[Mono-devel-list] Performance issues with security permissions

[Sebastien Pouliot]

> > * So the only thing creating the permission object does (without
> > --security) is more memory allocations, additional garbage collection...
> > All bad for Mono's performance. So the pattern was changed to something
> > like:
> >
> > 	public static string GetEnvironmentVariable (string name)
> > 	{
> > 		if (SecurityManager.SecurityEnabled) {
> > 			new EnvironmentPermission
>
> Yep, this looks good: it's the reason I insisted we'd use the
> --security option.

And it's a good idea ;-)

The important point (that I missed to mention earlier) is that --security
and SecurityManager.SecurityEnabled aren't _exactly_ the same thing. I.e.
not supplying --security removes more security checks than setting
SecurityManager.SecurityEnabled = false.

A visible case (right now) is that non-CAS security permissions, like
PrincipalPermission, won't be executed (by default) using declarative
security but will still work as expected if imperative security is used. In
contrast the MS runtime would execute this in both case.

> > * Now the property value for SecurityManager.SecurityEnabled reside in
> > unmanaged code (so it can be used over there and so we can't reflect on
> > the field to change its value). This means an internal call each time.
> >
> > To avoid this the JIT _could_ produce code to replace SystemManager.
> > SecurityEnabled by false when --security isn't enabled. In this case the
> > permission creation/demand would be treated as dead code (and possibly
> > totally removed by optimizations).
> >
> > 	??? is it worth it ???
>
> Yes, it is.

Great :)

> We'll do two things: if --security is not provided,
> the call will be changed to a false boolean value. I committed last week
> a change that will enable the code to be removed in this case also
> when the default optimization options are used (I needed it to remove
> code as well in some experimental code I had written).
> The other thing is: if --security is provided, the icall will be
> changed to a simple load from the memory location where the flag
> is stored,
> so it will be quite fast to execute. This could be optimized so
> that once the value is set to false we always return a false boolean
> constant (if we agree that in that case results should be considered
> undefined).

Want me to open a bugzilla issue on that ?

> >         * Another example is demanding a permission that is already
> >         demanded by something else down the execution stack. This is why
> >         Environment.CurrentDirectory doesn't check for PathDiscovery
> >         permissions because System.IO.Directory already does the job.
>
> A demand () in a call frame could mark the callframe if it succedes
> and an new demand would need to wlak the stack just to that point
> (this doesn't get rid of the obj creation ovehead, though...).

We could mark the stack with an Assert (either in the source code or as
an optimization) but evaluating an Demand/Assert on a frame is nearly
identical (i.e. calling IsSubsetOf), so this will likely only help if
we're looping.

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