linux-kernel - Re: [RFC 00/18] Pkernfs: Support persistence for live update

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: <888072e30cc003dbed3f41675242b877246e2f0a.camel@gmail.com>
Date: Tue, 06 Feb 2024 14:55:42 +0000
From: Luca Boccassi <luca.boccassi@...il.com>
To: jgowans@...zon.com
Cc: akpm@...ux-foundation.org, anthony.yznaga@...cle.com,
 brauner@...nel.org,  dwmw@...zon.co.uk, ebiederm@...ssion.com,
 graf@...zon.com, iommu@...ts.linux.dev,  joro@...tes.org,
 jschoenh@...zon.de, kexec@...ts.infradead.org,  kvm@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
 linux-mm@...ck.org, madvenka@...ux.microsoft.com, pbonzini@...hat.com, 
 seanjc@...gle.com, skinsburskii@...ux.microsoft.com,
 steven.sistare@...cle.com,  usama.arif@...edance.com,
 viro@...iv.linux.org.uk, will@...nel.org,  yuleixzhang@...cent.com
Subject: Re: [RFC 00/18] Pkernfs: Support persistence for live update

> Also, the question of a hard separation between
> persistent memory and ephemeral memory, compared to allowing
> arbitrary pages to
> be persisted. Pkernfs does it via a hard separation defined at boot
> time, other
> approaches could make the carving out of persistent pages dynamic.

Speaking from experience here - in Azure (Boost) we have been using
hard-carved out memory areas (DAX devices with ranges configured via
DTB) for persisting state across kexec for ~5 years or so. In a
nutshell: don't, it's a mistake.

It's a constant and consistence source of problems, headaches, issues
and workarounds piled upon workarounds, held together with duct tape
and prayers. It's just not flexible enough for any modern system. For
example, unless _all_ the machines are ridicolously overprovisioned in
terms of memory capacity (and guaranteed to remain so, forever), you
end up wasting enormous amounts of memory.

In Azure we are very much interested in a nice, well-abstracted, first-
class replacement for that setup that allows persisting data across
kexec, and in systemd userspace we'd very much want to use it as well,
but it really, really needs to be dynamic, and avoid the pitfall of
hard-configured carved out chunk.

-- 
Kind regards,
Luca Boccassi