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

[Bryan O'Donoghue]

On 28/02/17 15:27, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
> <pure.logic@xxxxxxxxxxxxxxxxx> wrote:
>> On 28/02/17 13:36, Andy Shevchenko wrote:
>>> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
>>> <andy.shevchenko@xxxxxxxxx> wrote:
>>>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
>>>> <ard.biesheuvel@xxxxxxxxxx> wrote:
>>>>> On 28 February 2017 at 12:29, Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx>
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