On Sun, 2009-06-21 at 23:10 +0200, Lucas Meijer wrote: > Hey Sebastien, > > Thanks for all the info. > > That would be wrong, but you're right that icalls are a bit special. > > The main point is detect-sc cannot generalize them, like p/invokes can > > be. > > > <snip> > > Here a counter-example (Math.cs) why: > > > > [MethodImplAttribute (MethodImplOptions.InternalCall)] > > public extern static double Floor (double d); > Do I summarize correctly if I say that there are icalls that can do no > harm, and icalls that can, so we cannot > just mark them as SecurityCritical. (because of the ones that can do no > harm like Math.Floor). ?
Yes, that's close enough. "can do no harm" -> "should do no harm" ;-) > Wouldn't it be easier from an audit perspective if all icalls are by > default considered SecurityCritical, unless > manually specified [Transparent] (like for Math.Floor). No, that's definitively not easier. > Maybe it's a > bit annoying adding those attributes manually, That's one (big) reason for not being easier (both annoying and error prone ;-) but it also means that: * in the mean time you get non-functional class libraries to continue the development of moonlight. This push this "feature" on the top of the priority list, while it can otherwise wait the audit stage; * you cannot apply [SecurityTransparent] anywhere but at the assembly-level (i.e. not on methods). Which is useless since this is the default in SL ;-). Of course you can leave them unmarked (at least as long as the runtime don't treat them specially); * the Mono runtime and BCL is a continuously moving target (new icalls, removed icalls, modified icalls). We would need to repeat the above steps each time we update from Mono HEAD. * even "safe" icalls (the one that should do no harm) needs to be audited, unlike other transparent code. Like I said it's definitively not easier ;-) Now marking them all [SecuritySafeCritical] has the advantages of: * Keeping Moonlight functional (with security enabled); * Adding all icalls to the audit list (even if they are to be audited separately or, at least, differently than the managed code). Removed (or unused, linker-wise) icalls will be removed from the list when regenerated; * Making the runtime refuse to run them unless marked as critical. Meaning we'll catch any new icalls (MAE) even if the list was not regenerated; The more you make me think about this the more convinced I am about the advantages of doing this the SSC way ;-) > however, it also seems like quite a error prone taks to take all icalls > that can do harm, and make sure that they're > really really only being called from securitycritical code. (now, and in > the future) Sure, but how does that differs from what's _already_ needed for moonlight ? e.g. p/invokes, unsafe code... Finding what's being called (or not) and from where (and its context) is not hard (and already done in our tooling). icalls (unless they call back into managed code) are no different. Saying that the audit is error prone is true, which is why the tools are made to ensure we can focus our attention on the right places (the SSC stuff). Having icalls does not change, much*, that and does not make it more (or less) error-prone. Also I fail to see (unless you did no want to imply that?) how does this differ from what you suggested above ? Because the above will work only if we do the same thing *earlier* and continue doing it afterward. Thanks Sebastien * the audit itself is different (icalls versus managed code) but the initial and subsequent detections are not. _______________________________________________ Moonlight-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/moonlight-list
