Date:   Tue, 14 Feb 2023 12:43:10 -0800
From:   "H. Peter Anvin" <hpa@zytor.com>
To:     "Maciej W. Rozycki" <macro@orcam.me.uk>,
        Thomas Gleixner <tglx@linutronix.de>
CC:     Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Kees Cook <keescook@chromium.org>, x86@kernel.org,
        linux-kernel@vger.kernel.org
Subject: =?US-ASCII?Q?Re=3A_=5BPING=5D=5BPATCH_v3=5D_x86=3A_Use_=60get=5Frandom?= =?US-ASCII?Q?=5Fu8=27_for_kernel_stack_offset_randomization?=
User-Agent: K-9 Mail for Android
In-Reply-To: <alpine.DEB.2.21.2302140447190.6368@angie.orcam.me.uk>
References: <alpine.DEB.2.21.2301302011150.55843@angie.orcam.me.uk> <alpine.DEB.2.21.2302122311470.46819@angie.orcam.me.uk> <877cwltmno.ffs@tglx> <alpine.DEB.2.21.2302140447190.6368@angie.orcam.me.uk>
Message-ID: <DDFBF35E-D837-4CDC-8EF8-2CBF75C77901@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On February 13, 2023 8:54:53 PM PST, "Maciej W=2E Rozycki" <macro@orcam=2Em=
e=2Euk> wrote:
>On Mon, 13 Feb 2023, Thomas Gleixner wrote:
>
>> >> For x86 kernel stack offset randomization uses the RDTSC instruction=
,=20
>> >> which according to H=2E Peter Anvin is not a secure source of entrop=
y:
>> >>=20
>> >> "RDTSC isn't a super fast instruction either, but what is *way* more
>> >> significant is that this use of RDTSC is NOT safe: in certain power =
states
>> >> it may very well be that stone number of lower bits of TSC contain n=
o
>> >> entropy at all=2E"
>> >
>> >  Ping for:
>> > <https://lore=2Ekernel=2Eorg/all/alpine=2EDEB=2E2=2E21=2E230130201115=
0=2E55843@angie=2Eorcam=2Eme=2Euk/>=2E
>>=20
>> I'm waiting for you to address Peter Anvins feedback=2E
>
> Do you mean this part:
>
>On Tue, 31 Jan 2023, H=2E Peter Anvin wrote:
>
>> Well, what I said was that masking out the low bits of TSC is not a val=
id use to
>> extract a random(-ish) number this way, because the lower bits may be a=
ffected
>> by quantization=2E Something like a circular multiply using a large pri=
me with a
>> good 0:1 balance can be used to mitigate that=2E
>>=20
>> However, the second part is that subsequent RDTSCs will be highly corre=
lated,
>> and so a CSPRNG is needed if you are actually trying to get reasonable =
security
>> this way =E2=80=93 and, well, we already have one of those=2E
>
>?  Well, I inferred, perhaps incorrectly, from the second paragraph that=
=20
>Peter agrees with my approach (with the CSPRNG being what `get_random_u8'=
=20
>and friends get at)=2E
>
>> You also cite him
>> w/o providing a link to the conversation, so any context is missing=2E
>
> Sorry about that=2E  I put the change heading for the previous iteration=
s=20
>in the change log, but I agree actual web links would've been better:
><https://lore=2Ekernel=2Eorg/all/alpine=2EDEB=2E2=2E21=2E2301081919550=2E=
65308@angie=2Eorcam=2Eme=2Euk/>,
><https://lore=2Ekernel=2Eorg/all/alpine=2EDEB=2E2=2E21=2E2301082113350=2E=
65308@angie=2Eorcam=2Eme=2Euk/>=2E
>
> Please let me know if you need anything else=2E  Thank you for your revi=
ew=2E
>
>  Maciej

No, I do indeed agree=2E We're talking something that is a part of an oper=
ation that is already fairly expensive=2E Now, if RDRAND is available on th=
e hardware then that could be used if someone really wants it to go faster=
=2E=2E=2E but get_random_*() seems saner than doing ad hoc hacks=2E