Discussing how SystemTable and its Pointers should be treated in Rust

Discussing how SystemTable and its Pointers should be treated in Rust

[Ayush Singh]

Hello everyone,

I wanted to discuss and get ideas about how I should implement the
various services (like allocator and stdin) for UEFI in Rust. I have
come up with two approaches:

1. Initialize the pointers needed for a module to work early on and
keep them local to the module. This will mean that the allocator
module will store the `allocate_pool` and `free_pool` pointers in a
static private to the module which will be initialized by the std
before the Rust main is run.

2. Only have one global pointer to the SystemTable and pass that to
the functions (like allocate and deallocate) when needed.

I am leaning more towards the first approach right now since it would
mean that we will only need to assert that the local pointer is valid.
However, the 1st approach is a NOGO if it is possible that the
pointers in SysteTable can be changed by UEFI.

By change, I mean that for example the `allocate_pool` pointer in
SystemTable is replaced with a different pointer midway through the
program. In that case, the pointer in the allocator module will become
invalid but the SystemTable will contain the pointer to the new
location of `allocate_pool` and stay valid.

Yours Sincerely,
Ayush Singh

Re: [edk2-devel] Discussing how SystemTable and its Pointers should be treated in Rust

[Michael Brown]

On 21/06/2022 07:04, Ayush Singh wrote:
> 1. Initialize the pointers needed for a module to work early on and
> keep them local to the module. This will mean that the allocator
> module will store the `allocate_pool` and `free_pool` pointers in a
> static private to the module which will be initialized by the std
> before the Rust main is run.
> 
> 2. Only have one global pointer to the SystemTable and pass that to
> the functions (like allocate and deallocate) when needed.
> 
> I am leaning more towards the first approach right now since it would
> mean that we will only need to assert that the local pointer is valid.
> However, the 1st approach is a NOGO if it is possible that the
> pointers in SysteTable can be changed by UEFI.
> 
> By change, I mean that for example the `allocate_pool` pointer in
> SystemTable is replaced with a different pointer midway through the
> program. In that case, the pointer in the allocator module will become
> invalid but the SystemTable will contain the pointer to the new
> location of `allocate_pool` and stay valid.

The UEFI shim will modify the LoadImage, StartImage, Exit, and 
ExitBootServices pointers in SystemTable->BootServices:

https://github.com/rhboot/shim/blob/main/replacements.c#L154-L183

In certain debug modes, iPXE will modify pointers within SystemTable in 
order to implement strace-like functionality for loaded EFI binaries:

https://github.com/ipxe/ipxe/blob/master/src/interface/efi/efi_wrap.c#L1243-L1265

so I would strongly suggest retaining only a pointer to SystemTable and 
dereferencing it at each point of use.

Thanks,

Michael