Re: [RFC] Second attempt at kernel secure boot support

On Mon, 29 Oct 2012, Matthew Garrett wrote:

> > > This is pretty much identical to the first patchset, but with the capability
> > > renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants
> > > to deploy these then they should disable kexec until support for signed
> > > kexec payloads has been merged.
> > 
> > Apparently your patchset currently doesn't handle device firmware loading, 
> > nor do you seem to mention in in the comments.
> 
> Correct.
> 
> > I believe signed firmware loading should be put on plate as well, right?
> 
> I think that's definitely something that should be covered. I hadn't 
> worried about it immediately as any attack would be limited to machines 
> with a specific piece of hardware, and the attacker would need to expend 
> a significant amount of reverse engineering work on the firmware - and 
> we'd probably benefit from them doing that in the long run...

Now -- how about resuming from S4?

Reading stored memory image (potentially tampered before reboot) from disk 
is basically DMA-ing arbitrary data over the whole RAM. I am currently not 
able to imagine a scenario how this could be made "secure" (without 
storing private keys to sign the hibernation image on the machine itself 
which, well, doesn't sound secure either).

-- 
Jiri Kosina
SUSE Labs