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: <ZMuux5CE1xIR7Mc3@zx2c4.com>
Date:   Thu, 3 Aug 2023 15:42:31 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Mario Limonciello <mario.limonciello@....com>
Cc:     jarkko@...nel.org, peterhuewe@....de, linux-kernel@...r.kernel.org,
        linux-integrity@...r.kernel.org, dragonn@...pl
Subject: Re: [PATCH 2/3] tpm: Add command line for not trusting tpm for RNG

On Wed, Aug 02, 2023 at 08:50:14PM -0500, Mario Limonciello wrote:
> The kernel supports random.cpu=off and random.bootloader=off.
> As TPM RNG is also registered as a hwrng, add the ability to
> prevent registering the TPM RNG.

Please do *not* do this. I agree with Jarkko that this doesn't belong.

Firstly, you're proposing a flag for the tpm driver, so the `random.`
namespace is inappropriate. Do not use the `random.` namespace if you're
not dealing with random.c specifically. Rather, this is very much a
`tpm.register_hwrng=1/0` flag, which describes better what this is about.

Secondly, I think you're making a mountain out of a molehill. You first
wanted to also disable Intel devices too, even though they aren't
affected by this bug. Now you're proposing a way for users to disable
everything. But so far there's no evidence that this matter goes any
further than AMD's fTPM. So let's calm a bit and not make too big deal
of this. If we suddenly get lots of reports that there's broken behavior
across the board, then maybe we should consider something like this. But
insofar as this is just an AMD derp, let's keep it simple and not over
complicate everything with more knobs. Fewer knobs, please!

Finally, with regards to AMD, my hope is that eventually the fTPM
becomes useful as a hwrng, and then we can relax the disabling to
re-enable it for whatever new revision might come to exist in the
future.

Thanks,
Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ