[Mono-devel-list] CAS update / feedback

[Sébastien Pouliot]

Thanks again Paolo :)

> > The point of my last email was that Assert (like Deny and
> PermitOnly) are
> > stack modifiers. Calling them has no impact until a stack walk
> is triggered
> > by any kind of Demand. If this has no impact maybe it could (or
> should) be
> > delayed...
> [...]
> > However like I said Assert *DOES NOTHING* unless a stack walk
> is triggered.
> > So we're still "loosing" time to mark the stack UInt32.MaxValue -
> > (UInt32.MaxValue / 1024) as most calls will never reach a
> Demand. At this
> > time I'm unsure about the performance of stack marking (it
> depends on the
> > type of stack we'll be using/reusing) but anyway it will be > 0.
>
> It should eventually be quite fast: if we use a variable on the call frame
> it's like a push on a single list.

Ok, I trust you completely on the performance :-).
I just assumed this to be far more CPU intensive than my alternative.

In this case the variable to be pushed must work for both imperative and
declarative security. It must be able to (at least) store a "reference"
(pointer/index/...) to a Assert, Deny and PermitOnly (3). A reference to the
assembly is also required but is already available from the execution stack.

We'll get PermissionSet instances (or IPermission instances that can be
converted to PermissionSet) from imperative security to store, directly or
indirectly, on the stack. But this isn't the optimal format for the
declarative attributes (as it requires to create them even if they'll never
be used).

> In this case we need to
> register the variable
> in MonoJitInfo so the stack walk can find it.

I'll get a look into MonoJitInfo.
Is there any code doing something similar right now ?

> > So the idea is that we already have two ways to populate the
> security stack
> > (declarative and imperative) so why not "create" two stack ?
> [...]
> > Cons
> > * We need to add an internal API to get the declarative
> security data from
> > the managed side (right now it's push from the JIT/runtime into
> the managed
> > world);
> > * We still need to implement the other half (imperative) to match MS
> > implementation (we're not saving development time);
> > * We must be able keep in order the execution stack (used for
> declarative
> > security) with the security stack (to be used for the
> imperative security);
>
> This is the biggest issue. Is the order significant inside the
> same call frame?

I don't think it's a problem.

There can be only one Assert, one Deny and one PermitOnly in a frame. Trying
to add more (imperatively) throw an exception. Method-level declarative
security attributes takes precedences over class-level attributes.

The only important order (in a frame) is the different markers, which is
(AFAIK):
- PermitOnly;
- Deny, and
- Assert.

> I guess so. What if Assert() is called in a loop? It's easy to optimize
> if you assert the same permission, but what if we alternate between two
> different ones? Anyway, this is mostly an issue of the imperative code.

If we are in a loop we must mark each stack frame with the Assert (or other
stack markers) before we enter the method, then remove it when we exit the
method. That's a scenario where I thinked performance would suffer but AFAIK
we don't have a choice for imperative security.

I was hoping to remove these marks for declarative security by encoding a
flag in both MonoMethod and MonoClass with the kind of security actions
applicable. Since this only has to be done once (when JITting the method)
and not every time we call the method.

Sebastien