Hi Bhupesh, On 19/06/2019 22:23, Bhupesh Sharma wrote: > Since most distributions use 'make zinstall' rule inside 'arch/arm64/boot/Makefile' (see > [1] for details) to install the arm64 Image.gz compressed file inside the boot destination > directory (for e.g. /boot), currently we cannot use kexec_file_load() to load vmlinuz (or > Image.gz): It's not just kexec_file_load(), we don't support booting from compressed or elf image formats either: the bootloader has to decompress any Image.gz before it can run it. > ... kernel returns -EINVAL error value, as it is not able to locate the magic number > =0x644d5241, which is expected in the 64-byte header of the decompressed kernel image > I can figure out two ways to address this: > > 1. Add support in user-space kexec-tools (for which I have a RFC patch ready), which > handles an 'Image.gz' being passed via kexec_file_load(), using an approach as follows: > > a). Copy the contents of Image.gz to a temporary file. > b). Decompress (gunzip-decompress) the contents inside the temporary file. > c). Pass the 'fd' of the temporary file to the kernel space. So basically the kernel space > still gets a decompressed kernel image to load via kexec_tools Sounds reasonable. (I guess you need to decompress it first to know the size to pass to kexec_file_load(), hence the intermediate copy) > This seems to have the following pros and cons, which I can think of: > > Pros: > - Changes can be handled in the user-space (kexec_tools) and no changes are required in > kernel space for handling the unsigned/non-secure boot case. > > Cons: > - One obvious issue is how to handle the signed kernel Image.gz, because signature > verification is managed inside the kernel, so handling a signed Image.gz would require > kernel intervention eventually. How do you sign an Image.gz? Isn't the signature written into the PE header? > - Passing decompressed image from user-space requires the kernel to read large amount of > data from the user-space. The kernel can't decompress itself, so this large amount of data has to be moved at some point. > 2. Add support in kernel (for which I have a RFC patch ready), which handles an 'Image.gz' > being passed via kexec_file_load(), using an approach as follows: > > a). Define a 'arch_kexec_kernel_image_probe' for arm64, which overrides the __weak > definition in 'kernel/kexec_file.c' > b). Inside 'arch_kexec_kernel_image_probe' for arm64, check if we have been passed a > magic header 0x1f, 0x8b (\037 \213) which indicates a 'gzip format' Image file. > b). Decompress the contents inside a buffer using a decompress_kernel() -> gunzip() -> > inflate() logic. > > This seems to have the following pros and cons, which I can think of: > > Pros: > - Handling signed Image.gz becomes easier in the kernel itself. I don't follow: you can't boot this, so why would you sign it? > Cons: > - One needs to add a decompress_kernel() -> gunzip() -> inflate() kind-of logic in kernel > space to handle gzipp'ed image for arm64. We support gzipped initramfs so the code already exists. More of a problem is kdump (which we don't yet support), which has to fit in the reserved crashkernel region, and we won't know the size of the compressed image until we've decompressed it. (its just fiddly) > So, I was wondering which approach should be more suitable - fixing this in user-space v/s > fix this in kernel-space. As user-space can do this, I think it should! Thanks, James _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
