This patch adds a setjmp implementation for LoongArch.
Signed-off-by: Zhou Yang <zhouyang@loongson.cn>
Signed-off-by: Sun Haiyong <sunhaiyong@loongson.cn>
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The gcc by default assumes executable stack is required if the source
object file doesn't have .note.GNU-stack section in place. If any of the
source objects doesn't incorporate the GNU-stack note, the resulting
program will have executable stack flag set in PT_GNU_STACK program
header to instruct program loader or kernel to set up the executable
stack when program loads to memory.
Usually the .note.GNU-stack section will be generated by gcc
automatically if it finds that executable stack is not required. However
it doesn't take care of generating .note.GNU-stack section for those
object files built from assembler sources. This leads to unnecessary
risk of security of exploiting the executable stack because those
assembler sources don't actually require stack to be executable to work.
The grub-emu and grub-emu-lite are found to flag stack as executable
revealed by execstack tool.
$ mkdir -p build-emu && cd build-emu
$ ../configure --with-platform=emu && make
$ execstack -q grub-core/grub-emu grub-core/grub-emu-lite
X grub-core/grub-emu
X grub-core/grub-emu-lite
This patch will add the missing GNU-stack note to the assembler source
used by both utilities, therefore the result doesn't count on gcc
default behavior and the executable stack is disabled.
$ execstack -q grub-core/grub-emu grub-core/grub-emu-lite
- grub-core/grub-emu
- grub-core/grub-emu-lite
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds support for RISC-V to the grub build system. With this
patch, I can successfully build grub on RISC-V as a UEFI application.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
