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)
We can use this pad[3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad.
Best regards,
Vincent Stehlé System Architect - Arm
[1] https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3] https://mensuel.framapad.org/p/ebbr-call-of-dec-4-abi8?lang=en #135 https://github.com/ARM-software/ebbr/pull/135
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.
Best regards
Heinrich
We can use this pad[3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad.
Best regards,
Vincent Stehlé System Architect - Arm
[1] https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3] https://mensuel.framapad.org/p/ebbr-call-of-dec-4-abi8?lang=en #135 https://github.com/ARM-software/ebbr/pull/135 _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
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?
Best regards, Vincent.
Best regards
Heinrich
We can use this pad[3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad.
Best regards,
Vincent Stehlé System Architect - Arm
[1] https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3] https://mensuel.framapad.org/p/ebbr-call-of-dec-4-abi8?lang=en #135 https://github.com/ARM-software/ebbr/pull/135 _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
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.
Hi,
On 04.12.24 14:50, Ard Biesheuvel wrote:
On Wed, 4 Dec 2024 at 14:42, Vincent Stehlé vincent.stehle@arm.com wrote: 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.
I have been slowly working towards adding EFI loader support to barebox.
I too would prefer that SetVirtualAddressMap is not mandated as to avoid the associated complexity.
Thanks, Ahmad
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On Wed, Dec 4, 2024 at 2:50 PM Ard Biesheuvel ardb@kernel.org wrote:
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.
ConvertPointer() may be used by any runtime driver including those loaded via LoadImage and executed via StartImage().
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.
It is no more a security issued than any other part of the EFI API implementation.
The target of EBBR was to have a basis on which any OS could build, not just Linux.
Best regards
Heinrich
On Wed, 4 Dec 2024 at 15:02, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On Wed, Dec 4, 2024 at 2:50 PM Ard Biesheuvel ardb@kernel.org wrote:
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.
ConvertPointer() may be used by any runtime driver including those loaded via LoadImage and executed via StartImage().
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.
It is no more a security issued than any other part of the EFI API implementation.
Incorrect.
ExitBootServices() is a special case here - it is the last opportunity where memory protections can be modified, as afterwards, the system firmware no longer owns the MMU and page tables.
Given that SetVirtualAddressMap() may need to update global function pointers in read-only data, ExitBootServices() has no choice but to remove the read-only protections from those memory regions, even if SetVirtualAddressMap() is never called.
The target of EBBR was to have a basis on which any OS could build, not just Linux.
I do not dispute that, but I will point out that the EFI specification marks all runtime services as optional at runtime, and for generic OS support, at least the get/set time and get/set variable services should be implemented too.
On Wed, Dec 4, 2024 at 3:50 PM Ard Biesheuvel ardb@kernel.org wrote:
On Wed, 4 Dec 2024 at 15:02, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On Wed, Dec 4, 2024 at 2:50 PM Ard Biesheuvel ardb@kernel.org wrote:
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.
ConvertPointer() may be used by any runtime driver including those
loaded via LoadImage and executed via StartImage().
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.
It is no more a security issued than any other part of the EFI API
implementation.
Incorrect.
ExitBootServices() is a special case here - it is the last opportunity where memory protections can be modified, as afterwards, the system firmware no longer owns the MMU and page tables.
Before returning from ExitBootServices() the firmware should set up the MMU such that relocation is possible, i.e. runtime code must be RWX. Without this compatibility with existing OSes is not given.
It the OS doesn't like it, it can make the EFI runtime code NX again.
If the OS has changed the runtime code to NX, it must reset runtime code to RWX before calling SetVirtualAddressMap() and can revert to NX afterwards.
Given that SetVirtualAddressMap() may need to update global function pointers in read-only data, ExitBootServices() has no choice but to remove the read-only protections from those memory regions, even if SetVirtualAddressMap() is never called.
The target of EBBR was to have a basis on which any OS could build, not
just Linux.
I do not dispute that, but I will point out that the EFI specification marks all runtime services as optional at runtime, and for generic OS support, at least the get/set time and get/set variable services should be implemented too.
The OS typically has its own RTC driver. Variable services cannot be substituted by the OS.
Ilias suggestion is a regression. Up to now we have avoided reducing EBBR functionality in new releases.
Best regards
Heinrich
boot-architecture@lists.linaro.org
-
Ahmad Fatoum -
Ard Biesheuvel -
Heinrich Schuchardt -
Vincent Stehlé