linux-kernel - Re: [RFC] Second attempt at kernel secure boot support

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: <alpine.LNX.2.00.1211051535060.24253@pobox.suse.cz>
Date:	Mon, 5 Nov 2012 15:40:15 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>,
	Chris Friesen <chris.friesen@...band.com>,
	Pavel Machek <pavel@....cz>,
	Eric Paris <eparis@...isplace.org>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Oliver Neukum <oneukum@...e.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	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 Sun, 4 Nov 2012, Eric W. Biederman wrote:

> > Why is "when kernel has been securely booted, the in-kernel kexec 
> > mechanism has to verify the signature of the supplied image before 
> > kexecing it" not enough? (basically the same thing we are doing for signed 
> > modules already).
> 
> For modules the only untrusted part of their environment are the command
> line parameters, and several of those have already been noted for
> needing to be ignored in a non-trusted root scenario.
> 
> For kexec there is a bunch of glue code and data that takes care of
> transitioning from the environment provided by kexec and the environment
> that the linux kernel or memtest86 or whatever we are booting is
> expecting.
> 
> Figuring out what glue code and data we need and supplying that glue
> code and data is what kexec-tools does.  The situation is a bit like
> dealing with the modules before most of the work of insmod was moved
> into the kernel.
> 
> For kexec-tools it is desirable to have glue layers outside of the
> kernel because every boot system in existence has a different set of
> parameter passing rules.
> 
> So signing in the kernel gets us into how do we sign the glue code and
> how dow we verify the glue code will jump to our signed and verified
> kernel image.

Do I understand you correctly that by the 'glue' stuff you actually mean 
the division of the kexec image into segments?

Of course, when we are dividing the image into segments and then passing 
those individually (even more so if some transformations are performed on 
those segments, which I don't know whether that's the case or not), then 
we can't do any signature verification of the image any more.

But I still don't fully understand what is so magical about taking the 
kernel image as is, and passing the whole lot to the running kernel as-is, 
allowing for signature verification.

Yes, it couldn't be sys_kexec_load(), as that would be ABI breakage, so 
it'd mean sys_kexec_raw_load(), or whatever ... but I fail to see why that 
would be problem in principle.

If you can point me to the code where all the magic that prevents this 
easy handling is happening, I'd appreciate it.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
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/