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

["Michael Brown" <mcb30@ipxe.org>]

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