On 2017-02-17 09:23, Kweh, Hock Leong wrote: >> -----Original Message----- >> From: Bryan O'Donoghue [mailto:pure.logic@xxxxxxxxxxxxxxxxx] >> Sent: Friday, February 17, 2017 8:54 AM >> To: Kweh, Hock Leong <hock.leong.kweh@xxxxxxxxx>; Jan Kiszka >> <jan.kiszka@xxxxxxxxxxx>; Andy Shevchenko <andy.shevchenko@xxxxxxxxx> >> Cc: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>; Ard Biesheuvel >> <ard.biesheuvel@xxxxxxxxxx>; linux-efi@xxxxxxxxxxxxxxx; Linux Kernel Mailing >> List <linux-kernel@xxxxxxxxxxxxxxx>; Borislav Petkov <bp@xxxxxxxxx> >> 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@xxxxxxxxxxx] >>>> Sent: Thursday, February 16, 2017 3:00 AM >>>> To: Andy Shevchenko <andy.shevchenko@xxxxxxxxx> >>>> Cc: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>; Ard Biesheuvel >>>> <ard.biesheuvel@xxxxxxxxxx>; linux-efi@xxxxxxxxxxxxxxx; Linux Kernel >>>> Mailing List <linux-kernel@xxxxxxxxxxxxxxx>; Borislav Petkov >>>> <bp@xxxxxxxxx>; Kweh, Hock Leong <hock.leong.kweh@xxxxxxxxx>; Bryan >>>> O'Donoghue <pure.logic@xxxxxxxxxxxxxxxxx> >>>> 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@xxxxxxxxxxx> >>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
