lkml.org 
[lkml]   [2012]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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


    \
     
     \ /
      Last update: 2012-10-31 18:21    [W:7.616 / U:0.388 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site