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: <5da59d02-d299-f5c7-48fa-a67bdd017252@siemens.com>
Date:   Fri, 17 Feb 2017 10:24:41 +0100
From:   Jan Kiszka <jan.kiszka@...mens.com>
To:     "Kweh, Hock Leong" <hock.leong.kweh@...el.com>,
        "Bryan O'Donoghue" <pure.logic@...us-software.ie>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Matt Fleming <matt@...eblueprint.co.uk>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        "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 2017-02-17 09:23, Kweh, Hock Leong wrote:
>> -----Original Message-----
>> From: Bryan O'Donoghue [mailto:pure.logic@...us-software.ie]
>> Sent: Friday, February 17, 2017 8:54 AM
>> To: Kweh, Hock Leong <hock.leong.kweh@...el.com>; Jan Kiszka
>> <jan.kiszka@...mens.com>; Andy Shevchenko <andy.shevchenko@...il.com>
>> Cc: Matt Fleming <matt@...eblueprint.co.uk>; Ard Biesheuvel
>> <ard.biesheuvel@...aro.org>; linux-efi@...r.kernel.org; Linux Kernel Mailing
>> List <linux-kernel@...r.kernel.org>; Borislav Petkov <bp@...en8.de>
>> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
>> images
>>
>>
>>
>> On 16/02/17 03:00, Kweh, Hock Leong wrote:
>>>> -----Original Message-----
>>>> From: Jan Kiszka [mailto:jan.kiszka@...mens.com]
>>>> Sent: Thursday, February 16, 2017 3:00 AM
>>>> To: Andy Shevchenko <andy.shevchenko@...il.com>
>>>> Cc: Matt Fleming <matt@...eblueprint.co.uk>; Ard Biesheuvel
>>>> <ard.biesheuvel@...aro.org>; linux-efi@...r.kernel.org; Linux Kernel
>>>> Mailing List <linux-kernel@...r.kernel.org>; Borislav Petkov
>>>> <bp@...en8.de>; Kweh, Hock Leong <hock.leong.kweh@...el.com>; Bryan
>>>> O'Donoghue <pure.logic@...us-software.ie>
>>>> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support
>>>> signed Quark images
>>>>
>>>> On 2017-02-15 19:50, Jan Kiszka wrote:
>>>>> On 2017-02-15 19:46, Andy Shevchenko wrote:
>>>>>> On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka
>>>>>> <jan.kiszka@...mens.com>
>>>> wrote:
>>>>>>> See patch 2 for the background.
>>>>>>>
>>>>>>> Series has been tested on the Galileo Gen2, to exclude
>>>>>>> regressions, with a firmware.cap without security header and the
>>>>>>> SIMATIC IOT2040 which requires the header because of its mandatory
>> secure boot.
>>>>>>
>>>>>> Briefly looking to the code it looks like a real hack.
>>>>>> Sorry, but it would be carefully (re-)designed.
>>>>>
>>>>> The interface that the firmware provides us? That should have been
>>>>> done differently, I agree, but I'm not too much into those firmware
>>>>> details, specifically when it comes to signatures.
>>>>>
>>>>> The Linux code was designed around that suboptimal situation. If
>>>>> there are better ideas, I'm all ears.
>>>>>
>>>>
>>>> Expanding CC's as requested by Andy.
>>>>
>>>> Jan
>>>>
>>>
>>> Hi Jan,
>>>
>>> While I upstreaming the capsule loader patches, I did work with
>>> maintainer Matt and look into this security header created for Quark.
>>> Eventually both of us agreed that this will not be upstream to
>>> mainline as it is really a Quark specific implementation.
>>
>> What's the logic of that ?
>>
>> It should be possible to provide a hook (or a custom function).
>>
>>>
>>> The proper implementation may require to work with UEFI community to
>>> expand its capsule spec to support signed binary.
>>
>> Are you volunteering to do that with - getting the CSH into the UEFI spec ?
>>
>> If not then we should have a method to load/ignore a capsule including the CSH,
>> if so then we should have a realistic timeline laid out for getting that spec work
>> done.
>>
>> Hint: I don't believe integrating the CSH into the UEFI standard will happen...
>>
> 
> Hi Jan & Bryan,
> 
> Please don't get me wrong. I am not rejecting the patch submission.
> I am just sharing a summary for the discussion that I had had it a year back
> with maintainer Matt for this topic. From the discussion, we did mention
> what would be the proper handling to this case. And to have UEFI expand

Do you happen to have a reference to the part of the discussions that
deal with the CSH topic?

> it capsule support and take in signed binary would be a more secured way.
> So, influencing UEFI community to have such support would be the right
> move throughout the discussion. That is my summary.
> 
> Of course, influencing the UEFI community would be the longer path.
> I think it is worth for try to bring the topic up here again to see if Matt
> would reconsider it. 

I just can re-express my frustration that this essential step hasn't
been started years ago by whoever designed the extension. Then I bet
there would have been constructive feedback on the interface BEFORE its
ugliness spread to broader use.

Or is there a technical need, in general or on Quark, to have the
signature header right before the standard capsule *for the handover* to
the firmware? I mean, I would naively put it into another capsule and
prepend that to the core so that the existing UEFI API can palate it
transparently and cleanly.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux