[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VcQ8ZoGqR=iOzVq0WbieMvGFnkTQZ-TBmwBTZT0B1NS_Q@mail.gmail.com>
Date: Tue, 28 Feb 2017 15:35:51 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Matt Fleming <matt@...eblueprint.co.uk>,
Jan Kiszka <jan.kiszka@...mens.com>,
"Kweh, Hock Leong" <hock.leong.kweh@...el.com>,
"Bryan O'Donoghue" <pure.logic@...us-software.ie>,
"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 Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> 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:
> 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.
Actually it most likely that Quark kernel (kernel compiled to be run
on Quark) will be ever used on the rest of (modern) x86 since it's
486+ architecture (kernel has specific option for it, 586TSC).
So, we might just be dependent or chosen by Quark.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists