lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 11 Apr 2013 10:59:26 +0200
From:	Thomas Renninger <trenn@...e.de>
To:	"Yu, Fenghua" <fenghua.yu@...el.com>
Cc:	Tang Chen <tangchen@...fujitsu.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Early microcode signing in secure boot environment -  Was: x86, microcode: Use common get_ramdisk_image()

On Thursday, April 11, 2013 08:28:37 AM Yu, Fenghua wrote:
> > From: Thomas Renninger [mailto:trenn@...e.de]
...
> > Does this apply to secure boot specification?
> 
> Secure boot can add another level of security because the early loaded
> microcode is part of initrd and initrd is measured by secure boot.
Not sure what is ment with "initrd is measured by secure boot".

Afaik the initrd does not get signed and verified, I cannot imagine how
that could work as it needs to get regenerated on client systems.

I expect it works like this:
initrd does not need signing as it is not executed itself, it only gets 
extracted.
Everything inside the initrd is subject to the secure boot rules:
binaries or whatever data which gets executed with kernel
privileges (or updates firmware) needs verification through
secure boot keys.

> > Is this "cryptographically authenticated by the CPU itself" thing
> > documented
> > somewhere so that security people can double check that it is really
> > secure?
> 
> X86 SDM defines that the second part of microcode update is the encrypted
> data.

Again, I doubt it is allowed to bypass UEFI authentication with arbitrary, 
vendor specific authentication checks.

      Thomas
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ