All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Heiko Carstens <hca@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand"
Date: Wed, 6 Jul 2022 17:24:49 +0200	[thread overview]
Message-ID: <YsWpQWXVeDFXvq0F@zx2c4.com> (raw)
In-Reply-To: <YsWiSH4BrY5oNJuM@mit.edu>

Hi Ted,

On Wed, Jul 06, 2022 at 10:55:04AM -0400, Theodore Ts'o wrote:
> On Tue, Jul 05, 2022 at 09:01:21PM +0200, Jason A. Donenfeld wrote:
> > Later the thinking evolved. With a properly designed RNG, using RDRAND
> > values alone won't harm anything, even if the outputs are malicious.
> 
> I personally think it's totally fine to remove nordrand.  However, the
> reason why it was there was that there were some rather extreme
> tin-foil-hatters who believed that if (the completely unavailable to
> the public for auditing) RDRAND implementation *were* malicious *and*
> the microcode had access to the register file and/or the instruction
> pipeline, then in theory, a malicious CPU could subvert how the RDRAND
> is mixed into the getrandom output to force a particular output.
> 
> Personally, I've always considered it to be insane, since a much
> easier way to compromise a CPU would be to drop a Minix system hidden
> into the CPU running a web server that had massive security bugs in it
> that were only discovered years later.  And if you don't trust the CPU
> manufacture to that extent, you should probably simply not use CPU's
> from that manufacturer.  :-)

That specific attack scenario is actually something I've fixed over the
last few months, by ensuring that all RDRAND values go through the hash
function. So even if the CPU is super malicious, it'd still need a hash
preimage, which isn't considered to be computable for blake2s.

Minix in the cpu... haha.. surely that would never happen... haha
surely...

Jason

WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Heiko Carstens <hca@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand"
Date: Wed, 6 Jul 2022 17:24:49 +0200	[thread overview]
Message-ID: <YsWpQWXVeDFXvq0F@zx2c4.com> (raw)
In-Reply-To: <YsWiSH4BrY5oNJuM@mit.edu>

Hi Ted,

On Wed, Jul 06, 2022 at 10:55:04AM -0400, Theodore Ts'o wrote:
> On Tue, Jul 05, 2022 at 09:01:21PM +0200, Jason A. Donenfeld wrote:
> > Later the thinking evolved. With a properly designed RNG, using RDRAND
> > values alone won't harm anything, even if the outputs are malicious.
> 
> I personally think it's totally fine to remove nordrand.  However, the
> reason why it was there was that there were some rather extreme
> tin-foil-hatters who believed that if (the completely unavailable to
> the public for auditing) RDRAND implementation *were* malicious *and*
> the microcode had access to the register file and/or the instruction
> pipeline, then in theory, a malicious CPU could subvert how the RDRAND
> is mixed into the getrandom output to force a particular output.
> 
> Personally, I've always considered it to be insane, since a much
> easier way to compromise a CPU would be to drop a Minix system hidden
> into the CPU running a web server that had massive security bugs in it
> that were only discovered years later.  And if you don't trust the CPU
> manufacture to that extent, you should probably simply not use CPU's
> from that manufacturer.  :-)

That specific attack scenario is actually something I've fixed over the
last few months, by ensuring that all RDRAND values go through the hash
function. So even if the CPU is super malicious, it'd still need a hash
preimage, which isn't considered to be computable for blake2s.

Minix in the cpu... haha.. surely that would never happen... haha
surely...

Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-s390@vger.kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>, Will Deacon <will@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	linuxppc-dev@lists.ozlabs.org,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand"
Date: Wed, 6 Jul 2022 17:24:49 +0200	[thread overview]
Message-ID: <YsWpQWXVeDFXvq0F@zx2c4.com> (raw)
In-Reply-To: <YsWiSH4BrY5oNJuM@mit.edu>

Hi Ted,

On Wed, Jul 06, 2022 at 10:55:04AM -0400, Theodore Ts'o wrote:
> On Tue, Jul 05, 2022 at 09:01:21PM +0200, Jason A. Donenfeld wrote:
> > Later the thinking evolved. With a properly designed RNG, using RDRAND
> > values alone won't harm anything, even if the outputs are malicious.
> 
> I personally think it's totally fine to remove nordrand.  However, the
> reason why it was there was that there were some rather extreme
> tin-foil-hatters who believed that if (the completely unavailable to
> the public for auditing) RDRAND implementation *were* malicious *and*
> the microcode had access to the register file and/or the instruction
> pipeline, then in theory, a malicious CPU could subvert how the RDRAND
> is mixed into the getrandom output to force a particular output.
> 
> Personally, I've always considered it to be insane, since a much
> easier way to compromise a CPU would be to drop a Minix system hidden
> into the CPU running a web server that had massive security bugs in it
> that were only discovered years later.  And if you don't trust the CPU
> manufacture to that extent, you should probably simply not use CPU's
> from that manufacturer.  :-)

That specific attack scenario is actually something I've fixed over the
last few months, by ensuring that all RDRAND values go through the hash
function. So even if the CPU is super malicious, it'd still need a hash
preimage, which isn't considered to be computable for blake2s.

Minix in the cpu... haha.. surely that would never happen... haha
surely...

Jason

  reply	other threads:[~2022-07-06 15:25 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-05 19:01 [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand" Jason A. Donenfeld
2022-07-05 19:01 ` Jason A. Donenfeld
2022-07-05 19:01 ` Jason A. Donenfeld
2022-07-05 19:36 ` Borislav Petkov
2022-07-05 19:36   ` Borislav Petkov
2022-07-05 19:36   ` Borislav Petkov
2022-07-05 19:44   ` Jason A. Donenfeld
2022-07-05 19:44     ` Jason A. Donenfeld
2022-07-05 19:44     ` Jason A. Donenfeld
2022-07-05 19:57     ` Borislav Petkov
2022-07-05 19:57       ` Borislav Petkov
2022-07-05 19:57       ` Borislav Petkov
2022-07-05 21:50       ` H. Peter Anvin
2022-07-05 21:50         ` H. Peter Anvin
2022-07-05 21:50         ` H. Peter Anvin
2022-07-05 22:00         ` Borislav Petkov
2022-07-05 22:00           ` Borislav Petkov
2022-07-05 22:00           ` Borislav Petkov
2022-07-05 23:11           ` H. Peter Anvin
2022-07-05 23:11             ` H. Peter Anvin
2022-07-05 23:11             ` H. Peter Anvin
2022-07-06 12:23             ` Borislav Petkov
2022-07-06 12:23               ` Borislav Petkov
2022-07-06 12:23               ` Borislav Petkov
2022-07-06 16:42               ` H. Peter Anvin
2022-07-06 16:42                 ` H. Peter Anvin
2022-07-06 16:42                 ` H. Peter Anvin
2022-07-06  0:28         ` Jason A. Donenfeld
2022-07-06  0:28           ` Jason A. Donenfeld
2022-07-06  0:28           ` Jason A. Donenfeld
2022-07-06  0:32           ` [PATCH v2] random: remove CONFIG_ARCH_RANDOM Jason A. Donenfeld
2022-07-06  0:32             ` Jason A. Donenfeld
2022-07-06  6:41             ` Greg Kroah-Hartman
2022-07-06  6:41               ` Greg Kroah-Hartman
2022-07-06  6:41               ` Greg Kroah-Hartman
2022-07-06  8:40             ` Heiko Carstens
2022-07-06  8:40               ` Heiko Carstens
2022-07-06  8:40               ` Heiko Carstens
2022-07-06 10:54             ` [PATCH v3] " Jason A. Donenfeld
2022-07-06 10:54               ` Jason A. Donenfeld
2022-07-06 12:35               ` Borislav Petkov
2022-07-06 12:35                 ` Borislav Petkov
2022-07-06 12:35                 ` Borislav Petkov
2022-07-06 13:55                 ` Jason A. Donenfeld
2022-07-06 13:55                   ` Jason A. Donenfeld
2022-07-06 13:55                   ` Jason A. Donenfeld
2022-07-06 14:35                   ` [PATCH v4] " Jason A. Donenfeld
2022-07-06 14:35                     ` Jason A. Donenfeld
2022-07-08  0:40                     ` [PATCH v5] " Jason A. Donenfeld
2022-07-08  0:40                       ` Jason A. Donenfeld
2022-07-13 15:46                       ` Catalin Marinas
2022-07-13 15:46                         ` Catalin Marinas
2022-07-13 15:46                         ` Catalin Marinas
2022-07-18 12:53                       ` Michael Ellerman
2022-07-18 12:53                         ` Michael Ellerman
2022-08-12 13:50                       ` Geert Uytterhoeven
2022-08-12 13:50                         ` Geert Uytterhoeven
2022-08-12 13:50                         ` Geert Uytterhoeven
2022-07-06 12:30           ` [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand" Borislav Petkov
2022-07-06 12:30             ` Borislav Petkov
2022-07-06 12:30             ` Borislav Petkov
2022-07-06 14:55 ` Theodore Ts'o
2022-07-06 14:55   ` Theodore Ts'o
2022-07-06 14:55   ` Theodore Ts'o
2022-07-06 15:24   ` Jason A. Donenfeld [this message]
2022-07-06 15:24     ` Jason A. Donenfeld
2022-07-06 15:24     ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YsWpQWXVeDFXvq0F@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=agordeev@linux.ibm.com \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hca@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=tglx@linutronix.de \
    --cc=tytso@mit.edu \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.