linux-kernel - Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

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: <CAKv+Gu-OCr1nX0-kWnWg4=DnDpZvM-ipSCfLbBA8h1e5eJYBbw@mail.gmail.com>
Date:   Tue, 28 Feb 2017 13:25:13 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Matt Fleming <matt@...eblueprint.co.uk>
Cc:     Jan Kiszka <jan.kiszka@...mens.com>,
        "Kweh, Hock Leong" <hock.leong.kweh@...el.com>,
        "Bryan O'Donoghue" <pure.logic@...us-software.ie>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>,
        "Ong, Boon Leong" <boon.leong.ong@...el.com>,
        "Mok, Tze Siong" <tze.siong.mok@...el.com>
Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

On 28 February 2017 at 12:29, Matt Fleming <matt@...eblueprint.co.uk> wrote:
> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>>
>> From you POV, does this exclude upstream quirk support for already
>> shipped devices?
>
> It would need to be an extremely small, well-contained change, that
> had no chance of disrupting other users of the capsule interface and
> where I had a good feeling that supporting it wouldn't turn into a
> maintenance nightmare (mountains of DMI strings or new platforms
> coming to market that used it).
>
> That's a tall order, and I'm pretty skeptical. Still, I'll never say
> never. Plus Ard would need convincing to give his ACK too.
>
> P.S. Has anyone actually investigated what would be required to fix
> the firmware to be able to extract the CSH if it was contained inside
> a capsule?

As I said before, I'd be ok with it if we select it compile time,
i.e., no runtime logic that infers whether we are running on such a
system or not, and no carrying both implementations in all kernels
that have capsule loading built in.

But I do realise that it increases the validation space for Matt,
given that he does the testing on the x86 side. For the ARM side of
things, the Kconfig option would simply not be settable. So I am going
to let Matt have the final word on this.