[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1378099377.7080.113.camel@linux-s257.site>
Date: Mon, 02 Sep 2013 13:22:57 +0800
From: joeyli <jlee@...e.com>
To: Kees Cook <keescook@...omium.org>
Cc: Lenny Szubowicz <lszubowi@...hat.com>,
Matthew Garrett <matthew.garrett@...ula.com>,
LKML <linux-kernel@...r.kernel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
Josh Boyer <jwboyer@...hat.com>
Subject: Re: [PATCH 0/10] Add additional security checks when module
loading is restricted
於 三,2013-08-28 於 16:07 -0700,Kees Cook 提到:
> On Wed, Aug 28, 2013 at 3:58 PM, Lenny Szubowicz <lszubowi@...hat.com> wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Matthew Garrett" <matthew.garrett@...ula.com>
> >> To: "Lenny Szubowicz" <lszubowi@...hat.com>
> >> Cc: linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org, jwboyer@...hat.com, keescook@...omium.org
> >> Sent: Wednesday, August 28, 2013 6:41:55 PM
> >> Subject: Re: [PATCH 0/10] Add additional security checks when module loading is restricted
> >>
> >> On Wed, 2013-08-28 at 18:37 -0400, Lenny Szubowicz wrote:
> >>
> >> > Did you purposely exclude similar checks for hibernate that were covered
> >> > by earlier versions of your patch set?
> >>
> >> Yes, I think it's worth tying it in with the encrypted hibernation
> >> support. The local attack is significantly harder in the hibernation
> >> case - in the face of unknown hardware it basically involves a
> >> pre-generated memory image corresponding to your system or the ability
> >> to force a reboot into an untrusted environment. I think it's probably
> >> more workable to just add a configuration option for forcing encrypted
> >> hibernation when secure boot is in use.
> >>
> >> --
> >> Matthew Garrett <matthew.garrett@...ula.com>
> >
> > I'm root. So I can write anything I want to the swap file that looks
> > like a valid hibernate image but is code of my choosing. I can read
> > anything I need from /dev/mem or /dev/kmem to help me do that.
> > I can then immediately initiate a reboot.
>
> Strictly speaking, RAM contents are not available via /dev/*mem, even
> to root. However, you can request a suspend image be written, but to
> not enter hibernation. Then modify the image, and request a resume
> from it.
>
> -Kees
>
I agreed!
As a userland hibernate tool, it possible trigger kernel to generate a
snapshot image of current memory, read the snapshot, modify and upload
it back to the temporary memory space of snapshot, trigger S4 resume to
restore it.
The signature check of S4 snapshot can prevent this attack because the
patches put the signature of snapshot image to snapshot header. Even
attacker change the signature of header or modified the data page in
snapshot. The modified snapshot image will not pass by signature check.
Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists