Comment 6 for bug 1877089
Revision history for this message
| bugproxy (bugproxy) wrote Comment bridged from LTC Bugzilla | #6 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
e3ace39
(Get the code!)
------- Comment From <email address hidden> 2020-05-12 11:56 EDT-------
Hi xnox,
we need a separate flavor because zfcpdump kernels (on pre z15) are limited to 64M of memory. Any stock kernel would run oom in such a constrained environment.
(In reply to comment #11)
> Hm, I'm not sure we can sign the zfcpdump-kernel.
>
> By convention, in Focal, signed kernels enforce signed module loading &
> lockdown that prevents unsigned module loading, kexec unsigned kernels or
> reading arbitrary kernel memory from userspace. And I am under impression
> that zfcpdump kernel/initrd rely on being able to read kernel memory.
hmm... not sure if this is really a problem
* the kernel is build without CONFIG_MODULES so all of the non existing kernel modules are automatically signed
* not sure how lockdown works in detail but zfcpdump only needs access to /proc/vmcore which should still be possible. Otherwise kdump would be broken as well.
* kexec is not needed. init is replaced by a piece of code that simply copies /proc/vmcore to disc and reboots.
> The zfcpdump-kernel flavour currently is built using zfcpdump_defconfig. I
> would be more comfortable if we could use the stock signed kernel image as
> the zfcpdump one, instead of the purpose built one. And include any missing
> modules in the zfcpdump initrd and/or adjust the cmdline to do things like
> PANIC_ON_OOPS=y. But i guess we will not get CONFIG_
> with the stock kernel image.
As said before the stock kernel won't run on a pre z15 machine. On z15 (needed for secure boot anyway) that might be an option as the HSA area (the piece of memory the zfcpdump kernel runs in) was increased to 512M. That's more than usually reserved for a kdump kernel, and should be enough for any stock kernel.
The problem is that zfcpdumps design never considered such an option so it won't run out of the box. Furthermore you would then need to support two different dump methods depending on the machine generation you are running on as long as any pre z15 machine is supported.
I must admit that getting rid of this monstrosity would be great but I don't think it will happen any time soon.
> Does zfcdump work with locked-down kernels?
Not sure never tried.
Philipp