unusual uefi call/mapping problem

unusual uefi call/mapping problem

[Joel Schopp]

I'm working on the Linux kernel implementation of an draft standard that 
has a uefi component.  The interesting part is that the uefi component 
isn't in the uefi runtime table, but instead has a physical address 
stored an ACPI table.  Other than not being in the runtime table it 
behaves exactly like the other runtime services.

After extracting the physical address of the UEFI service we can't 
successfully map it or call it.  I'm sure this is straightforward to 
somebody with experience in this area.  Here's a few of the things I've 
tried unsuccessfully, any pointers here would be appreciated.

1) Call the physical address
efi_call_phys_prelog();
efi_call_phys5(...);
efi_call_phys_epilog();

This generates some nasty scheduling while atomic errors

2) Various methods to map in the physical address into virtual address 
space and then call the virtual address.  All of these have failed.

3) I've started looking at adding an entry to the efi struct and a line 
to efi_enter_virtual_mode(...) with the new function name but haven't 
found the right spot to add an extra entry on to the mmap structure. 
Does this seem like a sane approach?

-Joel Schopp

Re: unusual uefi call/mapping problem

[Greg KH]

On Tue, Apr 16, 2013 at 04:31:17PM -0500, Joel Schopp wrote:
> I'm working on the Linux kernel implementation of an draft standard
> that has a uefi component.

What standard would that be?

> The interesting part is that the uefi
> component isn't in the uefi runtime table, but instead has a
> physical address stored an ACPI table.  Other than not being in the
> runtime table it behaves exactly like the other runtime services.
> 
> After extracting the physical address of the UEFI service we can't
> successfully map it or call it.

You want to call it from the kernel?  Why?  Usually you get a "virtual"
address to call UEFI things, and then use efi_call_virt?(), why can't
you do that here as well?

> I'm sure this is straightforward to
> somebody with experience in this area.  Here's a few of the things
> I've tried unsuccessfully, any pointers here would be appreciated.
> 
> 1) Call the physical address
> efi_call_phys_prelog();
> efi_call_phys5(...);
> efi_call_phys_epilog();
> 
> This generates some nasty scheduling while atomic errors

As it should :)

> 2) Various methods to map in the physical address into virtual
> address space and then call the virtual address.  All of these have
> failed.

Why?  What have you done that failed?  Any pointers to code anywhere?

Are you trying to do this before we switch to virtual mode, or after?

thanks,

greg k-h

Re: unusual uefi call/mapping problem

[Joel Schopp]

Thanks for the quick reply.

>> I'm working on the Linux kernel implementation of an draft standard
>> that has a uefi component.
>
> What standard would that be?

Trusted Computing Group Dynamic Root of Trust Management (D-RTM).


>> After extracting the physical address of the UEFI service we can't
>> successfully map it or call it.
>
> You want to call it from the kernel?  Why?  Usually you get a "virtual"
> address to call UEFI things, and then use efi_call_virt?(), why can't
> you do that here as well?

If I had a virtual address I would be a happy man.  I have a physical 
address and my attempts to turn it into a virtual one that is callable 
have been unfruitful.


>> 2) Various methods to map in the physical address into virtual
>> address space and then call the virtual address.  All of these have
>> failed.
>
> Why?  What have you done that failed?  Any pointers to code anywhere?

Unfortunately I can't release code until after the spec is public.  I 
believe that will happen in a matter of weeks and not months.  Then all 
work will be shared under gpl and we will work on getting it functional 
and acceptable for upstream inclusion.  I realize not being able to post 
code now is very limiting.

>
> Are you trying to do this before we switch to virtual mode, or after?

After.  We are trying to do this well after all userspace has started.

Re: unusual uefi call/mapping problem

[Matthew Garrett]

On Tue, Apr 16, 2013 at 04:31:17PM -0500, Joel Schopp wrote:
> I'm working on the Linux kernel implementation of an draft standard
> that has a uefi component.  The interesting part is that the uefi
> component isn't in the uefi runtime table, but instead has a
> physical address stored an ACPI table.  Other than not being in the
> runtime table it behaves exactly like the other runtime services.

Sigh. Is the spec final yet? Doing this in ACPI is inconvenient - ACPI 
isn't available at the stage where we do early UEFI setup, so it would 
have been much easier if this had been a UEFI table rather than an ACPI 
one.

> 2) Various methods to map in the physical address into virtual
> address space and then call the virtual address.  All of these have
> failed.

If the function pointer to the ACPI table is to a UEFI runtime region, 
the kernel should already have set up a virtual to physical mapping for 
the code. Does SetVirtualAddressMap() update the pointer in the ACPI 
table? If so, you're good to go - just pass it to the appropriate 
efi_call_virt*() wrapper. If not, and if the spec isn't final, go back 
and fix that.

> 3) I've started looking at adding an entry to the efi struct and a
> line to efi_enter_virtual_mode(...) with the new function name but
> haven't found the right spot to add an extra entry on to the mmap
> structure. Does this seem like a sane approach?

You mean the memmap structure? No, you shouldn't need to do that.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

Re: unusual uefi call/mapping problem

[Joel Schopp]

On 04/30/2013 07:52 AM, Matthew Garrett wrote:
> On Tue, Apr 16, 2013 at 04:31:17PM -0500, Joel Schopp wrote:
>> I'm working on the Linux kernel implementation of an draft standard
>> that has a uefi component.  The interesting part is that the uefi
>> component isn't in the uefi runtime table, but instead has a
>> physical address stored an ACPI table.  Other than not being in the
>> runtime table it behaves exactly like the other runtime services.
>
> Sigh. Is the spec final yet? Doing this in ACPI is inconvenient - ACPI
> isn't available at the stage where we do early UEFI setup, so it would
> have been much easier if this had been a UEFI table rather than an ACPI
> one.

The spec appears to currently be in purgatory, finished but not 
published.  Do you happen to know offhand what spec defines the UEFI 
runtime services table?

>
>> 2) Various methods to map in the physical address into virtual
>> address space and then call the virtual address.  All of these have
>> failed.

Turns out there was a bug in the UEFI implementation, I'm pretty sure we 
have a way to map it in and call it now.

>
> If the function pointer to the ACPI table is to a UEFI runtime region,
> the kernel should already have set up a virtual to physical mapping for
> the code. Does SetVirtualAddressMap() update the pointer in the ACPI
> table? If so, you're good to go - just pass it to the appropriate
> efi_call_virt*() wrapper. If not, and if the spec isn't final, go back
> and fix that.
>
>> 3) I've started looking at adding an entry to the efi struct and a
>> line to efi_enter_virtual_mode(...) with the new function name but
>> haven't found the right spot to add an extra entry on to the mmap
>> structure. Does this seem like a sane approach?
>
> You mean the memmap structure? No, you shouldn't need to do that.

Thanks. I won't then.

Re: unusual uefi call/mapping problem

[Matthew Garrett]

On Tue, Apr 30, 2013 at 10:51:45AM -0500, Joel Schopp wrote:
> On 04/30/2013 07:52 AM, Matthew Garrett wrote:
> >On Tue, Apr 16, 2013 at 04:31:17PM -0500, Joel Schopp wrote:
> >>I'm working on the Linux kernel implementation of an draft standard
> >>that has a uefi component.  The interesting part is that the uefi
> >>component isn't in the uefi runtime table, but instead has a
> >>physical address stored an ACPI table.  Other than not being in the
> >>runtime table it behaves exactly like the other runtime services.
> >
> >Sigh. Is the spec final yet? Doing this in ACPI is inconvenient - ACPI
> >isn't available at the stage where we do early UEFI setup, so it would
> >have been much easier if this had been a UEFI table rather than an ACPI
> >one.
> 
> The spec appears to currently be in purgatory, finished but not
> published.  Do you happen to know offhand what spec defines the UEFI
> runtime services table?

That's in the UEFI spec, but it wouldn't be appropriate to put it there. 
Instead, you can add another UEFI table with a different UUID and have a 
pointer to that from the ConfigurationTables pointer in the UEFI system 
table.

> >
> >>2) Various methods to map in the physical address into virtual
> >>address space and then call the virtual address.  All of these have
> >>failed.
> 
> Turns out there was a bug in the UEFI implementation, I'm pretty
> sure we have a way to map it in and call it now.

Cool.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org