From mboxrd@z Thu Jan 1 00:00:00 1970 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 06D00C48BF6 for ; Wed, 21 Feb 2024 06:34:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JBKEyD8wjLAqBZFcA8dsTLxs8bjEZW8t4s7N83eTTps=; b=Djq4SpUMx2JlTj +RqhP9B6SiYGJ8JHWNauNFGYoOwpxBopIi3AcQ57pXjIG0viPHZGPhadgEaMS3Fy/Mv0Q8etj6oY4 BPQkSSwnHRtqqYbg/7FtGnkjjG4/1GZ2ebXIYlU9UA0gZYIYxK76OvUjppYA6FmZK1tHaQeDVRgEG BF8pLU3yq/nUYu7PPce1AmWStzct8gGlZBSRh6/Z9ZJ749cFDelD1cG0e+U1HPmCI36W0YMmK4XcT MMPneWKfwTfY+ZDiRTlRgjPvC8qD6uYMyVydAM3RI2SudebWL7NAwMe8ugqx4lVH5GNE/FbGK3JNt 4NWVtZb4Vnebiz/P/oAA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rcgAs-0000000HLpt-0CUw; Wed, 21 Feb 2024 06:33:46 +0000 Received: from mail-oa1-x36.google.com ([2001:4860:4864:20::36]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rcgAp-0000000HLpT-0Yh1 for linux-arm-kernel@lists.infradead.org; Wed, 21 Feb 2024 06:33:44 +0000 Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-21e6be74db4so2874121fac.2 for ; Tue, 20 Feb 2024 22:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1708497221; x=1709102021; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=nzG1h3rFdE35vHs4nCO34Dzxpa3CLJjuLbNEkFJHymk=; b=K1ki2O1qXEu/z5hApaqUz2ekF+0FdhMJTsZuCHZ/NF8Z/Naq0VTcTWuiR6RSop2raK NigiAn2olsaAjCXEzENppZoTlDo32LehbobR7JJ/oZTyCbntFKBrZgk6459fbf4LpDgu 2k9mD7JHNySyByHBSEn+I4tVW3HHdTEXoCMsA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708497221; x=1709102021; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nzG1h3rFdE35vHs4nCO34Dzxpa3CLJjuLbNEkFJHymk=; b=JZPRmHYcyDIfGe4Iy+oxgCosKE2mwL1IqYCYdApp6HK9wHGaLU9SzHZC9nKOdPpQH3 /NBuewpFB/t9o58WjLBA7PeGIjhGXdtkr6B9500OZ7bOhiGn91oLznmJR0FihzChbJtw SAc28pGnOBGg4XcBnAjOqq0OHNKt34F5iP+XrE9jpTYhQIh4xv6gDMEtOODL0ab508SS /WGAcgjq5lAJiC13QNdpI+gpnqsWA5RsQOAXVOmpFUxkPigkVOHks3cFhaNeVt4Pc4AS 0uIzY9ElpzTqsQ7KHo2w8tJ4UzC0hk62C7mqY+7Nw2M+w4WbwmfPXCi1NFhfZ/1lIZqZ SkNg== X-Gm-Message-State: AOJu0YyOCJWFzhcQfpHRDomu5Pwz6SbxgWqSeYakTtiHJMs+3mS/rZhm zXTcJvuWClqF8PnkH9LRBgVmxOXJXdYRenchLreyPBckHKbp3g9fhr+AFuo7kA== X-Google-Smtp-Source: AGHT+IHS0EkkrYoLQUwOe/rW4LoTJCwu0I6ZorfS97z10oAfJ3Ro71jhHZu8xNKWwV345YFzvVeUNg== X-Received: by 2002:a05:6871:3a2a:b0:21e:d654:5c3f with SMTP id pu42-20020a0568713a2a00b0021ed6545c3fmr8228175oac.37.1708497220277; Tue, 20 Feb 2024 22:33:40 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id n14-20020a635c4e000000b005dc2ca5b667sm6682307pgm.10.2024.02.20.22.33.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Feb 2024 22:33:39 -0800 (PST) Date: Tue, 20 Feb 2024 22:33:39 -0800 From: Kees Cook To: Jeremy Linton , "Jason A. Donenfeld" Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, gustavoars@kernel.org, mark.rutland@arm.com, rostedt@goodmis.org, arnd@arndb.de, broonie@kernel.org, guohui@uniontech.com, Manoj.Iyer@arm.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, James Yang , Shiyou Huang Subject: Re: [RFC] arm64: syscall: Direct PRNG kstack randomization Message-ID: <202402202226.A6817927@keescook> References: <20240221020258.1210148-1-jeremy.linton@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240221020258.1210148-1-jeremy.linton@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240220_223343_220422_358A5631 X-CRM114-Status: GOOD ( 38.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Feb 20, 2024 at 08:02:58PM -0600, Jeremy Linton wrote: > The existing arm64 stack randomization uses the kernel rng to acquire > 5 bits of address space randomization. This is problematic because it > creates non determinism in the syscall path when the rng needs to be > generated or reseeded. This shows up as large tail latencies in some > benchmarks and directly affects the minimum RT latencies as seen by > cyclictest. Some questions: - for benchmarks, why not disable kstack randomization? - if the existing pRNG reseeding is a problem here, why isn't it a problem in the many other places it's used? - I though the pRNG already did out-of-line reseeding? > Other architectures are using timers/cycle counters for this function, > which is sketchy from a randomization perspective because it should be > possible to estimate this value from knowledge of the syscall return > time, and from reading the current value of the timer/counters. The expectation is that it would be, at best, unstable. > So, a poor rng should be better than the cycle counter if it is hard > to extract the stack offsets sufficiently to be able to detect the > PRNG's period. > > So, we can potentially choose a 'better' or larger PRNG, going as far > as using one of the CSPRNGs already in the kernel, but the overhead > increases appropriately. Further, there are a few options for > reseeding, possibly out of the syscall path, but is it even useful in > this case? I'd love to find a way to avoid an pRNG that could be reconstructed given enough samples. (But perhaps this xorshift RNG resists that?) -Kees > Reported-by: James Yang > Reported-by: Shiyou Huang > Signed-off-by: Jeremy Linton > --- > arch/arm64/kernel/syscall.c | 55 ++++++++++++++++++++++++++++++++++++- > 1 file changed, 54 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c > index 9a70d9746b66..70143cb8c7be 100644 > --- a/arch/arm64/kernel/syscall.c > +++ b/arch/arm64/kernel/syscall.c > @@ -37,6 +37,59 @@ static long __invoke_syscall(struct pt_regs *regs, syscall_fn_t syscall_fn) > return syscall_fn(regs); > } > > +#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET > +DEFINE_PER_CPU(u32, kstackrng); > +static u32 xorshift32(u32 state) > +{ > + /* > + * From top of page 4 of Marsaglia, "Xorshift RNGs" > + * This algorithm is intended to have a period 2^32 -1 > + * And should not be used anywhere else outside of this > + * code path. > + */ > + state ^= state << 13; > + state ^= state >> 17; > + state ^= state << 5; > + return state; > +} > + > +static u16 kstack_rng(void) > +{ > + u32 rng = raw_cpu_read(kstackrng); > + > + rng = xorshift32(rng); > + raw_cpu_write(kstackrng, rng); > + return rng & 0x1ff; > +} > + > +/* Should we reseed? */ > +static int kstack_rng_setup(unsigned int cpu) > +{ > + u32 rng_seed; > + > + do { > + rng_seed = get_random_u32(); > + } while (!rng_seed); > + raw_cpu_write(kstackrng, rng_seed); > + return 0; > +} > + > +static int kstack_init(void) > +{ > + int ret; > + > + ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "arm64/cpuinfo:kstackrandomize", > + kstack_rng_setup, NULL); > + if (ret < 0) > + pr_err("kstack: failed to register rng callbacks.\n"); > + return 0; > +} > + > +arch_initcall(kstack_init); > +#else > +static u16 kstack_rng(void) { return 0; } > +#endif /* CONFIG_RANDOMIZE_KSTACK_OFFSET */ > + > static void invoke_syscall(struct pt_regs *regs, unsigned int scno, > unsigned int sc_nr, > const syscall_fn_t syscall_table[]) > @@ -66,7 +119,7 @@ static void invoke_syscall(struct pt_regs *regs, unsigned int scno, > * > * The resulting 5 bits of entropy is seen in SP[8:4]. > */ > - choose_random_kstack_offset(get_random_u16() & 0x1FF); > + choose_random_kstack_offset(kstack_rng()); > } > > static inline bool has_syscall_work(unsigned long flags) > -- > 2.43.0 > -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel