linux-kernel - Re: [PATCH v8 2/7] kexec: define functions to map and unmap segments

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8504fd93-8fff-4fd9-8d2d-26b4e1e84bee@linux.microsoft.com>
Date: Tue, 25 Feb 2025 10:35:22 -0800
From: steven chen <chenste@...ux.microsoft.com>
To: Baoquan He <bhe@...hat.com>
Cc: zohar@...ux.ibm.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
Subject: Re: [PATCH v8 2/7] kexec: define functions to map and unmap segments

On 2/24/2025 4:18 PM, Baoquan He wrote:
> On 02/24/25 at 03:05pm, steven chen wrote:
>> On 2/23/2025 10:14 PM, 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)
>>>
>>> Thanks
>>> Baoquan
>> Hi Baoquan,
>>
>> For IMA, it appears that there are no current issues with TPM PCRs after a
>> kernel soft reboot.
> I mean using KHO to hold in 1st kernel and restore the IMA log in 2nd
> kernel.
>
>> This patches is used to get currently missed IMA measurements during the
>> kexec process copied to new kernel after the kernel soft reboot. I think
>> it's ok to leave it at current location: it will be easy to maintain for
>> IMA.
> Yeah, but I am saying this patchset increase unnecessary code
> complexity in kexec code maintaining.
>
>> Overall, for these patches, do you see any major blockers for kexec?
>>
>> If you have any specific concerns or need further details, please let me
>> know.
> I have no concerns for this patchset implementation itself, I saw you using
> vmap to maping the possible scattered source pages smartly and taking
> the mapped buffer pointers to update later duing kexec jumping. That's very
> great and clever method. BUT I am concerned about the solution, if we
> can make use of the existed way of KHO to implement it more simply. Could
> you please do investigation?

Hi Baoquan,

I will conduct an investigation. Thank you for your comments.

Steven