On 10 February 2017 at 10:49, Mark Rutland <mark.rutland@xxxxxxx> wrote: > On Wed, Feb 08, 2017 at 11:55:41AM +0000, Ard Biesheuvel wrote: >> To prevent unintended modifications to the kernel text (malicious or >> otherwise) while running the EFI stub, describe the kernel image as >> two separate sections: a .text section with read-execute permissions, >> covering .text, .rodata and .init.text, and a .data section with >> read-write permissions, covering .init.data, .data and .bss. >> >> This relies on the firmware to actually take the section permission >> flags into account, but this is something that is currently being >> implemented in EDK2, which means we will likely start seeing it in >> the wild between one and two years from now. >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > >> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S >> index b8deffa9e1bf..a93cc2b6f50b 100644 >> --- a/arch/arm64/kernel/vmlinux.lds.S >> +++ b/arch/arm64/kernel/vmlinux.lds.S >> @@ -149,6 +149,9 @@ SECTIONS >> ARM_EXIT_KEEP(EXIT_TEXT) >> } >> >> + . = ALIGN(SZ_4K); >> + __pecoff_data_start = .; >> + > > I understand that the stub needs to split the init text/data since > unlike the kernel it'll map those with separate permissions, but it > feels odd to do this specifically for the EFI stub. > While the init code executes in a *much* more controlled environment than the stub (which invokes various UEFI boot services to load initrds/dtb from block storage, and may do god knows what during ExitBootServices()), I think it is not unreasonable to split the init mapping into rx/rw segments, given that it is the only place where we have a good chunk of memory that is both writable and executable. > Yould it perhaps make more sense to always use separate segments for > init/exit text/data, and also apply the permission split in the kernel? > > With that, I don't think we'd need additional stub-specific linker > script changes. > I will prototype this -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
