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

Groups > linux.kernel > #1332201 > unrolled thread

Re: [PATCH] efi: runtime-wrappers: run UEFI Runtime Services with interrupts enabled

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] efi: runtime-wrappers: run UEFI Runtime Services with  interrupts enabled Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-11 17:10 +0100

#1332201 — Re: [PATCH] efi: runtime-wrappers: run UEFI Runtime Services with interrupts enabled

On Mon, 08 Feb, at 11:37:58AM, Andy Lutomirski wrote:
> On Feb 4, 2016 5:58 AM, "Ard Biesheuvel" <ard.biesheuvel@linaro.org> wrote:
> >
> > OK, since Sai has confirmed that Windows leaves interrupts enabled when
> > calling the EFI variable store related runtime services, we should be able
> > to do the same for Linux, or at least be slightly more confident that we
> > won't have to back out this change later.
> 
> Could this use a mutex instead of a spinlock?
> 
> Can someone with a mixed mode setup read a variable in a loop and make
> sure it doesn't crash and burn?  It should work fine, but explicit
> testing would be nice.  (It's interesting mainly because doing a mixed
> mode call with interrupts on can result in a non-IST CPL0 to CPL0
> exception delivery, which won't result in a stack switch.  This could
> easily trigger a stack overflow, logic bug, microcode bug, or
> as-yet-unknown CPU "feature".
 
I don't have physical hardware for testing mixed mode anymore (that
was returned to Intel when I left) but testing with Qemu didn't turn
up any problems when running with interrupts enabled.

> Hmm.  We should also audit the mixed mode entry code to make sure that
> the high bits of RSP are explicitly clear before switching into compat
> mode.  If I had to make a guess about how CPUs behave, I'd guess
> pessimistically: Intel CPUs clear the high bits of RSP when switching
> into long mode due to interrupt delivery, and AMD CPUs leave them set
> just to mess with us.
 
Interesting thought. I'm not aware of anyone testing mixed mode with
AMD CPUs, so that would be a good data point.

> Also, a WARN_ON(in_interrupt()) somewhere might be a good sanity check.

lockdep should catch this kind of stuff pretty quickly since we grab
the spinlock in every code path.

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web