lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6828fbeeff42ce962cc0195466760ea136f9c049.camel@linux.ibm.com>
Date: Tue, 04 Mar 2025 11:15:13 -0500
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Baoquan He <bhe@...hat.com>
Cc: steven chen <chenste@...ux.microsoft.com>, stefanb@...ux.ibm.com,
        roberto.sassu@...weicloud.com, roberto.sassu@...wei.com,
        eric.snowberg@...cle.com, ebiederm@...ssion.com, paul@...l-moore.com,
        code@...icks.com, bauermann@...abnow.com,
        linux-integrity@...r.kernel.org, kexec@...ts.infradead.org,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org,
        madvenka@...ux.microsoft.com, nramas@...ux.microsoft.com,
        James.Bottomley@...senpartnership.com, vgoyal@...hat.com,
        dyoung@...hat.com, Mike Rapoport
 <mike.rapoport@...il.com>
Subject: Re: [PATCH v8 2/7] kexec: define functions to map and unmap segments

On Fri, 2025-02-28 at 13:03 +0800, Baoquan He wrote:
> On 02/27/25 at 10:41am, Mimi Zohar wrote:
> > [Cc'ing Mike Rapoport]
> > 
> > On Mon, 2025-02-24 at 14:14 +0800, Baoquan He wrote:
> > > Hi Steve, Mimi,
> > > 
> > > On 02/18/25 at 02:54pm, steven chen wrote:
> > > > Currently, the mechanism to map and unmap segments to the kimage
> > > > structure is not available to the subsystems outside of kexec.  This
> > > > functionality is needed when IMA is allocating the memory segments
> > > > during kexec 'load' operation.  Implement functions to map and unmap
> > > > segments to kimage.
> > > 
> > > I am done with the whole patchset understanding. My concern is if this
> > > TPM PCRs content can be carried over through newly introduced KHO. I can
> > > see that these patchset doesn't introduce too much new code changes,
> > > while if many conponents need do this, kexec reboot will be patched all
> > > over its body and become ugly and hard to maintain.
> > > 
> > > Please check Mike Rapoport's v4 patchset to see if IMA can register
> > > itself to KHO and do somthing during 2nd kernel init to restore those
> > > TPM PCRs content to make sure all measurement logs are read correctly.
> > > [PATCH v4 00/14] kexec: introduce Kexec HandOver (KHO)
> > 
> > Hi Baoquan,
> > 
> > I was hoping to look at Mike's patch set before responding, but perhaps it is
> > better to respond earlier rather than later with my initial thoughts.
> > 
> > The IMA measurement list isn't stored in contiguous memory, but has to be
> > marshalled before being carried across kexec, and then unmarshalled to restore
> > it after the kexec.  Roberto Sassu has been thinking about changing how the IMA
> > measurement list is stored so marshalling/unmarshalling wouldn't be necessary. 
> > Making both this change and using KHO going forward would be a good idea.
> > 
> > However, that sort of change wouldn't be appropriate to backport.  So the
> > question comes down to whether being unable to attest the measurement list,
> > because the measurements are copied too early at kexec load, but the TPM is
> > being extended through kexec exec, is considered a bug.  If that is the case,
> > then I suggest finish cleaning up and upstreaming this patch set so that it
> > could be backported.
> 
> Ah, I understand your concern. There are stable kernels or distros
> kernels which need be taken care of. If then, we can continue to work on
> polishing this patchset, as you have pointed out, there are still room
> in this patchset to improve before merging.

Thanks, Baoquan!

I've already provided feedback on the IMA related patches.  Hopefully that will
be it.

Mimi



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ