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 69C6DC54798 for ; Tue, 5 Mar 2024 23:34:15 +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=wg3P2NudIFJKbJAA5kCxJ582uLCTSy/QlDtDz6K6miE=; b=n6hP642vWg+S8x NPb0Wprz83/Jljylq0DMAvRhGbpFLJ5vdFsoxw7kzFS3mowgmQjrGqJfkKOGqJpbKVE2+ys3lj44o 5y5IN7jFUPo/fKfNrQiTmVhW0z0OgCDwYbuHX3YicRYTdhKbcRAKfX0qzbh0Gh6XMxDyPCdjKRj9E jDMOkzgKkfZNyAvVwwW0qZmqvYj/PTOuYHFysBozb5xsFckejOWlYmg9qWBw4kQQLwQCtLPAvn1Mc DggPXfHdeaUjy91I3nh7pQ6X6iZq3kn+yCSl1s5kD81GWY0e5VDozuwczcvtDpyXewKmvgigTQ85F YmzQSzXz17B9yq3IcPUw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rheIL-0000000FdFi-3zaX; Tue, 05 Mar 2024 23:34:01 +0000 Received: from mail-pf1-x431.google.com ([2607:f8b0:4864:20::431]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rheIH-0000000FdCf-3gBv for linux-arm-kernel@lists.infradead.org; Tue, 05 Mar 2024 23:33:59 +0000 Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-6e64a9df6c3so177269b3a.3 for ; Tue, 05 Mar 2024 15:33:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1709681637; x=1710286437; 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=SVqJYG4NwJpbVhIQ4ejb78hlZKAflZdt5zQRCQZdbhg=; b=GSSIBqCgBkqWqHjXmmuS7c0YXvxaHz20j9lcLxIE0IFhvU8YHz1DKFLJYWs15mv1Kf dGkVzX78oEfutDWhz6sGYTyTVKlUZJ48fcA2g9PJg8xH9h06b23PQgRcHL2Nkrio8bUR 4RRxs/pU8SSwbooygzhQ9ODjXUUBs6sX3F2Ss= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709681637; x=1710286437; 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=SVqJYG4NwJpbVhIQ4ejb78hlZKAflZdt5zQRCQZdbhg=; b=Mmm03wjCi3bTVEYCywWJJwBzDytJi0CzjWPPBQMBaTZEBFqqQ9QLL83RnaHTXdEMOA AM+CtTcw2PZN2lKsdi7vQ2BVgpuaaZUtI3NtAMnsBcZp+7+6nDzvnzztJxgRIcAAfeEE qO1O7jzFS/aef+opPkUPF3UqbB8q6bwDuUQsF/rKTH+pnWC69nN+R1nFynIGw9kGjKjM W/pqzNqwEkvqDwgePaLb+EhVQIacjgWrYGpShiAj5o2IAqoiDDi1gRAiIckIaX/OlKCW xFKdJNz67SYpi08sJC0KAsRPjWJXBIU9SME0G0zFRPEpAKLAbbzGBYxXn25z+QZpVUzG pA8g== X-Gm-Message-State: AOJu0YxNiecF+Id+sYIBSAcrKHAD3KTvaW/Fur0NlEnpE6fuUXyN3dUL j/pNVdk+KPFJ57cOmqGFd9kqJlNwYz+v6eiQ3s+vdDA1YEiVFv+pGUU9gKj1mQ== X-Google-Smtp-Source: AGHT+IHQdYS5+xMryfTT1IOdZhcc6rZew5WCVjHi9VllATBYGMQVhc0/wPSb9IRr0q52NcbVnxEBdQ== X-Received: by 2002:a05:6a00:1ac7:b0:6e6:27d3:96ab with SMTP id f7-20020a056a001ac700b006e627d396abmr6963065pfv.16.1709681636969; Tue, 05 Mar 2024 15:33:56 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id r5-20020aa79885000000b006e530aca55asm9524721pfl.123.2024.03.05.15.33.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 15:33:55 -0800 (PST) Date: Tue, 5 Mar 2024 15:33:54 -0800 From: Kees Cook To: Jeremy Linton Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, Jason@zx2c4.com, 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: [PATCH 1/1] arm64: syscall: Direct PRNG kstack randomization Message-ID: <202403051526.0BE26F99E@keescook> References: <20240305221824.3300322-1-jeremy.linton@arm.com> <20240305221824.3300322-2-jeremy.linton@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240305221824.3300322-2-jeremy.linton@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240305_153358_307768_DADB6B84 X-CRM114-Status: GOOD ( 30.69 ) 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, Mar 05, 2024 at 04:18:24PM -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. > > 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. > > 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. Lets downgrade from get_random_u16() to > prandom_u32_state() under the theory that the danger of someone > guessing the 1 in 32 per call offset, is larger than that of being > able to extract sufficient history to accurately predict future > offsets. Further it should be safer to run with prandom_u32_state than > disabling stack randomization for those subset of applications where the > difference in latency is on the order of ~5X worse. > > Reported-by: James Yang > Reported-by: Shiyou Huang > Signed-off-by: Jeremy Linton > --- > arch/arm64/kernel/syscall.c | 42 ++++++++++++++++++++++++++++++++++++- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c > index 9a70d9746b66..33b3ea4adff8 100644 > --- a/arch/arm64/kernel/syscall.c > +++ b/arch/arm64/kernel/syscall.c > @@ -5,6 +5,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -37,6 +38,45 @@ 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(struct rnd_state, kstackrng); > + > +static u16 kstack_rng(void) > +{ > + u32 rng = prandom_u32_state(this_cpu_ptr(&kstackrng)); > + > + return rng & 0x1ff; > +} > + > +/* Should we reseed? */ > +static int kstack_rng_setup(unsigned int cpu) > +{ > + u32 rng_seed; > + > + /* zero should be avoided as a seed */ > + do { > + rng_seed = get_random_u32(); > + } while (!rng_seed); > + prandom_seed_state(this_cpu_ptr(&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); This will run initial seeding, but don't we need to reseed this with some kind of frequency? Otherwise, seems fine to me. -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel