[Mono-devel-list] CAS update / feedback

[Sébastien Pouliot]

Hello all,

I'm in the process of adding support for declarative security attributes
into Mono.
http://bugzilla.ximian.com/show_bug.cgi?id=52693

My current approach was to try to fit all this into the same model. I.e. to
share, as much as possible, the code between the declarative and imperative
security support.

Then last week (Boston meeting) Lupus suggested me to use a cache of the
PermissionSet coming from the metadata. Doing this cache is possible only
for PermissionSet coming from the metadata (declarative security) as they
can never change. However this requires "somewhat" (not a big deal)
different code than dealing with imperative security.

Now having a "somewhat different" code enable gave me an idea. Why not
having a "more different" code ?
Sharing code was to avoid complexity - but code quantity != code complexity
so...

Right now I'm thinking about dropping the JIT code generation for stack
modifiers (Assert, Deny and PermitOnly), i.e. everything that isn't a
demand.
That would:
(a) delay the creation of the PermissionSet objects (at the first stack
walk);
(b) remove any execution time penality to apply declarative stack modifiers
in the source code - at least if there are no demand (e.g. CAS turned off);
(c) it simplifies (and reduce) the code required in mini.c to implement CAS
(not much but less code == less bugs).

So the plan would be to:
(a) wait for a demand (i.e. demand, noncasdemand, demandchoice) either
	- triggered by the JIT-generated code (i.e. declarative security);
	- triggered in the source code (i.e. imperative security);
(b) if the demand requires a stack walk (e.g. some permissions inherits from
CodeAccessPermission)
	- use the execution stack for retreive all methods;
	- check if methods have security attributes
		- look if the items are cache for the stack modifiers;
			- if not then create (and cache) the PermissionSet;
			- keep pointers to the PermissionSet into MonoMethod/MethodInfo;
		- execute the stack modifiers;

The extra difficulties are:
- 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);
- to be able keep in order the execution stack (used for declarative
security) with the security stack (to be used for the imperative security);

Notes
- It doesn't remove the need to add a "security stack" for imperative
security;
- It doesn't complexify (nor simplify) the CompressedStack required for
threading...
- That doesn't applies to LinkDemand (JIT time) and InheritanceDemand (class
loader);


Anyone sees problems, or other simplification possible, with that ?
Thanks

Sebastien Pouliot
home: spouliot at videotron.ca
blog: http://pages.infinit.net/ctech/poupou.html