Messages in this thread | | | Date | Wed, 2 Nov 2022 07:14:00 +0100 | Subject | Re: [PATCH v2 1/2] x86/boot: robustify calling startup_{32,64}() from the decompressor code | From | Jiri Slaby <> |
| |
On 01. 11. 22, 17:15, Alexander Lobakin wrote: > After commit ce697ccee1a8 ("kbuild: remove head-y syntax"), I > started digging whether x86 is ready for removing this old cruft. > Removing its objects from the list makes the kernel unbootable. > This applies only to bzImage, vmlinux still works correctly. > The reason is that with no strict object order determined by the > linker arguments, not the linker script, startup_64 can be placed > not right at the beginning of the kernel. > Here's vmlinux.map's beginning before removing: > > ffffffff81000000 vmlinux.o:(.head.text) > ffffffff81000000 startup_64 > ffffffff81000070 secondary_startup_64 > ffffffff81000075 secondary_startup_64_no_verify > ffffffff81000160 verify_cpu > > and after: > > ffffffff81000000 vmlinux.o:(.head.text) > ffffffff81000000 pvh_start_xen > ffffffff81000080 startup_64 > ffffffff810000f0 secondary_startup_64 > ffffffff810000f5 secondary_startup_64_no_verify > > Not a problem itself, but the self-extractor code has the address of > that function hardcoded the beginning, not looking onto the ELF > header, which always contains the address of startup_{32,64}(). > > So, instead of doing an "act of blind faith", just take the address > from the ELF header and extract a relative offset to the entry > point. The decompressor function already returns a pointer to the > beginning of the kernel to the Asm code, which then jumps to it, > so add that offset to the return value. > This doesn't change anything for now, but allows to resign from the > "head object list" for x86 and makes sure valid Kbuild or any other > improvements won't break anything here in general. > > Tested-by: Jiri Slaby <jirislaby@kernel.org> > Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
thanks, -- js suse labs
| |