linux-kernel - Re: [RFC PATCH] Introduce persistent memory pool

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: <122aefbf-0ed7-cdd3-5c0a-3d1c51429598@redhat.com>
Date:   Thu, 31 Aug 2023 16:18:48 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>
Cc:     Stanislav Kinsburskii <stanislav.kinsburskii@...il.com>,
        Derek Kiernan <derek.kiernan@....com>,
        Dragan Cvetic <dragan.cvetic@....com>,
        Arnd Bergmann <arnd@...db.de>, Wei Liu <wei.liu@...nel.org>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Madhavan Venkataraman <madvenka@...ux.microsoft.com>,
        Anthony Yznaga <anthony.yznaga@...cle.com>,
        "Mike Rapoport (IBM)" <rppt@...nel.org>,
        James Gowans <jgowans@...zon.com>,
        Anirudh Rayabharam <anrayabh@...ux.microsoft.com>,
        Jinank Jain <jinankjain@...ux.microsoft.com>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] Introduce persistent memory pool

On 8/26/23 22:04, Greg Kroah-Hartman wrote:
>> Yeah, I guess the "ABI" word in misleading here, especially the first
>> letter. I mean something else: the old kernel/new kernel.
>> This persistent memory pool (its metadata) is supposed to be passed
>> across kexec with the data. That is probably the main difference in
>> comparison to pmem or cma.
>> Since the header can change its format between kernels, there should be
>> a way to identify it.
> 
> Ah.  Hah, that's crazy, and it's never going to work, you need to just
> test the version of the kernel that the image was created for (you have
> that in the kernel already) and verify that it is the same before
> loading the new one.
> 
> That way you never have to worry about any "version number", it's just
> the kernel specific version number instead.

Checking the version of the kernel is not enough because you want to 
support kexec to a newer kernel.

I agree though that a version number is not needed.  In the end this is 
just like a filesystem and you'd better keep it backwards compatible. 
If you think you might need an extra field in the header, you have to 
leave some padding and add a "flags" field that right now is always 
zero.  Or something like that.

Paolo