linux-kernel - Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

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:	Fri, 22 Nov 2013 10:57:51 -0500
From:	Eric Paris <eparis@...isplace.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Vivek Goyal <vgoyal@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	kexec@...ts.infradead.org, "H. Peter Anvin" <hpa@...or.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Greg Kroah-Hartman <greg@...ah.com>
Subject: Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

On Fri, Nov 22, 2013 at 10:33 AM, Jiri Kosina <jkosina@...e.cz> wrote:
> On Fri, 22 Nov 2013, Geert Uytterhoeven wrote:
>
>> >> Only arm, i386, ppc, ppc64, sh, and x86_64 support zImage.
>> >> It's not clear to me what alpha supports (if it supports anything at all?).
>> >
>> > Motiviation behind this patchset is secureboot. That is x86 specific
>> > only and bzImage is most commonly used format on that platform. So it
>> > makes sense to implement bzImage loader first, IMO.
>>
>> While secureboot(TM) may be x86-centric
>
> And ARM, right?
>
>> IIRC actually loading signed kernels and modules didn't originate on
>> x86. Anything can have a bootloader that accepts signed kernel images
>> only.
>
> Yes, but if you don't have the whole secure boot security model (i.e. root
> is implicitly untrusted), it's all just a game really.
>
> If you are playing this "signed kernel and modules" game, but have trusted
> root, he's free to replace the bootloader by one that wouldn't be
> verifying the kernel signature, and reboot into arbitrary kernel.

Ignore secureboot completely.

Consider a cloud provider who gives their customer a machine where
they, the cloud provider, is specifying the kernel and initrd.  This
is a real thing that people do today.  Root on the machine has ZERO
control over the kernel, bootloader, and initrd.  Check it out,
qemu/kvm can do this.  But, there is no way to disable kexec if the
distro configures it in (well, there is in RHEL at least).  I've
brought this up before with little useful response from the kexec
maintainers.  What I'd like is for a kernel trusted by me, the cloud
operator, to be able to be kexec'd.  I'd rather not have to completely
turn off kexec...

Make sense how this is useful for things other than secureboot?  And
we have users who want this.  This is not a speculative completely
made up maybe some day someone will want this type idea....
--
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/