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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
