[Mono-devel-list] CAS update / feedback

Sébastien Pouliot spouliot at videotron.ca
Fri Oct 29 08:37:36 EDT 2004

Hello all,

I'm in the process of adding support for declarative security attributes
into Mono.

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

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
That would:
(a) delay the creation of the PermissionSet objects (at the first stack
(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
	- 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);

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

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

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

More information about the Mono-devel-list mailing list