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]

Date:   Fri, 17 Feb 2017 11:14:46 +0100
From:   Jan Kiszka <jan.kiszka@...mens.com>
To:     "Bryan O'Donoghue" <pure.logic@...us-software.ie>,
        "Kweh, Hock Leong" <hock.leong.kweh@...el.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-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 10:51, Bryan O'Donoghue wrote:
> On 17/02/17 08:23, Kweh, Hock Leong wrote:
>> And to have UEFI expand
>> 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.
> 
> CSH stands for "Clanton Secure Header" - Clanton being the internal
> code-name for Quark X1000 prior to release.
> 
> There is no chance the UEFI standard (which can be used on ARM and
> potentially other architectures) will accept a SoC specific
> route-of-trust prepended header.
> 
> Sure some kind of binary signed headers might become part of the
> standard eventually but, definitely _not_ a CSH.
> 
> The fact is CSH exists in the real-world and a UEFI firmware supports
> accepting the CSH/UEFI-capsule pair for updating itself.
> 
> I think a far more practical solution is to accommodate the defacto
> implementation (the only ? current implementation). To me it defies
> reason to have Quark X1000 be the only system (that I know of) capable
> of doing a capsule update - have capsule code in the kernel - but _not_
> support the header prepended to that capsule that the Quark
> firmware/bootrom require.
> 
> Right now the capsule code is dead code on Quark x1000. Let's do the
> right thing and make it usable. I fully support having a
> separate/parallel conversation with the UEFI body but, I'd be amazed if
> the "Clanton Secure Header" made it into the standard...
> 

To be precise, CSH is only required on X102x. The X100x SoCs, those are
also found on the Galileo Gen2 maker board, do not support secure boot
and do not use the header. IIRC, there used to be an eval system with
the X1020 as well, but I think it's no longer available.

Interestingly, the capsule file found in Intel's Galileo firmware update
package [1] contains the CSH header. But I only succeeded flashing it on
a Gen2 by removing the header first.

Jan

[1]
https://downloadcenter.intel.com/download/26417/Intel-Galileo-Firmware-Updater-and-Drivers?product=83137

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