[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <36538307.gzWq1oO7Kg@linux-lqwf.site>
Date: Wed, 31 Oct 2012 23:19:31 +0100
From: Oliver Neukum <oneukum@...e.de>
To: Chris Friesen <chris.friesen@...band.com>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
Matthew Garrett <mjg59@...f.ucam.org>,
Jiri Kosina <jkosina@...e.cz>, Josh Boyer <jwboyer@...il.com>,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [RFC] Second attempt at kernel secure boot support
On Wednesday 31 October 2012 15:58:05 Chris Friesen wrote:
> On 10/31/2012 02:14 PM, Oliver Neukum wrote:
> > That would do it on my system.
> > Maybe in theory you could solve this by the kernel invalidating images
> > it hasn't written itself and forbidding to change the resume partition from the
> > kernel command line, but that would break user space hibernation.
>
> If the resuming kernel refuses to resume from images it didn't create
> itself, why do you need to forbid changing the resume partition from the
> kernel command line?
You don't. Signed images solve the problem.
I was responding to Alan's assertation that the problem could be solved
without signing the images. It turns out tht any such scheme would have
unacceptable limitations.
The key problem is actually safely storing the public key needed to verify
the signature. This problem is also solvable. It just needs help from the
UEFI infrastructure.
Regards
Oliver
--
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