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

Groups > linux.kernel > #1336382 > unrolled thread

[GIT PULL 00/13] EFI changes for v4.6 part 2

Back to article view | Back to linux.kernel

Contents

  [GIT PULL 00/13] EFI changes for v4.6 part 2 Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:40 +0100
    [PATCH 08/13] efi/arm: Check for LPAE support before booting a LPAE kernel Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:40 +0100
      [tip:efi/core] efi/arm: Check for LPAE support before booting a LPAE kernel tip-bot for Ard Biesheuvel <tipbot@zytor.com>@zytor.com - 2016-02-23 10:30 +0100
    [PATCH 11/13] x86/mm/pageattr: Don't implicitly allow _PAGE_RW in kernel_map_pages_in_pgd() Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:40 +0100
      [tip:efi/core] x86/mm/pat: Don't implicitly allow _PAGE_RW in kernel_map_pages_in_pgd() tip-bot for Sai Praneeth <tipbot@zytor.com>@zytor.com - 2016-02-23 10:20 +0100
    [PATCH 05/13] arm64: vmlinux.lds.S: Handle .init.rodata.xxx and .init.bss sections Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:40 +0100
      [tip:efi/core] arm64/vmlinux.lds.S: Handle .init.rodata.xxx and .init.bss sections tip-bot for Ard Biesheuvel <tipbot@zytor.com>@zytor.com - 2016-02-23 10:30 +0100
    [PATCH 03/13] x86/mm/pageattr: Use _PAGE_GLOBAL bit for EFI page table mappings Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:40 +0100
      [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings tip-bot for Sai Praneeth <tipbot@zytor.com>@zytor.com - 2016-02-23 10:20 +0100
        Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Andy Lutomirski <luto@amacapital.net> - 2016-02-23 18:50 +0100
          Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-23 19:10 +0100
            Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Borislav Petkov <bp@alien8.de> - 2016-02-23 19:20 +0100
            Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings "H. Peter Anvin" <hpa@zytor.com> - 2016-02-24 03:20 +0100
            Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings "H. Peter Anvin" <hpa@zytor.com> - 2016-02-24 03:20 +0100
            Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Ingo Molnar <mingo@kernel.org> - 2016-02-25 10:00 +0100
          Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> - 2016-02-24 02:00 +0100
            Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Andy Lutomirski <luto@amacapital.net> - 2016-02-24 03:50 +0100
              Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-24 15:20 +0100
                Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Borislav Petkov <bp@alien8.de> - 2016-02-24 17:30 +0100
                  Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Andy Lutomirski <luto@amacapital.net> - 2016-02-24 17:40 +0100
                    Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-24 20:00 +0100
                      Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-24 20:50 +0100
                        Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Andy Lutomirski <luto@amacapital.net> - 2016-02-24 21:00 +0100
                        Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Sylvain Chouleur <sylvain.chouleur@gmail.com> - 2016-02-29 12:00 +0100
                          Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Matt Fleming <matt@codeblueprint.co.uk> - 2016-03-02 12:30 +0100
                    Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-24 20:40 +0100
                      Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Andy Lutomirski <luto@amacapital.net> - 2016-02-24 21:00 +0100
                        Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Ingo Molnar <mingo@kernel.org> - 2016-02-25 10:10 +0100
                        Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-25 16:30 +0100
                  Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Andy Lutomirski <luto@amacapital.net> - 2016-02-24 17:50 +0100
                  Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Borislav Petkov <bp@alien8.de> - 2016-02-24 17:50 +0100
                Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Andy Lutomirski <luto@amacapital.net> - 2016-02-24 17:50 +0100
                  Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page  table mappings Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-25 17:10 +0100
    [PATCH 07/13] efi/arm-init: Use read-only early mappings Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:40 +0100
      [tip:efi/core] efi/arm-init: Use read-only early mappings tip-bot for Ard Biesheuvel <tipbot@zytor.com>@zytor.com - 2016-02-23 10:30 +0100
    [PATCH 06/13] efi/efistub: Prevent __init annotations from being used Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:40 +0100
      [tip:efi/core] efi/efistub: Prevent __init annotations from being used tip-bot for Ard Biesheuvel <tipbot@zytor.com>@zytor.com - 2016-02-23 10:10 +0100
    [PATCH 02/13] efi/runtime-wrappers: Run UEFI Runtime Services with interrupts enabled Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:40 +0100
      [tip:efi/core] efi/runtime-wrappers: Run UEFI Runtime Services with interrupts enabled tip-bot for Ard Biesheuvel <tipbot@zytor.com>@zytor.com - 2016-02-23 10:30 +0100
    [PATCH 13/13] x86/efi: Only map kernel text for EFI mixed mode Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:40 +0100
      [tip:efi/core] x86/efi: Only map kernel text for EFI mixed mode tip-bot for Sai Praneeth <tipbot@zytor.com>@zytor.com - 2016-02-23 10:20 +0100
    [PATCH 12/13] x86/efi: Map EFI_MEMORY_{XP,RO} memory region bits to EFI page tables Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:40 +0100
      [tip:efi/core] x86/efi: Map EFI_MEMORY_{XP,RO} memory region bits to EFI page tables tip-bot for Sai Praneeth <tipbot@zytor.com>@zytor.com - 2016-02-23 10:20 +0100
    [PATCH 10/13] efi/arm*: Perform hardware compatibility check Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:40 +0100
      [tip:efi/core] efi/arm*: Perform hardware compatibility check tip-bot for Ard Biesheuvel <tipbot@zytor.com>@zytor.com - 2016-02-23 10:30 +0100
    [PATCH 09/13] efi/arm64: Check for h/w support before booting a >4 KB granule kernel Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:40 +0100
      [tip:efi/core] efi/arm64: Check for h/w support before booting a >4 KB granular kernel tip-bot for Ard Biesheuvel <tipbot@zytor.com>@zytor.com - 2016-02-23 10:30 +0100
    [PATCH 01/13] efi: Reformat GUID tables to follow the format in UEFI spec Matt Fleming <matt@codeblueprint.co.uk> - 2016-02-17 13:50 +0100
      [tip:efi/core] efi: Reformat GUID tables to follow the format in UEFI spec tip-bot for Peter Jones <tipbot@zytor.com>@zytor.com - 2016-02-23 10:30 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1342343 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On Wed, Feb 24, 2016 at 8:36 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>
>> So the EFI runtime crap should not change once it is mapped. And those
>> should be global. It is only natural.
>
> Why is it natural?
>
> Long-term, I'd rather see EFI runtime services use an actual mm_struct
> and use_mm.

Definitely.

The EFI runtime page mapping may be unchanging, but that doesn't mean
we should be mapping it all the time - the mapping may not change, but
we will change away from it.

So marking those pages global is very wrong.

                 Linus

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

#1342383 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On Wed, 24 Feb, at 10:56:13AM, Linus Torvalds wrote:
> On Wed, Feb 24, 2016 at 8:36 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> >>
> >> So the EFI runtime crap should not change once it is mapped. And those
> >> should be global. It is only natural.
> >
> > Why is it natural?
> >
> > Long-term, I'd rather see EFI runtime services use an actual mm_struct
> > and use_mm.
> 
> Definitely.
> 
> The EFI runtime page mapping may be unchanging, but that doesn't mean
> we should be mapping it all the time - the mapping may not change, but
> we will change away from it.
 
There is movement towards hanging the EFI memory map off of mm_struct
for x86. ARM and arm64 already do this and there were some patches
from Sylvain (Cc'd) to do this for the purposes of having a task
context that could be preempted while in the middle of an EFI runtime
call for some Intel platforms,

  https://lkml.kernel.org/r/1452702762-27216-4-git-send-email-sylvain.chouleur@gmail.com

Apart from the code simplification and not being required to open-code
the %cr3 diddling, are there other benefits of mm_struct and use_mm()
that make it appealing in the non-preemptible case?

Not that those aren't reasons enough.

> So marking those pages global is very wrong.

Ingo, Andy, how do you want to handle this patch? Maybe just drop it
from tip/efi/core while we prod around making all the EFI mappings
non-global? Nothing else depends on it, it can be dropped without any
harm.

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

#1342399 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On Wed, Feb 24, 2016 at 11:45 AM, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Wed, 24 Feb, at 10:56:13AM, Linus Torvalds wrote:
>> On Wed, Feb 24, 2016 at 8:36 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> >>
>> >> So the EFI runtime crap should not change once it is mapped. And those
>> >> should be global. It is only natural.
>> >
>> > Why is it natural?
>> >
>> > Long-term, I'd rather see EFI runtime services use an actual mm_struct
>> > and use_mm.
>>
>> Definitely.
>>
>> The EFI runtime page mapping may be unchanging, but that doesn't mean
>> we should be mapping it all the time - the mapping may not change, but
>> we will change away from it.
>
> There is movement towards hanging the EFI memory map off of mm_struct
> for x86. ARM and arm64 already do this and there were some patches
> from Sylvain (Cc'd) to do this for the purposes of having a task
> context that could be preempted while in the middle of an EFI runtime
> call for some Intel platforms,
>
>   https://lkml.kernel.org/r/1452702762-27216-4-git-send-email-sylvain.chouleur@gmail.com
>
> Apart from the code simplification and not being required to open-code
> the %cr3 diddling, are there other benefits of mm_struct and use_mm()
> that make it appealing in the non-preemptible case?
>
> Not that those aren't reasons enough.

If we add PCID support, then use_mm will get the benefits (~200ns
savings for a round trip) for free.

>
>> So marking those pages global is very wrong.
>
> Ingo, Andy, how do you want to handle this patch? Maybe just drop it
> from tip/efi/core while we prod around making all the EFI mappings
> non-global? Nothing else depends on it, it can be dropped without any
> harm.

If the patch is harmless as is, I'm okay with letting it stay.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

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

#1345643 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

2016-02-24 20:45 GMT+01:00 Matt Fleming <matt@codeblueprint.co.uk>:
> On Wed, 24 Feb, at 10:56:13AM, Linus Torvalds wrote:
>> On Wed, Feb 24, 2016 at 8:36 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> >>
>> >> So the EFI runtime crap should not change once it is mapped. And those
>> >> should be global. It is only natural.
>> >
>> > Why is it natural?
>> >
>> > Long-term, I'd rather see EFI runtime services use an actual mm_struct
>> > and use_mm.
>>
>> Definitely.
>>
>> The EFI runtime page mapping may be unchanging, but that doesn't mean
>> we should be mapping it all the time - the mapping may not change, but
>> we will change away from it.
>
> There is movement towards hanging the EFI memory map off of mm_struct
> for x86. ARM and arm64 already do this and there were some patches
> from Sylvain (Cc'd) to do this for the purposes of having a task
> context that could be preempted while in the middle of an EFI runtime
> call for some Intel platforms,
>
>   https://lkml.kernel.org/r/1452702762-27216-4-git-send-email-sylvain.chouleur@gmail.com

I was thinking we could use the efi kthread to handle the efi services
generically, not only for the interruptible case, and have a way to decide if we
allow interruptions inside the efi call itself or not.

Then all runtime services would use an mm_struct. The drawback is that you will
need two context switchs to be able to execute the runtime service.

-- 
Sylvain

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

#1347966 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On Mon, 29 Feb, at 11:56:56AM, Sylvain Chouleur wrote:
> 2016-02-24 20:45 GMT+01:00 Matt Fleming <matt@codeblueprint.co.uk>:
> > On Wed, 24 Feb, at 10:56:13AM, Linus Torvalds wrote:
> >> On Wed, Feb 24, 2016 at 8:36 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> >> >>
> >> >> So the EFI runtime crap should not change once it is mapped. And those
> >> >> should be global. It is only natural.
> >> >
> >> > Why is it natural?
> >> >
> >> > Long-term, I'd rather see EFI runtime services use an actual mm_struct
> >> > and use_mm.
> >>
> >> Definitely.
> >>
> >> The EFI runtime page mapping may be unchanging, but that doesn't mean
> >> we should be mapping it all the time - the mapping may not change, but
> >> we will change away from it.
> >
> > There is movement towards hanging the EFI memory map off of mm_struct
> > for x86. ARM and arm64 already do this and there were some patches
> > from Sylvain (Cc'd) to do this for the purposes of having a task
> > context that could be preempted while in the middle of an EFI runtime
> > call for some Intel platforms,
> >
> >   https://lkml.kernel.org/r/1452702762-27216-4-git-send-email-sylvain.chouleur@gmail.com
> 
> I was thinking we could use the efi kthread to handle the efi services
> generically, not only for the interruptible case, and have a way to decide if we
> allow interruptions inside the efi call itself or not.
> 
> Then all runtime services would use an mm_struct. The drawback is that you will
> need two context switchs to be able to execute the runtime service.

I would be surprised if the asynchronous nature of having a special
EFI kthread would buy you any benefit in general. And in fact, in the
efi-pstore code you can be invoked in IRQ context and you really don't
want to start talking to a kthread.

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

#1342371 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On Wed, 24 Feb, at 08:36:33AM, Andy Lutomirski wrote:
> On Wed, Feb 24, 2016 at 8:20 AM, Borislav Petkov <bp@alien8.de> wrote:
> > On Wed, Feb 24, 2016 at 02:10:46PM +0000, Matt Fleming wrote:
> >> > Normally, the only pages with are _PAGE_GLOBAL are those that are in
> >> > the normal kernel mappings (swapper_pg_dir and normal mm_struct pgds).
> >> > By allowing _PAGE_GLOBAL to be set in EFI mappings, you're breaking
> >> > that convention, which forces you to use extra-expensive
> >> > __flush_tlb_all calls in efi_call_virt.
> >
> > Hold on, do you mean the __flush_tlb_all() in the CONFIG_EFI_MIXED code?
> >
> > That's mixed mode. I think you mean the FLUSH_TLB_ALL in efi_call.
> > That's EFI on 64-bit but that is mandated by the spec, AFAIR.
> 
> I mean the one in efi_call_virt.  Why would the spec mandate a TLB
> flush at all?  EFI runtime services have no business touching the
> paging structures directly.  Heck, the 32-bit ones don't even know the
> *format* of the paging structures.
 
Right, and it would necessitate copying out arguments because the
firmware won't understand where/how the kernel has mapped things.

No firmware is going to be doing that.

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

#1342401 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On Wed, Feb 24, 2016 at 11:33 AM, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Wed, 24 Feb, at 08:36:33AM, Andy Lutomirski wrote:
>> On Wed, Feb 24, 2016 at 8:20 AM, Borislav Petkov <bp@alien8.de> wrote:
>> > On Wed, Feb 24, 2016 at 02:10:46PM +0000, Matt Fleming wrote:
>> >> > Normally, the only pages with are _PAGE_GLOBAL are those that are in
>> >> > the normal kernel mappings (swapper_pg_dir and normal mm_struct pgds).
>> >> > By allowing _PAGE_GLOBAL to be set in EFI mappings, you're breaking
>> >> > that convention, which forces you to use extra-expensive
>> >> > __flush_tlb_all calls in efi_call_virt.
>> >
>> > Hold on, do you mean the __flush_tlb_all() in the CONFIG_EFI_MIXED code?
>> >
>> > That's mixed mode. I think you mean the FLUSH_TLB_ALL in efi_call.
>> > That's EFI on 64-bit but that is mandated by the spec, AFAIR.
>>
>> I mean the one in efi_call_virt.  Why would the spec mandate a TLB
>> flush at all?  EFI runtime services have no business touching the
>> paging structures directly.  Heck, the 32-bit ones don't even know the
>> *format* of the paging structures.
>
> Right, and it would necessitate copying out arguments because the
> firmware won't understand where/how the kernel has mapped things.
>
> No firmware is going to be doing that.

Just so I understand correctly: could we get away with putting the EFI
virtual runtime mappings at positive (user) addresses for 64-bit UEFI,
or is there some reason that we need the high bit set?

If we could use positive addresses, then we could use the existing
use_mm infrastructure directly with no funny business at all except to
the extent that we might need to use unusual APIs to set up the VMAs
(if we use real VMAs) in the first place.  (We could cheat and
allocate a single monstrous VM_MIXEDMAP or VM_PFNMAP vma with a .fault
handler that always fails.)  If we have to use negative addresses,
then we'll always be stuck with a funny pgd, but we could still
probably use use_mm instead of manually fiddling with cr3.

Some day I want to experiment with calling runtime services at CPL 3,
too :)  We'd want to add some infrastructure to permit kernel threads
to run through the entry/exit code as if they were user processes, but
there's nothing conceptually wrong with that.  We already allow kernel
threads to call execve and "return" to real user mode, so it's not
much of a stretch.  The main issue would be dealing with signal
handling and such -- we'd want to report faults back to the kernel
thread's CPL3-invocation thunks rather than delivering a signal at CPL
3.

Hmm, now it's time to muse about how the interface would work.  If we
kept it in line with existing practice, we'd add an API to make a
special kernel thread with an attached user context.  To enter CPL3,
you'd return from the thread's main function.  When user mode was done
(fault or syscall), new hooks in the entry code (similar to seccomp
and the die notifier stuff) would re-enter the main function with some
arguments indicating what happened.

If we wanted to make it a bit easier to use, we'd have to allocate an
extra kernel sack, and we could have:

void invoke_cpl3(struct cpl3_context *ctx);

where ctx contains memory for an extra stack as well as a bunch of
data indicating the reason that it returned.

The latter is harder to implement but probably much easier to use.

If anyone wants to work on this, ping me and I'll help and do a bunch of review.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

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

#1343000 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

* Andy Lutomirski <luto@amacapital.net> wrote:

> >> I mean the one in efi_call_virt.  Why would the spec mandate a TLB flush at 
> >> all?  EFI runtime services have no business touching the paging structures 
> >> directly.  Heck, the 32-bit ones don't even know the *format* of the paging 
> >> structures.
> >
> > Right, and it would necessitate copying out arguments because the firmware 
> > won't understand where/how the kernel has mapped things.
> >
> > No firmware is going to be doing that.
> 
> Just so I understand correctly: could we get away with putting the EFI virtual 
> runtime mappings at positive (user) addresses for 64-bit UEFI, or is there some 
> reason that we need the high bit set?
> 
> If we could use positive addresses, then we could use the existing use_mm 
> infrastructure directly with no funny business at all except to the extent that 
> we might need to use unusual APIs to set up the VMAs (if we use real VMAs) in 
> the first place.  (We could cheat and allocate a single monstrous VM_MIXEDMAP or 
> VM_PFNMAP vma with a .fault handler that always fails.)  If we have to use 
> negative addresses, then we'll always be stuck with a funny pgd, but we could 
> still probably use use_mm instead of manually fiddling with cr3.

Would be nice to get an answer to these questions. The more we isolate firmware 
execution into 'regular' MM concepts, the more robust it all becomes.

> Some day I want to experiment with calling runtime services at CPL 3, too :)

That would be an interesting isolation method as well ...

Thanks,

	Ingo

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

#1343270 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On Wed, 24 Feb, at 11:49:23AM, Andy Lutomirski wrote:
> On Wed, Feb 24, 2016 at 11:33 AM, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> > On Wed, 24 Feb, at 08:36:33AM, Andy Lutomirski wrote:
> >> On Wed, Feb 24, 2016 at 8:20 AM, Borislav Petkov <bp@alien8.de> wrote:
> >> > On Wed, Feb 24, 2016 at 02:10:46PM +0000, Matt Fleming wrote:
> >> >> > Normally, the only pages with are _PAGE_GLOBAL are those that are in
> >> >> > the normal kernel mappings (swapper_pg_dir and normal mm_struct pgds).
> >> >> > By allowing _PAGE_GLOBAL to be set in EFI mappings, you're breaking
> >> >> > that convention, which forces you to use extra-expensive
> >> >> > __flush_tlb_all calls in efi_call_virt.
> >> >
> >> > Hold on, do you mean the __flush_tlb_all() in the CONFIG_EFI_MIXED code?
> >> >
> >> > That's mixed mode. I think you mean the FLUSH_TLB_ALL in efi_call.
> >> > That's EFI on 64-bit but that is mandated by the spec, AFAIR.
> >>
> >> I mean the one in efi_call_virt.  Why would the spec mandate a TLB
> >> flush at all?  EFI runtime services have no business touching the
> >> paging structures directly.  Heck, the 32-bit ones don't even know the
> >> *format* of the paging structures.
> >
> > Right, and it would necessitate copying out arguments because the
> > firmware won't understand where/how the kernel has mapped things.
> >
> > No firmware is going to be doing that.
> 
> Just so I understand correctly: could we get away with putting the EFI
> virtual runtime mappings at positive (user) addresses for 64-bit UEFI,
> or is there some reason that we need the high bit set?
 
Good question. There are multiple parts to this answer:

 1) Some firmware is known to break when entered via the identity
    addresses (VA==PA) 

 2) Kexec cares the most about where we map things because the region
    has to be static across Kexec reboots. We do pass the kernel's EFI
    memory map regions between Kexec kernels but that region clearly
    needs to be available across kernel versions

It shouldn't be possible to conflict with userspace mappings or
anything like that because we should never be accessing userspace
addresses during EFI runtime services calls - all relevant data is
copied to a kernel buffer or such. Userspace isn't even mapped now
we've got completely separate EFI page tables.

I don't think there's anything else that would stop us clearing the
high bit and moving the EFI virtual mapping region somewhere else.
Boris?

> If we could use positive addresses, then we could use the existing
> use_mm infrastructure directly with no funny business at all except to
> the extent that we might need to use unusual APIs to set up the VMAs
> (if we use real VMAs) in the first place.  (We could cheat and
> allocate a single monstrous VM_MIXEDMAP or VM_PFNMAP vma with a .fault
> handler that always fails.)  If we have to use negative addresses,
> then we'll always be stuck with a funny pgd, but we could still
> probably use use_mm instead of manually fiddling with cr3.
 
We don't use VMAs at the moment.

Having a custom .fault handler could be a very interesting idea
because we've talked about wanting to do EFI-specific things in the
past if we fault while executing firmware, e.g. printing warnings in
the kernel log indicating the firmware is known to be buggy because it
performed an access not compliant with the spec. See 1) above.

> Some day I want to experiment with calling runtime services at CPL 3,
> too :)  We'd want to add some infrastructure to permit kernel threads
> to run through the entry/exit code as if they were user processes, but
> there's nothing conceptually wrong with that.  We already allow kernel
> threads to call execve and "return" to real user mode, so it's not
> much of a stretch.  The main issue would be dealing with signal
> handling and such -- we'd want to report faults back to the kernel
> thread's CPL3-invocation thunks rather than delivering a signal at CPL
> 3.
 
Right, more isolation is better. I'm not sure we could get all the way
to CPL 3 but I wouldn't begrudge anyone trying.

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

#1342198 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On Wed, Feb 24, 2016 at 8:41 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Feb 24, 2016 at 05:20:02PM +0100, Borislav Petkov wrote:
>> That's mixed mode. I think you mean the FLUSH_TLB_ALL in efi_call.
>> That's EFI on 64-bit but that is mandated by the spec, AFAIR.
>
> Ok, so mfleming set me straight on IRC - that's tip/master I should be
> staring at.
>
> In any case, I think we should do __flush_tlb_all() in efi_call_cirt()
> just in case, for the simple reason that EFI could be installing some
> funky TLB entries which we don't want. I'm not saying it does and it
> probably won't but what's stopping it?
>
> Or am I being overly paranoid?

I think you may be overly paranoid here.  At least no working 32-bit
EFI does this because we run it in compat mode.  Any paging entries it
inserts would be misinterpreted and likely immediately cause a crash.
Also, the EFI code doesn't know a virtual address through which to
reference the paging structures in the first place -- it could read
CR3, but that gives a physical address, and it's not at all clear to
me what even the crazier firmware authors would do with a physical
address that doesn't live in EFI-defined ranges.

--Andy

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

#1342205 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On Wed, Feb 24, 2016 at 05:20:02PM +0100, Borislav Petkov wrote:
> That's mixed mode. I think you mean the FLUSH_TLB_ALL in efi_call.
> That's EFI on 64-bit but that is mandated by the spec, AFAIR.

Ok, so mfleming set me straight on IRC - that's tip/master I should be
staring at.

In any case, I think we should do __flush_tlb_all() in efi_call_cirt()
just in case, for the simple reason that EFI could be installing some
funky TLB entries which we don't want. I'm not saying it does and it
probably won't but what's stopping it?

Or am I being overly paranoid?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

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

#1342202 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On Wed, Feb 24, 2016 at 6:10 AM, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Tue, 23 Feb, at 06:43:04PM, Andy Lutomirski wrote:
>> On Tue, Feb 23, 2016 at 4:50 PM, Sai Praneeth Prakhya
>> <sai.praneeth.prakhya@intel.com> wrote:
>> >
>> > As you rightly said the code is about making a page GLOBAL if PRESENT is
>> > set and we do set PRESENT bit before mapping so that page is GLOBAL.
>> > This code was taken from the other parts of pageattr.c. The point is
>> > that we don't want differences between whether things were mapped in the
>> > EFI page tables directly (i.e. using populate_pte()) or later split from
>> > large pages via the split_large_page() code path. If this is still
>> > confusing could you please elaborate on it further.
>>
>> At least the comment should say "Set the GLOBAL flag if and only
>> if...".  But why is this code here in the first place?  What is
>> passing a pgprot with global unset into this code in the first place?
>
> This comes from populate_pgd(),
>
>   static int populate_pgd(struct cpa_data *cpa, unsigned long addr)
>   {
>           pgprot_t pgprot = __pgprot(_KERNPG_TABLE);

which reminds me: aren't we supposed to *not* set GLOBAL on _PAGE_TABLE entries?

>>
>> You're making a choice of whether to set _PAGE_GLOBAL, and I think
>> you've made the wrong choice.
>>
>> Normally, the only pages with are _PAGE_GLOBAL are those that are in
>> the normal kernel mappings (swapper_pg_dir and normal mm_struct pgds).
>> By allowing _PAGE_GLOBAL to be set in EFI mappings, you're breaking
>> that convention, which forces you to use extra-expensive
>> __flush_tlb_all calls in efi_call_virt.
>>
>> I think you should explicitly *clear* _PAGE_GLOBAL in the EFI mappings
>> instead.  This would allow you to use write_cr3 by itself, which would
>> make the code simpler and faster.
>
> This is interesting.
>
> When I suggested to Sai that he write this patch my main motivation
> was consistency for all mappings. We've got that now, but perhaps it's
> the wrong consistency ;)
>
> If we go with the no-PAGE_GLOBAL approach, we need changes to ensure
> we never set _PAGE_GLOBAL for the EFI mappings, because before this
> patch was applied sometimes we did and sometimes we didn't, depending
> on whether a page was split or not.
>
> I'm racking my brain to think of how your suggestion might have
> unintended consequences because diagnosing stale TLB entry bugs is
> simply the worst job ever. I can't think of anything. The only
> scenarios where we'd see problems is if a) we have new global mappings
> in the EFI page tables or b) we have different global mappings.
>
> Since we reference swapper_pg_dir from the PMD level downwards b)
> shouldn't be a problem, and the only differences between
> swapper_pg_dir and efi_pgd should be the EFI mappings, which saves us
> from a).

:)

Anyway, there's certainly no need to do this right now.

>
>> > This is a valid point. I know that EFI runtime regions persist during
>> > and after boot if we have a UEFI firmware and other commits made EFI
>> > regions have separate page table but I am not clear about the effect of
>> > global flush. I think Matt/Boris could comment on it.
>>
>> It's straightfoward on existing kernels.  If _PAGE_GLOBAL is set, TLB
>> entries persist across cr3 writes.  If _PAGE_GLOBAL is clear, then TLB
>> entries are flushed by cr3 writes.
>
> This is safe for EFI right now because of the big __flush_tlb_all() in
> efi_call_virt().
>
>> With PCID enabled (which is only in a not-quite-ready patch set I
>> have), the story is a bit more complicated, but it works essentially
>> the same way unless you explicitly opt out.
>
> Hmm... is series that posted somewhere?

It's living here:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/pcid

at least until someone figures out how to squash the races in the bookkeeping.

I intentionally never load PCID == 0 with the "don't flush" bit set
specifically so that direct PCID-unaware CR3 loads (like the EFI code
does all over the place) keep working.

>
>> > We touch this code path only when mapping EFI runtime regions to VA
>> > space, i.e. we added pgd field in cpa only as a support for mapping efi
>> > runtime regions.
>>
>> populate_pgd is called from non-EFI code as well though, isn't it?
>
> Nope. The "if (cpa->pgd)" guard ensures that we only call that
> function for the EFI mapping code - no one else sets ->pgd.

OK, although a comment might be nice.

--Andy

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

#1343290 — Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On Wed, 24 Feb, at 08:39:56AM, Andy Lutomirski wrote:
> 
> OK, although a comment might be nice.

Something like this?

---
From ac40fc0269d4d8cc9051982c177ee140d6e1b761 Mon Sep 17 00:00:00 2001
From: Matt Fleming <matt@codeblueprint.co.uk>
Date: Thu, 25 Feb 2016 15:54:50 +0000
Subject: [PATCH] x86/mm/pat: Document the (currently) EFI-only code path

It's not at all obvious that populate_pgd() and friends are only
executed when mapping EFI virtual memory regions or that no other
pageattr callers pass a ->pgd value.

Reported-by: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
---
 arch/x86/mm/pageattr.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 14c38ae80409..8fee5b6f8f66 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1125,8 +1125,14 @@ static int populate_pgd(struct cpa_data *cpa, unsigned long addr)
 static int __cpa_process_fault(struct cpa_data *cpa, unsigned long vaddr,
 			       int primary)
 {
-	if (cpa->pgd)
+	if (cpa->pgd) {
+		/*
+		 * Right now, we only execute this code path when mapping
+		 * the EFI virtual memory map regions, no other users
+		 * provide a ->pgd value. This may change in the future.
+		 */
 		return populate_pgd(cpa, vaddr);
+	}
 
 	/*
 	 * Ignore all non primary paths.
-- 
2.6.2

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

#1336387 — [PATCH 07/13] efi/arm-init: Use read-only early mappings

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>

The early mappings of the EFI system table contents and the UEFI memory
map are read-only from the OS point of view. So map them read-only to
protect them from inadvertent modification.

Acked-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
---
 drivers/firmware/efi/arm-init.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d571b53c..aa1f743152a2 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -61,8 +61,8 @@ static int __init uefi_init(void)
 	char vendor[100] = "unknown";
 	int i, retval;
 
-	efi.systab = early_memremap(efi_system_table,
-				    sizeof(efi_system_table_t));
+	efi.systab = early_memremap_ro(efi_system_table,
+				       sizeof(efi_system_table_t));
 	if (efi.systab == NULL) {
 		pr_warn("Unable to map EFI system table.\n");
 		return -ENOMEM;
@@ -86,8 +86,8 @@ static int __init uefi_init(void)
 			efi.systab->hdr.revision & 0xffff);
 
 	/* Show what we know for posterity */
-	c16 = early_memremap(efi_to_phys(efi.systab->fw_vendor),
-			     sizeof(vendor) * sizeof(efi_char16_t));
+	c16 = early_memremap_ro(efi_to_phys(efi.systab->fw_vendor),
+				sizeof(vendor) * sizeof(efi_char16_t));
 	if (c16) {
 		for (i = 0; i < (int) sizeof(vendor) - 1 && *c16; ++i)
 			vendor[i] = c16[i];
@@ -100,8 +100,8 @@ static int __init uefi_init(void)
 		efi.systab->hdr.revision & 0xffff, vendor);
 
 	table_size = sizeof(efi_config_table_64_t) * efi.systab->nr_tables;
-	config_tables = early_memremap(efi_to_phys(efi.systab->tables),
-				       table_size);
+	config_tables = early_memremap_ro(efi_to_phys(efi.systab->tables),
+					  table_size);
 	if (config_tables == NULL) {
 		pr_warn("Unable to map EFI config table array.\n");
 		retval = -ENOMEM;
@@ -185,7 +185,7 @@ void __init efi_init(void)
 	efi_system_table = params.system_table;
 
 	memmap.phys_map = params.mmap;
-	memmap.map = early_memremap(params.mmap, params.mmap_size);
+	memmap.map = early_memremap_ro(params.mmap, params.mmap_size);
 	if (memmap.map == NULL) {
 		/*
 		* If we are booting via UEFI, the UEFI memory map is the only
-- 
2.6.2

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

#1340464 — [tip:efi/core] efi/arm-init: Use read-only early mappings

Commit-ID:  2eec5dedf770dc85c1fdf6b86873165e61bb1fff
Gitweb:     http://git.kernel.org/tip/2eec5dedf770dc85c1fdf6b86873165e61bb1fff
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Wed, 17 Feb 2016 12:36:00 +0000
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 22 Feb 2016 08:26:27 +0100

efi/arm-init: Use read-only early mappings

The early mappings of the EFI system table contents and the UEFI memory
map are read-only from the OS point of view. So map them read-only to
protect them from inadvertent modification.

Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1455712566-16727-8-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/firmware/efi/arm-init.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d57..aa1f743 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -61,8 +61,8 @@ static int __init uefi_init(void)
 	char vendor[100] = "unknown";
 	int i, retval;
 
-	efi.systab = early_memremap(efi_system_table,
-				    sizeof(efi_system_table_t));
+	efi.systab = early_memremap_ro(efi_system_table,
+				       sizeof(efi_system_table_t));
 	if (efi.systab == NULL) {
 		pr_warn("Unable to map EFI system table.\n");
 		return -ENOMEM;
@@ -86,8 +86,8 @@ static int __init uefi_init(void)
 			efi.systab->hdr.revision & 0xffff);
 
 	/* Show what we know for posterity */
-	c16 = early_memremap(efi_to_phys(efi.systab->fw_vendor),
-			     sizeof(vendor) * sizeof(efi_char16_t));
+	c16 = early_memremap_ro(efi_to_phys(efi.systab->fw_vendor),
+				sizeof(vendor) * sizeof(efi_char16_t));
 	if (c16) {
 		for (i = 0; i < (int) sizeof(vendor) - 1 && *c16; ++i)
 			vendor[i] = c16[i];
@@ -100,8 +100,8 @@ static int __init uefi_init(void)
 		efi.systab->hdr.revision & 0xffff, vendor);
 
 	table_size = sizeof(efi_config_table_64_t) * efi.systab->nr_tables;
-	config_tables = early_memremap(efi_to_phys(efi.systab->tables),
-				       table_size);
+	config_tables = early_memremap_ro(efi_to_phys(efi.systab->tables),
+					  table_size);
 	if (config_tables == NULL) {
 		pr_warn("Unable to map EFI config table array.\n");
 		retval = -ENOMEM;
@@ -185,7 +185,7 @@ void __init efi_init(void)
 	efi_system_table = params.system_table;
 
 	memmap.phys_map = params.mmap;
-	memmap.map = early_memremap(params.mmap, params.mmap_size);
+	memmap.map = early_memremap_ro(params.mmap, params.mmap_size);
 	if (memmap.map == NULL) {
 		/*
 		* If we are booting via UEFI, the UEFI memory map is the only

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

#1336388 — [PATCH 06/13] efi/efistub: Prevent __init annotations from being used

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>

__init annotations should not be used in the EFI stub, since the code is
either included in the decompressor (x86, ARM) where they have no effect,
or the whole stub is __init annotated at the section level (arm64), by
renaming the sections, in which case the __init annotations will be
redundant, and will result in section names like .init.init.text, and our
linker script does not expect that. So un-#define __init so that its
inadvertent use will force a build error.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
---
 drivers/firmware/efi/libstub/efistub.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 6b6548fda089..86ff7bfa6ace 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -5,6 +5,16 @@
 /* error code which can't be mistaken for valid address */
 #define EFI_ERROR	(~0UL)
 
+/*
+ * __init annotations should not be used in the EFI stub, since the code is
+ * either included in the decompressor (x86, ARM) where they have no effect,
+ * or the whole stub is __init annotated at the section level (arm64), by
+ * renaming the sections, in which case the __init annotation will be
+ * redundant, and will result in section names like .init.init.text, and our
+ * linker script does not expect that.
+ */
+#undef __init
+
 void efi_char16_printk(efi_system_table_t *, efi_char16_t *);
 
 efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg, void *__image,
-- 
2.6.2

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

#1340424 — [tip:efi/core] efi/efistub: Prevent __init annotations from being used

Commit-ID:  07e83dbb75865b016f6493c119a30aac7c25051a
Gitweb:     http://git.kernel.org/tip/07e83dbb75865b016f6493c119a30aac7c25051a
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Wed, 17 Feb 2016 12:35:59 +0000
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 22 Feb 2016 08:26:26 +0100

efi/efistub: Prevent __init annotations from being used

__init annotations should not be used in the EFI stub, since the code is
either included in the decompressor (x86, ARM) where they have no effect,
or the whole stub is __init annotated at the section level (arm64), by
renaming the sections.

In the second case the __init annotations will be redundant, and will
result in section names like .init.init.text, and our linker script does
not expect that.

So un-#define __init so that its inadvertent use will force a build error.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1455712566-16727-7-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/firmware/efi/libstub/efistub.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 6b6548f..86ff7bf 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -5,6 +5,16 @@
 /* error code which can't be mistaken for valid address */
 #define EFI_ERROR	(~0UL)
 
+/*
+ * __init annotations should not be used in the EFI stub, since the code is
+ * either included in the decompressor (x86, ARM) where they have no effect,
+ * or the whole stub is __init annotated at the section level (arm64), by
+ * renaming the sections, in which case the __init annotation will be
+ * redundant, and will result in section names like .init.init.text, and our
+ * linker script does not expect that.
+ */
+#undef __init
+
 void efi_char16_printk(efi_system_table_t *, efi_char16_t *);
 
 efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg, void *__image,

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

#1336389 — [PATCH 02/13] efi/runtime-wrappers: Run UEFI Runtime Services with interrupts enabled

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>

The UEFI spec allows Runtime Services to be invoked with interrupts
enabled. The only reason we were disabling interrupts was to prevent
recursive calls into the services on the same CPU, which will lead to
deadlock. However, the only context where such invocations may occur
legally is from efi-pstore via efivars, and that code has been updated
to call a non-blocking alternative when invoked from a non-interruptible
context.

So instead, update the ordinary, blocking UEFI Runtime Services wrappers
to execute with interrupts enabled. This aims to prevent excessive interrupt
latencies on uniprocessor platforms with slow variable stores.

Note that other OSes such as Windows call UEFI Runtime Services with
interrupts enabled as well.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
---
 drivers/firmware/efi/runtime-wrappers.c | 71 +++++++++++++--------------------
 1 file changed, 28 insertions(+), 43 deletions(-)

diff --git a/drivers/firmware/efi/runtime-wrappers.c b/drivers/firmware/efi/runtime-wrappers.c
index 7b8b2f2702ca..de6953039af6 100644
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -63,23 +63,21 @@ static DEFINE_SPINLOCK(efi_runtime_lock);
 
 static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(get_time, tm, tc);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
 static efi_status_t virt_efi_set_time(efi_time_t *tm)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(set_time, tm);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -87,23 +85,21 @@ static efi_status_t virt_efi_get_wakeup_time(efi_bool_t *enabled,
 					     efi_bool_t *pending,
 					     efi_time_t *tm)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(get_wakeup_time, enabled, pending, tm);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
 static efi_status_t virt_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(set_wakeup_time, enabled, tm);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -113,13 +109,12 @@ static efi_status_t virt_efi_get_variable(efi_char16_t *name,
 					  unsigned long *data_size,
 					  void *data)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(get_variable, name, vendor, attr, data_size,
 			       data);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -127,12 +122,11 @@ static efi_status_t virt_efi_get_next_variable(unsigned long *name_size,
 					       efi_char16_t *name,
 					       efi_guid_t *vendor)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(get_next_variable, name_size, name, vendor);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -142,13 +136,12 @@ static efi_status_t virt_efi_set_variable(efi_char16_t *name,
 					  unsigned long data_size,
 					  void *data)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(set_variable, name, vendor, attr, data_size,
 			       data);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -157,15 +150,14 @@ virt_efi_set_variable_nonblocking(efi_char16_t *name, efi_guid_t *vendor,
 				  u32 attr, unsigned long data_size,
 				  void *data)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	if (!spin_trylock_irqsave(&efi_runtime_lock, flags))
+	if (!spin_trylock(&efi_runtime_lock))
 		return EFI_NOT_READY;
 
 	status = efi_call_virt(set_variable, name, vendor, attr, data_size,
 			       data);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -175,16 +167,15 @@ static efi_status_t virt_efi_query_variable_info(u32 attr,
 						 u64 *remaining_space,
 						 u64 *max_variable_size)
 {
-	unsigned long flags;
 	efi_status_t status;
 
 	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
 		return EFI_UNSUPPORTED;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(query_variable_info, attr, storage_space,
 			       remaining_space, max_variable_size);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -194,29 +185,27 @@ virt_efi_query_variable_info_nonblocking(u32 attr,
 					 u64 *remaining_space,
 					 u64 *max_variable_size)
 {
-	unsigned long flags;
 	efi_status_t status;
 
 	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
 		return EFI_UNSUPPORTED;
 
-	if (!spin_trylock_irqsave(&efi_runtime_lock, flags))
+	if (!spin_trylock(&efi_runtime_lock))
 		return EFI_NOT_READY;
 
 	status = efi_call_virt(query_variable_info, attr, storage_space,
 			       remaining_space, max_variable_size);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
 static efi_status_t virt_efi_get_next_high_mono_count(u32 *count)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(get_next_high_mono_count, count);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -225,26 +214,23 @@ static void virt_efi_reset_system(int reset_type,
 				  unsigned long data_size,
 				  efi_char16_t *data)
 {
-	unsigned long flags;
-
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	__efi_call_virt(reset_system, reset_type, status, data_size, data);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 }
 
 static efi_status_t virt_efi_update_capsule(efi_capsule_header_t **capsules,
 					    unsigned long count,
 					    unsigned long sg_list)
 {
-	unsigned long flags;
 	efi_status_t status;
 
 	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
 		return EFI_UNSUPPORTED;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(update_capsule, capsules, count, sg_list);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -253,16 +239,15 @@ static efi_status_t virt_efi_query_capsule_caps(efi_capsule_header_t **capsules,
 						u64 *max_size,
 						int *reset_type)
 {
-	unsigned long flags;
 	efi_status_t status;
 
 	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
 		return EFI_UNSUPPORTED;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(query_capsule_caps, capsules, count, max_size,
 			       reset_type);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
-- 
2.6.2

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

#1340460 — [tip:efi/core] efi/runtime-wrappers: Run UEFI Runtime Services with interrupts enabled

Commit-ID:  fe3244945c47161e2486412d6412c87ba279305d
Gitweb:     http://git.kernel.org/tip/fe3244945c47161e2486412d6412c87ba279305d
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Wed, 17 Feb 2016 12:35:55 +0000
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 22 Feb 2016 08:26:25 +0100

efi/runtime-wrappers: Run UEFI Runtime Services with interrupts enabled

The UEFI spec allows Runtime Services to be invoked with interrupts
enabled. The only reason we were disabling interrupts was to prevent
recursive calls into the services on the same CPU, which will lead to
deadlock. However, the only context where such invocations may occur
legally is from efi-pstore via efivars, and that code has been updated
to call a non-blocking alternative when invoked from a non-interruptible
context.

So instead, update the ordinary, blocking UEFI Runtime Services wrappers
to execute with interrupts enabled. This aims to prevent excessive interrupt
latencies on uniprocessor platforms with slow variable stores.

Note that other OSes such as Windows call UEFI Runtime Services with
interrupts enabled as well.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1455712566-16727-3-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/firmware/efi/runtime-wrappers.c | 71 +++++++++++++--------------------
 1 file changed, 28 insertions(+), 43 deletions(-)

diff --git a/drivers/firmware/efi/runtime-wrappers.c b/drivers/firmware/efi/runtime-wrappers.c
index 7b8b2f2..de69530 100644
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -63,23 +63,21 @@ static DEFINE_SPINLOCK(efi_runtime_lock);
 
 static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(get_time, tm, tc);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
 static efi_status_t virt_efi_set_time(efi_time_t *tm)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(set_time, tm);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -87,23 +85,21 @@ static efi_status_t virt_efi_get_wakeup_time(efi_bool_t *enabled,
 					     efi_bool_t *pending,
 					     efi_time_t *tm)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(get_wakeup_time, enabled, pending, tm);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
 static efi_status_t virt_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(set_wakeup_time, enabled, tm);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -113,13 +109,12 @@ static efi_status_t virt_efi_get_variable(efi_char16_t *name,
 					  unsigned long *data_size,
 					  void *data)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(get_variable, name, vendor, attr, data_size,
 			       data);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -127,12 +122,11 @@ static efi_status_t virt_efi_get_next_variable(unsigned long *name_size,
 					       efi_char16_t *name,
 					       efi_guid_t *vendor)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(get_next_variable, name_size, name, vendor);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -142,13 +136,12 @@ static efi_status_t virt_efi_set_variable(efi_char16_t *name,
 					  unsigned long data_size,
 					  void *data)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(set_variable, name, vendor, attr, data_size,
 			       data);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -157,15 +150,14 @@ virt_efi_set_variable_nonblocking(efi_char16_t *name, efi_guid_t *vendor,
 				  u32 attr, unsigned long data_size,
 				  void *data)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	if (!spin_trylock_irqsave(&efi_runtime_lock, flags))
+	if (!spin_trylock(&efi_runtime_lock))
 		return EFI_NOT_READY;
 
 	status = efi_call_virt(set_variable, name, vendor, attr, data_size,
 			       data);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -175,16 +167,15 @@ static efi_status_t virt_efi_query_variable_info(u32 attr,
 						 u64 *remaining_space,
 						 u64 *max_variable_size)
 {
-	unsigned long flags;
 	efi_status_t status;
 
 	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
 		return EFI_UNSUPPORTED;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(query_variable_info, attr, storage_space,
 			       remaining_space, max_variable_size);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -194,29 +185,27 @@ virt_efi_query_variable_info_nonblocking(u32 attr,
 					 u64 *remaining_space,
 					 u64 *max_variable_size)
 {
-	unsigned long flags;
 	efi_status_t status;
 
 	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
 		return EFI_UNSUPPORTED;
 
-	if (!spin_trylock_irqsave(&efi_runtime_lock, flags))
+	if (!spin_trylock(&efi_runtime_lock))
 		return EFI_NOT_READY;
 
 	status = efi_call_virt(query_variable_info, attr, storage_space,
 			       remaining_space, max_variable_size);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
 static efi_status_t virt_efi_get_next_high_mono_count(u32 *count)
 {
-	unsigned long flags;
 	efi_status_t status;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(get_next_high_mono_count, count);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -225,26 +214,23 @@ static void virt_efi_reset_system(int reset_type,
 				  unsigned long data_size,
 				  efi_char16_t *data)
 {
-	unsigned long flags;
-
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	__efi_call_virt(reset_system, reset_type, status, data_size, data);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 }
 
 static efi_status_t virt_efi_update_capsule(efi_capsule_header_t **capsules,
 					    unsigned long count,
 					    unsigned long sg_list)
 {
-	unsigned long flags;
 	efi_status_t status;
 
 	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
 		return EFI_UNSUPPORTED;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(update_capsule, capsules, count, sg_list);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 
@@ -253,16 +239,15 @@ static efi_status_t virt_efi_query_capsule_caps(efi_capsule_header_t **capsules,
 						u64 *max_size,
 						int *reset_type)
 {
-	unsigned long flags;
 	efi_status_t status;
 
 	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
 		return EFI_UNSUPPORTED;
 
-	spin_lock_irqsave(&efi_runtime_lock, flags);
+	spin_lock(&efi_runtime_lock);
 	status = efi_call_virt(query_capsule_caps, capsules, count, max_size,
 			       reset_type);
-	spin_unlock_irqrestore(&efi_runtime_lock, flags);
+	spin_unlock(&efi_runtime_lock);
 	return status;
 }
 

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

#1336390 — [PATCH 13/13] x86/efi: Only map kernel text for EFI mixed mode

From: Sai Praneeth <sai.praneeth.prakhya@intel.com>

The correct symbol to use when figuring out the size of the kernel
text is '_etext', not '_end' which is the symbol for the entire kernel
image includes data and debug sections.

Cc: Borislav Petkov <bp@alien8.de>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Ravi Shankar <ravi.v.shankar@intel.com>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
---
 arch/x86/platform/efi/efi_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 40d2f447a9dd..49e4dd4a1f58 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -275,7 +275,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
 	efi_scratch.phys_stack = virt_to_phys(page_address(page));
 	efi_scratch.phys_stack += PAGE_SIZE; /* stack grows down */
 
-	npages = (_end - _text) >> PAGE_SHIFT;
+	npages = (_etext - _text) >> PAGE_SHIFT;
 	text = __pa(_text);
 	pfn = text >> PAGE_SHIFT;
 
-- 
2.6.2

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web