linux-kernel - Re: [PATCH 14/14] arm64: kexec_file: add vmlinux format 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]

Date:   Wed, 30 Aug 2017 18:40:14 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Mark Rutland <mark.rutland@....com>,
        AKASHI Takahiro <takahiro.akashi@...aro.org>
Cc:     herbert@...dor.apana.org.au, bhe@...hat.com,
        ard.biesheuvel@...aro.org, catalin.marinas@....com,
        will.deacon@....com, linux-kernel@...r.kernel.org,
        kexec@...ts.infradead.org, dhowells@...hat.com, arnd@...db.de,
        linux-arm-kernel@...ts.infradead.org, bauerman@...ux.vnet.ibm.com,
        akpm@...ux-foundation.org, dyoung@...hat.com, davem@...emloft.net,
        vgoyal@...hat.com
Subject: Re: [PATCH 14/14] arm64: kexec_file: add vmlinux format support

Mark Rutland <mark.rutland@....com> writes:

> On Thu, Aug 24, 2017 at 06:30:50PM +0100, Mark Rutland wrote:
>> On Thu, Aug 24, 2017 at 05:18:11PM +0900, AKASHI Takahiro wrote:
>> > The first PT_LOAD segment, which is assumed to be "text" code, in vmlinux
>> > will be loaded at the offset of TEXT_OFFSET from the begining of system
>> > memory. The other PT_LOAD segments are placed relative to the first one.
>> 
>> I really don't like assuming things about the vmlinux ELF file.
>> 
>> > Regarding kernel verification, since there is no standard way to contain
>> > a signature within elf binary, we follow PowerPC's (not yet upstreamed)
>> > approach, that is, appending a signature right after the kernel binary
>> > itself like module signing.
>> 
>> I also *really* don't like this. It's a bizarre in-band mechanism,
>> without explcit information. It's not a nice ABI.
>> 
>> If we can load an Image, why do we need to be able to load a vmlinux?
>
> So IIUC, the whole point of this is to be able to kexec_file_load() a
> vmlinux + signature bundle, for !CONFIG_EFI kernels.
>
> For that, I think that we actually need a new kexec_file_load${N}
> syscall, where we can pass the signature for the kernel as a separate
> file. Ideally also with a flags argument and perhaps the ability to sign
> the initrd too.
>
> That way we don't ahve to come up with a magic vmlinux+signature format,

You don't have to come up with one, it already exists. We've been using
it for signed modules for ~5 years.

It also has the advantages of being a signature of the entire ELF, no
silly games about which sections are included, and it's attached to the
vmlinux so you don't have to remember to copy it around. And the code to
produce it and verify it already exists.

cheers