Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] The patch fails to enable BTI veneers for the kernel because EFI stub and PI object files explicitly strip the property note. -- --- Patch [7]: [PATCH 07/12] arm64/bti: Advertise BTI in assembly objects --- commit f368db6f176a29dc1fd3803f6ac93282119ab6aa Author: Josh Poimboeuf <[email protected]> arm64/bti: Advertise BTI in assembly objects This commit forces the inclusion of a GNU property note with the BTI bit into every assembly file. This is intended to ensure the linker emits BTI veneers for >128MB kernels by ensuring all input objects have the property. > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index 6b005c8fef706..4eee721c0b278 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -23,6 +23,10 @@ ifeq ($(CONFIG_ARM64_ERRATUM_843419),y) > LDFLAGS_vmlinux += --fix-cortex-a53-843419 > endif > > +ifeq ($(CONFIG_ARM64_BTI_KERNEL),y) > +KBUILD_AFLAGS += -include $(srctree)/arch/arm64/include/asm/bti-note.h > +endif [Severity: High] This isn't a bug introduced by this patch, but will this approach still fail to emit BTI veneers for the kernel? The GNU linker requires all input objects to have the BTI property, but the EFI stub and PI object files explicitly strip the property note before they are linked into vmlinux. In drivers/firmware/efi/libstub/Makefile: STUBCOPY_FLAGS-y += --remove-section=.note.gnu.property And in arch/arm64/kernel/pi/Makefile: $(obj)/%.pi.o: OBJCOPYFLAGS := --prefix-symbols=__pi_ \ --remove-section=.note.gnu.property Since these objects are stripped of the note and linked into vmlinux, will the linker continue to evaluate the global link with objects lacking the BTI property, leaving the original large-kernel crash unresolved? [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=7
