linux-kernel - Re: [RFC v3 00/21] Preserved-over-Kexec RAM

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: <ZHf/Os9v2cx97Maw@MiWiFi-R3L-srv>
Date:   Thu, 1 Jun 2023 10:15:22 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Anthony Yznaga <anthony.yznaga@...cle.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, x86@...nel.org,
        hpa@...or.com, dave.hansen@...ux.intel.com, luto@...nel.org,
        peterz@...radead.org, rppt@...nel.org, akpm@...ux-foundation.org,
        ebiederm@...ssion.com, keescook@...omium.org, graf@...zon.com,
        jason.zeng@...el.com, lei.l.li@...el.com,
        steven.sistare@...cle.com, fam.zheng@...edance.com,
        mgalaxy@...mai.com, kexec@...ts.infradead.org
Subject: Re: [RFC v3 00/21] Preserved-over-Kexec RAM

On 04/26/23 at 05:08pm, Anthony Yznaga wrote:
> Sending out this RFC in part to guage community interest.
> This patchset implements preserved-over-kexec memory storage or PKRAM as a
> method for saving memory pages of the currently executing kernel so that
> they may be restored after kexec into a new kernel. The patches are adapted
> from an RFC patchset sent out in 2013 by Vladimir Davydov [1]. They
> introduce the PKRAM kernel API.
> 
> One use case for PKRAM is preserving guest memory and/or auxillary
> supporting data (e.g. iommu data) across kexec to support reboot of the
> host with minimal disruption to the guest. PKRAM provides a flexible way
> for doing this without requiring that the amount of memory used by a fixed
> size created a priori.  Another use case is for databases to preserve their
> block caches in shared memory across reboot.

If so, I have confusions, who can help clarify:
1) Why kexec reboot was introduced, what do we expect kexec reboot to
   do?

2) If we need keep these data and those data, can we not reboot? They
   are definitely located there w/o any concern.

3) What if systems of AI, edge computing, HPC etc also want to carry
   kinds of data from userspace or kernel, system status, registers
   etc when kexec reboot is needed, while enligntened by this patch?

Thanks
Baoquan