Hi All,
A fellow laptop user has been looking into efi=novamap requirement. I was sharing with him that I thought only firmware could solve this problem and he has questioned me on that assertion and pointed me to this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=4e46c...
It appears from my reading that efi=novamap is required because: It is fiddly to make the kernel function SetVirtualAddressMap() work correctly on AArch64. Without documentation for the laptops I care about, it does not appear to be a valuable use of time to make SetVirtualAddressMap() work. For now, efi=novamap is a good-enough work-around.
Is that more a more accurate analysis on my part?
best regards, Richard
-- Richard.Henwood@arm.com Server Software Eco-System Tel: +1 512 410 9612 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Wed, 11 Sep 2019 at 16:05, Richard Henwood Richard.Henwood@arm.com wrote:
Hi All,
A fellow laptop user has been looking into efi=novamap requirement. I was sharing with him that I thought only firmware could solve this problem and he has questioned me on that assertion and pointed me to this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=4e46c...
It appears from my reading that efi=novamap is required because: It is fiddly to make the kernel function SetVirtualAddressMap() work correctly on AArch64. Without documentation for the laptops I care about, it does not appear to be a valuable use of time to make SetVirtualAddressMap() work. For now, efi=novamap is a good-enough work-around.
Is that more a more accurate analysis on my part?
Not quite.
SetVirtualAddressMap() is a service provided by the firmware *to* the OS.
The Qualcomm implementation inadvertently depends on certain behavior of the Windows loader, and when another EFI compliant loader calls it, the system crashes. Fortunately, (and this is what the patch argues), SetVirtualAddressMap() does not actually do anything useful for us, so we can simply omit calling it, and things work fine.
On Wed, 11 Sep 2019, Ard Biesheuvel wrote:
On Wed, 11 Sep 2019 at 16:05, Richard Henwood Richard.Henwood@arm.com wrote:
Hi All,
A fellow laptop user has been looking into efi=novamap requirement. I was sharing with him that I thought only firmware could solve this problem and he has questioned me on that assertion and pointed me to this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=4e46c...
It appears from my reading that efi=novamap is required because: It is fiddly to make the kernel function SetVirtualAddressMap() work correctly on AArch64. Without documentation for the laptops I care about, it does not appear to be a valuable use of time to make SetVirtualAddressMap() work. For now, efi=novamap is a good-enough work-around.
Is that more a more accurate analysis on my part?
Not quite.
SetVirtualAddressMap() is a service provided by the firmware *to* the OS.
The Qualcomm implementation inadvertently depends on certain behavior of the Windows loader, and when another EFI compliant loader calls it, the system crashes. Fortunately, (and this is what the patch argues), SetVirtualAddressMap() does not actually do anything useful for us, so we can simply omit calling it, and things work fine.
Can we explore the following:
"So the obvious fix is to stop calling SetVirtualAddressMap() altogether on arm64 systems."
What are the possible implications for such an endeavour?
On Thu, 19 Sep 2019 at 13:36, Lee Jones lee.jones@linaro.org wrote:
On Wed, 11 Sep 2019, Ard Biesheuvel wrote:
On Wed, 11 Sep 2019 at 16:05, Richard Henwood Richard.Henwood@arm.com wrote:
Hi All,
A fellow laptop user has been looking into efi=novamap requirement. I was sharing with him that I thought only firmware could solve this problem and he has questioned me on that assertion and pointed me to this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=4e46c...
It appears from my reading that efi=novamap is required because: It is fiddly to make the kernel function SetVirtualAddressMap() work correctly on AArch64. Without documentation for the laptops I care about, it does not appear to be a valuable use of time to make SetVirtualAddressMap() work. For now, efi=novamap is a good-enough work-around.
Is that more a more accurate analysis on my part?
Not quite.
SetVirtualAddressMap() is a service provided by the firmware *to* the OS.
The Qualcomm implementation inadvertently depends on certain behavior of the Windows loader, and when another EFI compliant loader calls it, the system crashes. Fortunately, (and this is what the patch argues), SetVirtualAddressMap() does not actually do anything useful for us, so we can simply omit calling it, and things work fine.
Can we explore the following:
"So the obvious fix is to stop calling SetVirtualAddressMap() altogether on arm64 systems."
What are the possible implications for such an endeavour?
It is known to break u-boot's EFI implementation. They fixed this in their upstream, but quite a while after their EFI implementation was made available.
So the only thing we might do is set to novamap property by default on some condition, but I am not sure what that condition could be.
Hi All,
On Thu, 2019-09-19 at 13:41 +0300, Ard Biesheuvel wrote:
On Thu, 19 Sep 2019 at 13:36, Lee Jones lee.jones@linaro.org wrote:
On Wed, 11 Sep 2019, Ard Biesheuvel wrote:
<snip>
SetVirtualAddressMap() is a service provided by the firmware *to* the OS.
The Qualcomm implementation inadvertently depends on certain behavior of the Windows loader, and when another EFI compliant loader calls it, the system crashes. Fortunately, (and this is what the patch argues), SetVirtualAddressMap() does not actually do anything useful for us, so we can simply omit calling it, and things work fine.
Can we explore the following:
"So the obvious fix is to stop calling SetVirtualAddressMap() altogether on arm64 systems."
What are the possible implications for such an endeavour?
It is known to break u-boot's EFI implementation. They fixed this in their upstream, but quite a while after their EFI implementation was made available.
So the only thing we might do is set to novamap property by default on some condition, but I am not sure what that condition could be.
After 5 months of ruminating on this (and various activities in related packages) there is any new thinking on this topic?
best regards, Richard -- Richard.Henwood@arm.com Server Software Eco-System Tel: +1 512 410 9612 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
aarch64-laptops@lists.linaro.org
-
Ard Biesheuvel -
Lee Jones -
Richard Henwood