Re: [PATCH 2/2] x86/random: Issue a warning if RDRAND or RDSEED fails

[Jason A. Donenfeld]

On Tue, Jan 30, 2024 at 2:45 PM Reshetova, Elena
<elena.reshetova@xxxxxxxxx> wrote:
> No, this is not the case per Intel SDM. I think we can live under a simple
> assumption that both of these instructions can fail not just due to broken
> HW, but also due to enough pressure put into the whole DRBG construction
> that supplies random numbers via RDRAND/RDSEED.

Yea, thought so.

> I guess your concern about DoS here is for the case when we don’t
> trust the host/VMM *and* assume malicious userspace, correct?
> Because in non-confidential computing case, the Linux RNG in such
> case will just use non-RDRAND fallbacks, no DoS will happen and we
> should have enough entropy that is outside of userspace control.

Don't think about the RNG for just one second. The basic principle is
simpler: if you have a
`WARN_ON(unprivd_userspace_triggerable_condition)`, that's usually
considered a DoS - panic_on_warn and such.

> >
> > And if the DoS thing _is_ a concern, and the use case for this WARN_ON
> > in the first place is the trusted computing scenario, so we basically
> > only care about early boot, then one addendum would be to only warn if
> > we're in early boot, which would work because seeding via RDRAND is
> > attempted pretty early on in init.c.
>
> I don’t think we are only concerned with initial early boot and initial seeding.
> What about periodic reseeding of ChaCha CSPRNG? If you don’t get
> RDRAND/RDSEED output during this step, don’t we formally loose the forward
> prediction resistance property of Linux RNG assuming this is the only source
> of entropy that is outside of attacker control?

If you never add new material, and you have the initial seed, then
it's deterministic. But you still mostly can't backtrack if the state
leaks at some future point in time.

Jason