Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 254B5C61DA4 for ; Tue, 14 Feb 2023 05:13:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231480AbjBNFNb (ORCPT ); Tue, 14 Feb 2023 00:13:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231462AbjBNFNJ (ORCPT ); Tue, 14 Feb 2023 00:13:09 -0500 Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F1C5613525 for ; Mon, 13 Feb 2023 21:12:32 -0800 (PST) Received: by angie.orcam.me.uk (Postfix, from userid 500) id A6F4992009C; Tue, 14 Feb 2023 06:12:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 9A5CE92009B; Tue, 14 Feb 2023 05:12:29 +0000 (GMT) Date: Tue, 14 Feb 2023 05:12:29 +0000 (GMT) From: "Maciej W. Rozycki" To: Thomas Gleixner , "Jason A. Donenfeld" cc: Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Kees Cook , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] x86: Use `get_random_u8' for kernel stack offset randomization In-Reply-To: <874jrptmk9.ffs@tglx> Message-ID: References: <874jrptmk9.ffs@tglx> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 13 Feb 2023, Thomas Gleixner wrote: > On Mon, Jan 30 2023 at 21:30, Maciej W. Rozycki wrote: > > > > Therefore switch to our generic entropy source and use `get_random_u8' > > instead, which according to Jason A. Donenfeld is supposed to be fast > > enough: > > > > "Generally it's very very fast, as most cases wind up being only a > > memcpy -- in this case, a single byte copy. So by and large it should > > be suitable. It's fast enough now that most networking things are able > > to use it. And lots of other places where you'd want really high > > performance. So I'd expect it's okay to use here too. And if it is too > > slow, we should figure out how to make it faster. But I don't suspect > > it'll be too slow." > > Please provide numbers on contemporary hardware. Jason, is this something you could help me with to back up your claim? My access to modern x86 gear is limited and I just don't have anything I can randomly fiddle with (I guess an Intel Core 2 Duo T5600 processor back from 2008 doesn't count as "contemporary", does it?). > Up to that point, it's easy enough to just disable that randomization on > 32bit. I think for 32-bit we could just go with `get_random_u8' unconditionally, but if you'd rather I disabled the feature altogether such as in v1 or v2, then I'm happy to resubmit whichever version seems the best, or make yet a different one. Please mind the security implications of RDTSC raised in the discussion though. Thanks for your feedback. Maciej