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

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2017-02-17 09:23, Kweh, Hock Leong wrote:
>> -----Original Message-----
>> From: Bryan O'Donoghue [mailto:pure.logic@nexus-software.ie]
>> Sent: Friday, February 17, 2017 8:54 AM
>> To: Kweh, Hock Leong <hock.leong.kweh@intel.com>; Jan Kiszka
>> <jan.kiszka@siemens.com>; Andy Shevchenko <andy.shevchenko@gmail.com>
>> Cc: Matt Fleming <matt@codeblueprint.co.uk>; Ard Biesheuvel
>> <ard.biesheuvel@linaro.org>; linux-efi@vger.kernel.org; Linux Kernel Mailing
>> List <linux-kernel@vger.kernel.org>; Borislav Petkov <bp@alien8.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@siemens.com]
>>>> Sent: Thursday, February 16, 2017 3:00 AM
>>>> To: Andy Shevchenko <andy.shevchenko@gmail.com>
>>>> Cc: Matt Fleming <matt@codeblueprint.co.uk>; Ard Biesheuvel
>>>> <ard.biesheuvel@linaro.org>; linux-efi@vger.kernel.org; Linux Kernel
>>>> Mailing List <linux-kernel@vger.kernel.org>; Borislav Petkov
>>>> <bp@alien8.de>; Kweh, Hock Leong <hock.leong.kweh@intel.com>; Bryan
>>>> O'Donoghue <pure.logic@nexus-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@siemens.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