On Wed, 2025-06-04 at 11:34 +0800, Coiby Xu wrote: > On Thu, May 22, 2025 at 07:08:04AM -0400, Mimi Zohar wrote: > > On Thu, 2025-05-22 at 11:24 +0800, Baoquan He wrote: > > > On 05/21/25 at 08:54am, Mimi Zohar wrote: > > > > On Fri, 2025-05-16 at 08:22 +0800, Baoquan He wrote: > > > > > CC kexec list. > > > > > > > > > > On 05/16/25 at 07:39am, Baoquan He wrote: > > > > > > Kdump kernel doesn't need IMA functionality, and enabling IMA will > > > > > > cost > > > > > > extra memory. It would be very helpful to allow IMA to be disabled > > > > > > for > > > > > > kdump kernel. > > > > > > Thanks a lot for careufl reviewing and great suggestions. > > > > > > > > > > > The real question is not whether kdump needs "IMA", but whether not > > > > enabling > > > > IMA in the kdump kernel could be abused. The comments below don't > > > > address > > > > that question but limit/emphasize, as much as possible, turning IMA off > > > > is > > > > limited to the kdump kernel. > > > > > > Are you suggesting removing below paragraph from patch log because they > > > are redundant? I can remove it in v2 if yes. > > > > "The comments below" was referring to my comments on the patch, not the next > > paragraph. "don't address that question" refers to whether the kdump kernel > > could be abused. > > > > We're trying to close integrity gaps, not add new ones. Verifying the UKI's > > signature addresses the integrity of the initramfs. What about the > > integrity of > > the kdump initramfs (or for that matter the kexec initramfs)? If the kdump > > initramfs was signed, IMA would be able to verify it before the kexec. > > Hi Mimi, > > I thought you were asking that the commit message should address the > question why disabling IMA should be limited to the kdump kernel. It > turns out I misunderstood your concern. > > Currently there is no way provided to verify the kdump initramfs as a > whole file or to verify individual files in the kdump initramfs.
There were multiple attempts to close this integrity gap, but none of them were upstreamed. > > As you have already known, the kdump initramfs is always generated on > the fly and will be re-generated when the dumping target changes or > some important files change. We try to generate a minimal initramfs in > order to save memory. So yes, it's impossible to sign it as a whole file > beforehand. I'm just curious as to how UKI includes the initramfs, if it does, in the signature. > > And since xattrs like security.ima are not supported in the kdump > initramfs, we have no way to use IMA to verify individual file's > integrity. In fact, we have to stop IMA from working otherwise it's > very likely kdump will break. > > So far, I'm not aware of any bug report that complains kdump stops > working because of IMA. So it indicates very few users are trying to use > IMA in kdump. > > If users do have concerns on the integrity of kdump initramfs, I think > we can advice users to make sure the deployed IMA policy will verify the > integrity of the files while they are being collected and copied into > the kdump initramfs by tools like dracut. For now, I'd prefer to leave it as an integrity gap that still needs to be addressed. thanks, Mimi
