Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1581530 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images Jan Kiszka <jan.kiszka@siemens.com> - 2017-02-15 19:20 +0100
    Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-02-15 19:20 +0100
      Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Jan Kiszka <jan.kiszka@siemens.com> - 2017-02-15 19:50 +0100
    [PATCH 1/2] efi/capsule: Prepare for loading images with security header Jan Kiszka <jan.kiszka@siemens.com> - 2017-02-15 19:20 +0100
    [PATCH 2/2] efi/capsule: Add support for Quark security header Jan Kiszka <jan.kiszka@siemens.com> - 2017-02-15 19:20 +0100
      Re: [PATCH 2/2] efi/capsule: Add support for Quark security header Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2017-02-17 02:40 +0100
    Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-02-15 19:50 +0100
    Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-02-15 19:50 +0100
      Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Jan Kiszka <jan.kiszka@siemens.com> - 2017-02-15 20:00 +0100
        Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Jan Kiszka <jan.kiszka@siemens.com> - 2017-02-15 20:10 +0100
          RE: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images "Kweh, Hock Leong" <hock.leong.kweh@intel.com> - 2017-02-16 04:10 +0100
            Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Jan Kiszka <jan.kiszka@siemens.com> - 2017-02-16 08:40 +0100
              Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-02-18 23:00 +0100
                Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Jan Kiszka <jan.kiszka@siemens.com> - 2017-02-19 14:40 +0100
                  Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2017-02-20 02:40 +0100
                    Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Jan Kiszka <jan.kiszka@siemens.com> - 2017-02-20 03:00 +0100
            Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2017-02-17 02:00 +0100
              RE: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images "Kweh, Hock Leong" <hock.leong.kweh@intel.com> - 2017-02-17 09:30 +0100
                Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Jan Kiszka <jan.kiszka@siemens.com> - 2017-02-17 10:30 +0100
                  Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Matt Fleming <matt@codeblueprint.co.uk> - 2017-02-28 13:20 +0100
                    Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Jan Kiszka <jan.kiszka@siemens.com> - 2017-02-28 13:30 +0100
                      Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Matt Fleming <matt@codeblueprint.co.uk> - 2017-02-28 13:40 +0100
                        Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-02-28 14:40 +0100
                          Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2017-02-28 16:10 +0100
                          Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2017-02-28 16:20 +0100
                            Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-02-28 17:30 +0100
                              Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-02-28 18:20 +0100
                                Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2017-02-28 19:50 +0100
                                  Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2017-03-01 15:40 +0100
                                    Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-03-01 16:10 +0100
                              Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2017-02-28 18:30 +0100
                        Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-02-28 14:40 +0100
                          Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-02-28 14:40 +0100
                Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2017-02-17 11:00 +0100
                  Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Jan Kiszka <jan.kiszka@siemens.com> - 2017-02-17 11:20 +0100
                    Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark  images Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2017-02-17 12:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

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

On 2017-02-28 13:12, Matt Fleming wrote:
> On Fri, 17 Feb, at 10:24:41AM, Jan Kiszka wrote:
>>
>> 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.
> 
> I'm fairly sure this was my first thought when we discussed this
> originally, some years ago now.
> 
> The whole CSH concept is, frankly, stupid. It makes a mockery of
> everything the capsule interface was designed to be.
> 
> I have long been holding out in hope that someone would patch the
> firmware to work around this CSH requirement, something along the
> lines of the double wrapping Jan mentions above. It's not like the
> Quark is the only platform that wants to verify capsules.
> 
> But to my knowledge, that hasn't happened.
> 
> Nevertheless my answer is still the same - someone needs to go and
> update the Quark firmware source to work with the generic capsule
> mechanism.
> 

From you POV, does this exclude upstream quirk support for already
shipped devices?

Jan

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

[toc] | [prev] | [next] | [standalone]

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

On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
> 
> From you POV, does this exclude upstream quirk support for already
> shipped devices?

It would need to be an extremely small, well-contained change, that
had no chance of disrupting other users of the capsule interface and
where I had a good feeling that supporting it wouldn't turn into a
maintenance nightmare (mountains of DMI strings or new platforms
coming to market that used it).

That's a tall order, and I'm pretty skeptical. Still, I'll never say
never. Plus Ard would need convincing to give his ACK too.

P.S. Has anyone actually investigated what would be required to fix
the firmware to be able to extract the CSH if it was contained inside
a capsule?

[toc] | [prev] | [next] | [standalone]

#1589447

On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 28 February 2017 at 12:29, Matt Fleming <matt@codeblueprint.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).

+ it's UP only!

> So, we might just be dependent or chosen by Quark.

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

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

On 28/02/17 15:07, Bryan O'Donoghue wrote:
> a big fat ia32

*allow a full fat..

-- 
bod

[toc] | [prev] | [next] | [standalone]

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

On 28/02/17 13:36, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>>> On 28 February 2017 at 12:29, Matt Fleming <matt@codeblueprint.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).
> 
> + it's UP only!
> 
>> So, we might just be dependent or chosen by Quark.
> 

Still though the current ia32 kernel runs on Quark and all other ia32
systems. It would be a pity/shame to make this feature dependent on
compiling a Quark specific kernel, after all its only a header on a
capsule as opposed to a large hardware-level architectural divergence.

I'd still like us to try for a low-fat hook that would a big fat ia32
kernel just work without having to force a user compile up a
Quark-specific kernel.

-- 
bod

[toc] | [prev] | [next] | [standalone]

#1589604

On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
<pure.logic@nexus-software.ie> wrote:
> On 28/02/17 13:36, Andy Shevchenko wrote:
>> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
>> <andy.shevchenko@gmail.com> wrote:
>>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
>>> <ard.biesheuvel@linaro.org> wrote:
>>>> On 28 February 2017 at 12:29, Matt Fleming <matt@codeblueprint.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).
>>
>> + it's UP only!
>>
>>> So, we might just be dependent or chosen by Quark.
>>
>
> Still though the current ia32 kernel runs on Quark and all other ia32
> systems.

How come? Quark has a silicon bug (SMP kernel might oops) and it is
not even i586!

> It would be a pity/shame to make this feature dependent on
> compiling a Quark specific kernel, after all its only a header on a
> capsule as opposed to a large hardware-level architectural divergence.
>

> I'd still like us to try for a low-fat hook that would a big fat ia32
> kernel just work without having to force a user compile up a
> Quark-specific kernel.

Can you elaborate how to run i686 kernel (which is default for x86
32-bit AFAIK) on Quark?

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1589639

On Tue, Feb 28, 2017 at 6:52 PM, Bryan O'Donoghue
<pure.logic@nexus-software.ie> wrote:
> On 28/02/17 15:27, Andy Shevchenko wrote:
>> On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
>> <pure.logic@nexus-software.ie> wrote:
>>> On 28/02/17 13:36, Andy Shevchenko wrote:
>>>> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
>>>> <andy.shevchenko@gmail.com> wrote:
>>>>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
>>>>> <ard.biesheuvel@linaro.org> wrote:
>>>>>> On 28 February 2017 at 12:29, Matt Fleming <matt@codeblueprint.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).
>>>>
>>>> + it's UP only!
>>>>
>>>>> So, we might just be dependent or chosen by Quark.
>>>>
>>>
>>> Still though the current ia32 kernel runs on Quark and all other ia32
>>> systems.
>>
>> How come? Quark has a silicon bug (SMP kernel might oops) and it is
>> not even i586!
>
> sorry if this is a bit long in advance...
>
> You mean a lock prefixed pagefault.
>
> For reference Quark should be considered CONFIG_M586TSC=y (or better)
> i.e. it's 586 ISA with a TSC added on.

So, if it would be CONFIG_M686=y then?
This is default for x86 32-bit kernels.

>
> I've been meaning to do a write up about this, since I've spent some
> time with a debugger doing an analysis of the fault. Basically any
> operation that is lock-prefixed that also page-faults pushes the address
> of the _previous_ instruction (not the instruction that faulted) onto
> the PF# stack. Which sucks.
>
> Obviously then when you IRET you will execute the previous instruction
> again - on return to user-space - as opposed to the instruction you
> faulted on.
>
> So it's nothing to do with SMP per se, except that the lock prefix was
> added to drive the #lock signal on future SMP versions of the part (that
> never happened). We discussed this @ the time Dave Jones did
>
> commit d4e1a0af1d3a88cdfc8c954d3005eb8745ec518d
> Author: Dave Jones <davej@redhat.com>
> Date:   Tue Oct 28 13:57:53 2014 -0400
>
>     x86: Don't enable F00F workaround on Intel Quark processors
>
> ... and we agreed to have a good look at lock prefixed instructions in
> the kernel. On !SMP builds there is (or was at the time anyway) alot of
> LOCK_PREFIX looking like this
>
> #ifdef CONFIG_SMP
> #define LOCK_PREFIX_HERE \
>                 ".pushsection .smp_locks,\"a\"\n"       \
>                 ".balign 4\n"                           \
>                 ".long 671f - .\n" /* offset */         \
>                 ".popsection\n"                         \
>                 "671:"
>
> #define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock; "
>
> #else /* ! CONFIG_SMP */
> #define LOCK_PREFIX_HERE ""
> #define LOCK_PREFIX ""
> #endif
>
> Which meant that !SMP was safe. It was probably overkill though because
> kernel code shouldn't PF anyway.

So, would it work if CONFIG_SMP=y ?
(This is default for x86 32-bit kernels)

> !SMP ia32 builds should be fine and we have never actually seen _kernel_
> code die on SMP builds ... presumably (demonstrably) because lock
> prefixed operations in the kernel don't PF#.

Which doesn't guarantee that it will not oops at some circumstances.

>>> It would be a pity/shame to make this feature dependent on
>>> compiling a Quark specific kernel, after all its only a header on a
>>> capsule as opposed to a large hardware-level architectural divergence.
>>>
>>
>>> I'd still like us to try for a low-fat hook that would a big fat ia32
>>> kernel just work without having to force a user compile up a
>>> Quark-specific kernel.
>>
>> Can you elaborate how to run i686 kernel (which is default for x86
>> 32-bit AFAIK) on Quark?
>
> A kernel compiled like this
>
> make menuconfig ARCH=i386

I hope you care that it is equivalent to

make menuconfig ARCH=i686

> make bzImage -j 8
>
> will run just fine on Quark x1000 I do it regularly. CPUID ought to (and
> does) inform the runtime kernel of what to do re: MSRs etc.
>
> We won't execute xmm/mmx, we won't touch 686 specific MSRs etc, etc.

It is i*6*86 code still.

So, summarize, you state that
1. CONFIG_SMP=y and
2. CONFIG_M686=y and
3. Kernel works on Quark

Is it correct?

If 1 or 2 is not correct it means we can *not* use the same kernel on
Quark. Unfortunately.

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

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

On 28/02/17 17:18, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 6:52 PM, Bryan O'Donoghue
>> A kernel compiled like this
>>
>> make menuconfig ARCH=i386
> 
> I hope you care that it is equivalent to
> 
> make menuconfig ARCH=i686
> 
>> make bzImage -j 8
>>
>> will run just fine on Quark x1000 I do it regularly. CPUID ought to (and
>> does) inform the runtime kernel of what to do re: MSRs etc.
>>
>> We won't execute xmm/mmx, we won't touch 686 specific MSRs etc, etc.
> 
> It is i*6*86 code still.
> 
> So, summarize, you state that
> 1. CONFIG_SMP=y and
> 2. CONFIG_M686=y and
> 3. Kernel works on Quark
> 
> Is it correct?

Logically yes. It's a very long time since I looked in detail. No harm
in checking it out though.

I'll compile up the above kernel this evening (GMT) and verify.


-- 
bod

[toc] | [prev] | [next] | [standalone]

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

On 28/02/17 17:42, Bryan O'Donoghue wrote:
> On 28/02/17 17:18, Andy Shevchenko wrote:
>> On Tue, Feb 28, 2017 at 6:52 PM, Bryan O'Donoghue
>>> A kernel compiled like this
>>>
>>> make menuconfig ARCH=i386
>>
>> I hope you care that it is equivalent to
>>
>> make menuconfig ARCH=i686
>>
>>> make bzImage -j 8
>>>
>>> will run just fine on Quark x1000 I do it regularly. CPUID ought to (and
>>> does) inform the runtime kernel of what to do re: MSRs etc.
>>>
>>> We won't execute xmm/mmx, we won't touch 686 specific MSRs etc, etc.
>>
>> It is i*6*86 code still.
>>
>> So, summarize, you state that
>> 1. CONFIG_SMP=y and
>> 2. CONFIG_M686=y and
>> 3. Kernel works on Quark
>>
>> Is it correct?
>
> Logically yes. It's a very long time since I looked in detail. No harm
> in checking it out though.
>
> I'll compile up the above kernel this evening (GMT) and verify.
>
>

CONFIG_SMP=y - no difference - like I say it's PF# on lock prefix
                instructions, not SMP=y that's the problem here
CONFIG_M686=y (doesnt' boot)
CONFIG_M586TSC=y does boot

So yes M686 is not bootable on this part. My point to you about having a 
custom kernel though still stands, you shouldn't have to compile a quark 
specific kernel - just a 586TSC kernel with Quark support.

For example CentOS is bootable on Quark.


---
bod

[toc] | [prev] | [next] | [standalone]

#1590378

On Wed, Mar 1, 2017 at 4:02 PM, Bryan O'Donoghue
<pure.logic@nexus-software.ie> wrote:

>>> So, summarize, you state that
>>> 1. CONFIG_SMP=y and
>>> 2. CONFIG_M686=y and
>>> 3. Kernel works on Quark
>>>
>>> Is it correct?

>> Logically yes. It's a very long time since I looked in detail. No harm
>> in checking it out though.
>>
>> I'll compile up the above kernel this evening (GMT) and verify.

> CONFIG_SMP=y - no difference - like I say it's PF# on lock prefix
>                instructions, not SMP=y that's the problem here
> CONFIG_M686=y (doesnt' boot)
> CONFIG_M586TSC=y does boot

> So yes M686 is not bootable on this part. My point to you about having a
> custom kernel though still stands, you shouldn't have to compile a quark
> specific kernel - just a 586TSC kernel with Quark support.

... which is not default. That's my point.

> For example CentOS is bootable on Quark.

Because someone there took care of it. (I think being i586 compatible
binaries as well)

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

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

On 28/02/17 15:27, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
> <pure.logic@nexus-software.ie> wrote:
>> On 28/02/17 13:36, Andy Shevchenko wrote:
>>> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
>>> <andy.shevchenko@gmail.com> wrote:
>>>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
>>>> <ard.biesheuvel@linaro.org> wrote:
>>>>> On 28 February 2017 at 12:29, Matt Fleming <matt@codeblueprint.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).
>>>
>>> + it's UP only!
>>>
>>>> So, we might just be dependent or chosen by Quark.
>>>
>>
>> Still though the current ia32 kernel runs on Quark and all other ia32
>> systems.
> 
> How come? Quark has a silicon bug (SMP kernel might oops) and it is
> not even i586!

sorry if this is a bit long in advance...

You mean a lock prefixed pagefault.

For reference Quark should be considered CONFIG_M586TSC=y (or better)
i.e. it's 586 ISA with a TSC added on.

I've been meaning to do a write up about this, since I've spent some
time with a debugger doing an analysis of the fault. Basically any
operation that is lock-prefixed that also page-faults pushes the address
of the _previous_ instruction (not the instruction that faulted) onto
the PF# stack. Which sucks.

Obviously then when you IRET you will execute the previous instruction
again - on return to user-space - as opposed to the instruction you
faulted on.

So it's nothing to do with SMP per se, except that the lock prefix was
added to drive the #lock signal on future SMP versions of the part (that
never happened). We discussed this @ the time Dave Jones did

commit d4e1a0af1d3a88cdfc8c954d3005eb8745ec518d
Author: Dave Jones <davej@redhat.com>
Date:   Tue Oct 28 13:57:53 2014 -0400

    x86: Don't enable F00F workaround on Intel Quark processors

... and we agreed to have a good look at lock prefixed instructions in
the kernel. On !SMP builds there is (or was at the time anyway) alot of
LOCK_PREFIX looking like this

#ifdef CONFIG_SMP
#define LOCK_PREFIX_HERE \
                ".pushsection .smp_locks,\"a\"\n"       \
                ".balign 4\n"                           \
                ".long 671f - .\n" /* offset */         \
                ".popsection\n"                         \
                "671:"

#define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock; "

#else /* ! CONFIG_SMP */
#define LOCK_PREFIX_HERE ""
#define LOCK_PREFIX ""
#endif

Which meant that !SMP was safe. It was probably overkill though because
kernel code shouldn't PF anyway.

User-space is another story.

This image faults reliably in rpc-stad and sshd - because like I say -
lock-prefixed page faults push the previous (not the current)
instruction onto the pagefault stack.

https://sourceforge.net/projects/galileodebian/

anyway...

!SMP ia32 builds should be fine and we have never actually seen _kernel_
code die on SMP builds ... presumably (demonstrably) because lock
prefixed operations in the kernel don't PF#.

>> It would be a pity/shame to make this feature dependent on
>> compiling a Quark specific kernel, after all its only a header on a
>> capsule as opposed to a large hardware-level architectural divergence.
>>
> 
>> I'd still like us to try for a low-fat hook that would a big fat ia32
>> kernel just work without having to force a user compile up a
>> Quark-specific kernel.
> 
> Can you elaborate how to run i686 kernel (which is default for x86
> 32-bit AFAIK) on Quark?

A kernel compiled like this

make menuconfig ARCH=i386
make bzImage -j 8

will run just fine on Quark x1000 I do it regularly. CPUID ought to (and
does) inform the runtime kernel of what to do re: MSRs etc.

We won't execute xmm/mmx, we won't touch 686 specific MSRs etc, etc.

-- 
bod

[toc] | [prev] | [next] | [standalone]

#1589448

On 28 February 2017 at 12:29, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>>
>> From you POV, does this exclude upstream quirk support for already
>> shipped devices?
>
> It would need to be an extremely small, well-contained change, that
> had no chance of disrupting other users of the capsule interface and
> where I had a good feeling that supporting it wouldn't turn into a
> maintenance nightmare (mountains of DMI strings or new platforms
> coming to market that used it).
>
> That's a tall order, and I'm pretty skeptical. Still, I'll never say
> never. Plus Ard would need convincing to give his ACK too.
>
> P.S. Has anyone actually investigated what would be required to fix
> the firmware to be able to extract the CSH if it was contained inside
> a capsule?

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.

But I do realise that it increases the validation space for Matt,
given that he does the testing on the x86 side. For the ARM side of
things, the Kconfig option would simply not be settable. So I am going
to let Matt have the final word on this.

[toc] | [prev] | [next] | [standalone]

#1589452

On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 28 February 2017 at 12:29, Matt Fleming <matt@codeblueprint.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

[toc] | [prev] | [next] | [standalone]

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

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...

-- 
bod

[toc] | [prev] | [next] | [standalone]

#1583296 — 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

[toc] | [prev] | [next] | [standalone]

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

On 17/02/17 10:14, Jan Kiszka wrote:
> 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.

The CSH is supported on the non-secure SoCs - the BSP on Gen1 certainly did.

https://downloadcenter.intel.com/download/23197/Intel-Quark-SoC-X1000-Board-Support-Package-BSP-

- > QuarkPlatformPkg/Platform/Dxe/PlatformInit/DxeCapsuleSecurity.c

CreateCapsuleBufferForWriting()

Looks like it will tolerate a lack of CSH but, obviously that's no
solution for the secure boot parts.

> 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.

Hmm - the out of the box firmware will accept capsules from the website.
Gen1 and Gen2 should be the same in that respect - if you use the BSP
kernel.

You should validate the out-of-the-box capsule update - with the kernel
on SPI flash works with the CSH in place.

Next step then is to get it working on tip-of-tree.

I have one Gen1 left (which I won't be experimenting with) - and I think
one Gen2 (which I don't especially mind blowing up).

Let's take the time to validate (or repudiate)

1. Out of the box BSP works with CSH capsules in place
2. New tip-of-tree addition supports CSH capsules

and review.

Stripping the CSH shouldn't be necessary (and breaks the secure boot
parts anyway).

-- 
bod

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web