On Tue, Nov 6, 2012 at 4:18 PM, Takashi Iwai ti...@suse.de wrote:
Right, and it's intentionally dropped so. For the non-default fw
path, it can be added via proc dynamically or via kconfig statically.
If the firmware is generated via udev, then it doesn't make sense to
check a static
On Tue, Nov 6, 2012 at 6:17 PM, Takashi Iwai ti...@suse.de wrote:
At Tue, 6 Nov 2012 18:04:36 +0800,
Ming Lei wrote:
On Tue, Nov 6, 2012 at 4:18 PM, Takashi Iwai ti...@suse.de wrote:
Right, and it's intentionally dropped so. For the non-default fw
path, it can be added via proc
On Wed, 31 Oct 2012, Matthew Garrett wrote:
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
On Tue, Nov 06, 2012 at 08:57:06AM +, Jan Beulich wrote:
The question here is how to properly invalidate that data then:
So far I was assuming that clearing the valid bit would be the way
to go, as the specification says nothing on e.g. the image address
being zero having any specific
On Tue, Nov 06, 2012 at 01:51:15PM +0100, Jiri Kosina wrote:
On Wed, 31 Oct 2012, Matthew Garrett wrote:
shim generates a public and private key.
It seems to me that this brings quite a huge delay into the boot process
both for regular and resume cases (as shim has no way to know what is
On Tue, Nov 06, 2012 at 09:12:17AM +, Alan Cox wrote:
- is it worth Red Hat doing - that's up to Red Hat's business managers
- is it worth merging into the kernel - that's not
The capability bit is small and clean the rest of it is beginning to look
far too ugly for upstream right now.
On 06.11.12 at 13:55, Josh Triplett j...@joshtriplett.org wrote:
On Tue, Nov 06, 2012 at 08:57:06AM +, Jan Beulich wrote:
The question here is how to properly invalidate that data then:
So far I was assuming that clearing the valid bit would be the way
to go, as the specification says
On 11/06/2012 01:56 AM, Florian Weimer wrote:
Personally, I think the only way out of this mess is to teach users
how to disable Secure Boot.
If you're going to go that far, why not just get them to install a
RedHat (or SuSE, or Ubuntu, or whoever) key and use that instead?
Secure boot
On Tue, 06 Nov 2012 16:55:25 -0500
Matthew Garrett mj...@srcf.ucam.org wrote:
I'm not sure why you think that Fedora PXE installs will automatically wipe
disks - they'll do whatever Kickstart tells them to do. The only thing
relevant to secure boot here is that you need a signed bootloader,
Sure, and scripts run as root can wipe your files too. That's really not what
this is all about.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at
10 matches
Mail list logo
