Hi folks,
It seems there is no code to enable stack alignment check in EDK2, while it is required to be enabled according to UEFI spec v2.6, section 2.3.6, page 38.
Shall we find somewhere to enable SA?
Thanks and regards,
Gary (Heyi Guo)
On 20 February 2017 at 06:42, Heyi Guo heyi.guo@linaro.org wrote:
Hi folks,
It seems there is no code to enable stack alignment check in EDK2, while it is required to be enabled according to UEFI spec v2.6, section 2.3.6, page 38.
Shall we find somewhere to enable SA?
SA implies 16 byte alignment of the stack. Are we sure all existing asm code is 16 byte clean?
在 2/20/2017 6:14 PM, Ard Biesheuvel 写道:
On 20 February 2017 at 06:42, Heyi Guo heyi.guo@linaro.org wrote:
Hi folks,
It seems there is no code to enable stack alignment check in EDK2, while it is required to be enabled according to UEFI spec v2.6, section 2.3.6, page 38.
Shall we find somewhere to enable SA?
SA implies 16 byte alignment of the stack. Are we sure all existing asm code is 16 byte clean?
Not sure; but I think it is also an issue if SA is not enabled, for it is not UEFI specification compliant. Please advise.
Thanks,
Gary (Heyi Guo)
On 20 February 2017 at 11:00, Heyi Guo heyi.guo@linaro.org wrote:
在 2/20/2017 6:14 PM, Ard Biesheuvel 写道:
On 20 February 2017 at 06:42, Heyi Guo heyi.guo@linaro.org wrote:
Hi folks,
It seems there is no code to enable stack alignment check in EDK2, while it is required to be enabled according to UEFI spec v2.6, section 2.3.6, page 38.
Shall we find somewhere to enable SA?
SA implies 16 byte alignment of the stack. Are we sure all existing asm code is 16 byte clean?
Not sure; but I think it is also an issue if SA is not enabled, for it is not UEFI specification compliant. Please advise.
Yes, you are correct, we should fix this. But given that we are erring on the side of laxity, it is unlikely that 3rd party images would fail to execute correctly under an EDK2 based UEFI for AArch64 that fails to set the SA bit.
So we need to audit the .S files to check whether they preserve the 16 byte SP alignment in all cases. If this is the case, we can simply update the MMU code to set the SA bit when it enables the MMU.
On Mon, Feb 20, 2017 at 11:03:26AM +0000, Ard Biesheuvel wrote:
On 20 February 2017 at 11:00, Heyi Guo heyi.guo@linaro.org wrote:
在 2/20/2017 6:14 PM, Ard Biesheuvel 写道:
On 20 February 2017 at 06:42, Heyi Guo heyi.guo@linaro.org wrote:
Hi folks,
It seems there is no code to enable stack alignment check in EDK2, while it is required to be enabled according to UEFI spec v2.6, section 2.3.6, page 38.
Shall we find somewhere to enable SA?
SA implies 16 byte alignment of the stack. Are we sure all existing asm code is 16 byte clean?
Not sure; but I think it is also an issue if SA is not enabled, for it is not UEFI specification compliant. Please advise.
Yes, you are correct, we should fix this. But given that we are erring on the side of laxity, it is unlikely that 3rd party images would fail to execute correctly under an EDK2 based UEFI for AArch64 that fails to set the SA bit.
So we need to audit the .S files to check whether they preserve the 16 byte SP alignment in all cases. If this is the case, we can simply update the MMU code to set the SA bit when it enables the MMU.
Yes.
find * -name "*.S" | grep -i Aarch64 | wc -l shows 46 files.
I could create a Jira task and we could split the work between us?
/ Leif
On 20 February 2017 at 11:34, Leif Lindholm leif.lindholm@linaro.org wrote:
On Mon, Feb 20, 2017 at 11:03:26AM +0000, Ard Biesheuvel wrote:
On 20 February 2017 at 11:00, Heyi Guo heyi.guo@linaro.org wrote:
在 2/20/2017 6:14 PM, Ard Biesheuvel 写道:
On 20 February 2017 at 06:42, Heyi Guo heyi.guo@linaro.org wrote:
Hi folks,
It seems there is no code to enable stack alignment check in EDK2, while it is required to be enabled according to UEFI spec v2.6, section 2.3.6, page 38.
Shall we find somewhere to enable SA?
SA implies 16 byte alignment of the stack. Are we sure all existing asm code is 16 byte clean?
Not sure; but I think it is also an issue if SA is not enabled, for it is not UEFI specification compliant. Please advise.
Yes, you are correct, we should fix this. But given that we are erring on the side of laxity, it is unlikely that 3rd party images would fail to execute correctly under an EDK2 based UEFI for AArch64 that fails to set the SA bit.
So we need to audit the .S files to check whether they preserve the 16 byte SP alignment in all cases. If this is the case, we can simply update the MMU code to set the SA bit when it enables the MMU.
Yes.
find * -name "*.S" | grep -i Aarch64 | wc -l shows 46 files.
I could create a Jira task and we could split the work between us?
Yes, please. And I don't mind doing all of them.
On Mon, Feb 20, 2017 at 07:44:08PM +0000, Ard Biesheuvel wrote:
On 20 February 2017 at 11:34, Leif Lindholm leif.lindholm@linaro.org wrote:
On Mon, Feb 20, 2017 at 11:03:26AM +0000, Ard Biesheuvel wrote:
On 20 February 2017 at 11:00, Heyi Guo heyi.guo@linaro.org wrote:
在 2/20/2017 6:14 PM, Ard Biesheuvel 写道:
On 20 February 2017 at 06:42, Heyi Guo heyi.guo@linaro.org wrote:
Hi folks,
It seems there is no code to enable stack alignment check in EDK2, while it is required to be enabled according to UEFI spec v2.6, section 2.3.6, page 38.
Shall we find somewhere to enable SA?
SA implies 16 byte alignment of the stack. Are we sure all existing asm code is 16 byte clean?
Not sure; but I think it is also an issue if SA is not enabled, for it is not UEFI specification compliant. Please advise.
Yes, you are correct, we should fix this. But given that we are erring on the side of laxity, it is unlikely that 3rd party images would fail to execute correctly under an EDK2 based UEFI for AArch64 that fails to set the SA bit.
So we need to audit the .S files to check whether they preserve the 16 byte SP alignment in all cases. If this is the case, we can simply update the MMU code to set the SA bit when it enables the MMU.
Yes.
find * -name "*.S" | grep -i Aarch64 | wc -l shows 46 files.
I could create a Jira task and we could split the work between us?
Yes, please. And I don't mind doing all of them.
I lied - 50 including OpenPlatformPkg.
I've raised LEG-478 and assigned it to you (and another one coming up for the SCTLR change).
/ Leif
-
Ard Biesheuvel -
Heyi Guo -
Leif Lindholm