Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 11 Jan 2023 17:53:37 -0800
From:   "H. Peter Anvin" <hpa@zytor.com>
To:     "Maciej W. Rozycki" <macro@orcam.me.uk>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>
CC:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v2=5D_x86=3A_Disable_kernel_?= =?US-ASCII?Q?stack_offset_randomization_for_!TSC?=
User-Agent: K-9 Mail for Android
In-Reply-To: <alpine.DEB.2.21.2301120129020.65308@angie.orcam.me.uk>
References: <alpine.DEB.2.21.2301082113350.65308@angie.orcam.me.uk> <Y72CByxvewQv78YH@zx2c4.com> <alpine.DEB.2.21.2301120129020.65308@angie.orcam.me.uk>
Message-ID: <B71587C5-21E8-4F7C-94FB-92E2AA9F840A@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On January 11, 2023 5:34:29 PM PST, "Maciej W=2E Rozycki" <macro@orcam=2Eme=
=2Euk> wrote:
>On Tue, 10 Jan 2023, Jason A=2E Donenfeld wrote:
>
>> > Index: linux-macro/arch/x86/include/asm/entry-common=2Eh
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> > --- linux-macro=2Eorig/arch/x86/include/asm/entry-common=2Eh
>> > +++ linux-macro/arch/x86/include/asm/entry-common=2Eh
>> > @@ -5,6 +5,7 @@
>> >  #include <linux/randomize_kstack=2Eh>
>> >  #include <linux/user-return-notifier=2Eh>
>> > =20
>> > +#include <asm/cpufeature=2Eh>
>> >  #include <asm/nospec-branch=2Eh>
>> >  #include <asm/io_bitmap=2Eh>
>> >  #include <asm/fpu/api=2Eh>
>> > @@ -85,7 +86,8 @@ static inline void arch_exit_to_user_mod
>> >  	 * Therefore, final stack offset entropy will be 5 (x86_64) or
>> >  	 * 6 (ia32) bits=2E
>> >  	 */
>> > -	choose_random_kstack_offset(rdtsc() & 0xFF);
>> > +	if (cpu_feature_enabled(X86_FEATURE_TSC))
>> > +		choose_random_kstack_offset(rdtsc() & 0xFF);
>>=20
>> What would happen if you just called `get_random_u8()` here?
>
> Thank you for your input=2E  I've had a look at the function and it seem=
s a=20
>bit heavyweight compared to a mere single CPU instruction, but I guess wh=
y=20
>not=2E  Do you have any performance figures (in terms of CPU cycles) for =
the=20
>usual cases?  Offhand I'm not sure how I could benchmark it myself=2E
>
> I have made a patch and of course it makes the system boot too, although=
=20
>it's not clear to me how I can actually verify randomisation works=2E  I =
can=20
>assume it does I suppose=2E
>
>  Maciej

Not to mention that we could use rdrand here if it is available (although =
it is slower than rdtsc=2E)

RDTSC isn't a super fast instruction either, but what is *way* more signif=
icant 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 no entropy at =
all=2E

At the very least one should do a rotating multiply with a large (32-bit) =
prime number=2E