linux-kernel - Re: [PATCH] random: invalidate crngs and batches on cpuhp teardown

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]

Date:   Mon, 14 Feb 2022 15:00:45 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     LKML <linux-kernel@...r.kernel.org>,
        Dominik Brodowski <linux@...inikbrodowski.net>
Cc:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Sultan Alsawaf <sultan@...neltoast.com>,
        "Theodore Ts'o" <tytso@....edu>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] random: invalidate crngs and batches on cpuhp teardown

Hi Sebastian,

This is the follow up I alluded to in my earlier email. If we get the
cpuhp notifier working correctly, per
<https://lore.kernel.org/lkml/20220214133735.966528-1-Jason@zx2c4.com/>,
then this patch here should be an easy and correct extension.

I was wondering, though, how common this general pattern is, and
whether there's an opportunity at some point down the road for a more
general mechanism. Right now, we have this:

static DEFINE_PER_CPU(struct crng, crngs) = {
    .generation = ULONG_MAX,
    .lock = INIT_LOCAL_LOCK(crngs.lock),
};

What we're running into is that we want the structure to have that
contents immediately after the CPU boots up (which is why this patch
and the previous one sets it during teardown). Maybe other things also
find themselves wanting this too, such that we could have something
called:

static DEFINE_PER_CPU_HPINIT(struct crng, crngs) = {
    .generation = ULONG_MAX,
    .lock = INIT_LOCAL_LOCK(crngs.lock),
};

These would go in a separate linker section, and cpuhp would memcpy
the various sections in at the appropriate time.

Does this seem feasible / desirable? Or is the use case we've found
here actually pretty niche so this wouldn't help with much? Anyhow,
I'm mostly just curious, and intend to move ahead with the approach of
the patch here, but thought I'd mention this.

Jason