UEFI secure boot kernel restrictions
Posted Nov 8, 2012 16:13 UTC (Thu) by
alonz (subscriber, #815)
Parent article:
UEFI secure boot kernel restrictions
> It's not exactly clear why Microsoft would make a distinction between a
> kernel exploit and using legitimate kernel services when making a
> blacklisting decision [...]
Actually the explanation is quite simple: if a compromise is the result of a kernel exploit, Microsoft can expect (and/or demand) a bug fix – and revoke the key only if the vendor misbehaves. If the compromise is a "feature" of the product, this is vendor misbehavior by definition.
(I see the same at work, quite a lot—I architect security systems; this kind of behavior is built-in into the legalese of many certification processes.)
(
Log in to post comments)