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: <87ziah1ma9.fsf@concordia.ellerman.id.au>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ