On Wed, 4 Dec 2024 at 14:42, Vincent Stehlé vincent.stehle@arm.com wrote:
On Wed, Dec 04, 2024 at 01:40:10PM +0100, Heinrich Schuchardt wrote:
On 12/4/24 10:01, Vincent Stehlé wrote:
Dear EBBR contributors,
We will have an EBBR call[1] today, Dec 4 at 14h00 UTC.
We have two topics and a pull request on the agenda[2]:
- #135: Prepare for v2.3.0
- HTTP Boot (Ilias)
- Changing SetVirtualAddressMap() + ConvertPointer() to optional and not recommended (Ilias)
This would mean that EBBR firmware is no longer able to boot generic UEFI based operating systems. I would strongly discourage such a change.
If for specific scenarios, e.g. when running current Linux, SetVirtualAddressMap() is not needed, it may be disabled on a project basis but we should not call this EBBR compatible.
Hi Heinrich,
Thank you for your inputs. Ilias will update us on this proposal today hopefully. I understand that you cannot join today, but you will have the minutes and we can have a quick summary next call and continue the discussion by e-mail, too.
On my side I could verify the following aspects:
- Those functions are optional at RunTime in UEFI
- Linux can boot with and without calling SetVirtualAddressMap(), and AFAICT it never calls ConvertPointer()
I thus wonder if your comment about not being able to boot a generic OS without those is maybe a bit too strong?
ConvertPointer() is only used internally by firmware in the implementation of SetVirtualAddressMap(). No OS is supposed to call it, and so the fact that Linux does not call it is expected.
SetVirtualAddressMap() is required for general OS compatibility. However, it is a source of bugs and very difficult to implement correctly. And at the risk of getting ahead of Ilias's pitch, it is a security issue too. So IMHO, EBBR should not get in the way of sound security practices, and at least allow SetVirtualAddressMap() to be omitted.