linux-kernel - Re: Early microcode signing in secure boot environment - Was: x86, microcode: Use common get_ramdisk

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]

Message-ID: <195101369.cgl3lvkTHk@skinner.arch.suse.de>
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/