From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from blyat.fensystems.co.uk (blyat.fensystems.co.uk [54.246.183.96])
 by mx.groups.io with SMTP id smtpd.web10.40177.1655796507513123204
 for <devel@edk2.groups.io>;
 Tue, 21 Jun 2022 00:28:28 -0700
Authentication-Results: mx.groups.io;
 dkim=missing; spf=pass (domain: ipxe.org, ip: 54.246.183.96, mailfrom: mcb30@ipxe.org)
Received: from [IPV6:2a00:23c6:5486:8700:eaa7:4ea6:88e4:6f0e] (unknown [IPv6:2a00:23c6:5486:8700:eaa7:4ea6:88e4:6f0e])
	by blyat.fensystems.co.uk (Postfix) with ESMTPSA id 046EE44103;
	Tue, 21 Jun 2022 07:28:22 +0000 (UTC)
Message-ID: <89aade8b-5f79-54a6-9807-edafdc422cad@ipxe.org>
Date: Tue, 21 Jun 2022 08:28:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.2
Subject: Re: [edk2-devel] Discussing how SystemTable and its Pointers should be treated in Rust
To: devel@edk2.groups.io, ayushdevel1325@gmail.com,
 Michael Kubacki <mikuback@linux.microsoft.com>, michael.d.kinney@intel.com,
 jabeena.b.gaibusab@intel.com, Jiewen Yao <jiewen.yao@intel.com>
References: <CA+Yfj7tm8-1omF20eXznHG0b43vagw1VgyWAvpsTn4SZQKfZ-w@mail.gmail.com>
From: "Michael Brown" <mcb30@ipxe.org>
In-Reply-To: <CA+Yfj7tm8-1omF20eXznHG0b43vagw1VgyWAvpsTn4SZQKfZ-w@mail.gmail.com>
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
	blyat.fensystems.co.uk
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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