From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2B0802F2916 for ; Tue, 18 Nov 2025 11:25:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763465111; cv=none; b=ucT9y7tkvv7pLNcnM/eMJ7m2Mqh7zWFj1E00w0zOCVnLuf13pwtBte4Pm0nm6GNGFWWOZQ+p3xO2UeLSnkXgstASjs71IcWTzaYXvLtBpxoM98m3kQ+mbNRKE59TkwRy03Gsdm80LOqMO16cV6gTiFW7+bxJ5hi6Ff2EALVQF7k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763465111; c=relaxed/simple; bh=GJzH1tShpsXBHY6j+sEBLQ6FIbls3JrFm7b/COvywD8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=m6x4SZGKApC6ykilwghGaP32cKBaGKU4g+laNDa4HPBOzJQFzIeX/6OH8WoUTU1LLj4MBivQq/mVNSYIj08ajmHM+/s9AvmS+PdkDpfsyLmOoSIdhvtCMu1U3nksMlExUgDLeIFEUoKm+tX0R+Wg0JdTnxR+iVk3QYZfrXYpTDc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D9645FEC; Tue, 18 Nov 2025 03:25:01 -0800 (PST) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2D9533F66E; Tue, 18 Nov 2025 03:25:08 -0800 (PST) Date: Tue, 18 Nov 2025 11:25:05 +0000 From: Mark Rutland To: Ryan Roberts Cc: Kees Cook , Arnd Bergmann , Ard Biesheuvel , Jeremy Linton , Will Deacon , Catalin Marinas , "linux-arm-kernel@lists.infradead.org" , Linux Kernel Mailing List Subject: Re: [DISCUSSION] kstack offset randomization: bugs and performance Message-ID: References: <66c4e2a0-c7fb-46c2-acce-8a040a71cd8e@arm.com> <202511171221.517FC4F@keescook> <251bcfb4-6069-40f7-be03-0a745bb8f761@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <251bcfb4-6069-40f7-be03-0a745bb8f761@arm.com> On Tue, Nov 18, 2025 at 10:28:29AM +0000, Ryan Roberts wrote: > On 17/11/2025 20:27, Kees Cook wrote: > > On Mon, Nov 17, 2025 at 11:31:22AM +0000, Ryan Roberts wrote: > >> On 17/11/2025 11:30, Ryan Roberts wrote: > The original rationale for a separate choose_random_kstack_offset() at the end > of the syscall is described as: > > * This position in the syscall flow is done to > * frustrate attacks from userspace attempting to learn the next offset: > * - Maximize the timing uncertainty visible from userspace: if the > * offset is chosen at syscall entry, userspace has much more control > * over the timing between choosing offsets. "How long will we be in > * kernel mode?" tends to be more difficult to predict than "how long > * will we be in user mode?" > * - Reduce the lifetime of the new offset sitting in memory during > * kernel mode execution. Exposure of "thread-local" memory content > * (e.g. current, percpu, etc) tends to be easier than arbitrary > * location memory exposure. > > I'm not totally convinced by the first argument; for arches that use the tsc, > sampling the tsc at syscall entry would mean that userspace can figure out the > random value that will be used for syscall N by sampling the tsc and adding a > bit just before calling syscall N. Sampling the tsc at syscall exit would mean > that userspace can figure out the random value that will be used for syscall N > by sampling the tsc and subtracting a bit just after syscall N-1 returns. I > don't really see any difference in protection? > > If you're trying force the kernel-sampled tsc to be a specific value, then for > the sample-on-exit case, userspace can just make a syscall with an invalid id as > it's syscall N-1 and in that case the duration between entry and exit is tiny > and fixed so it's still pretty simple to force the value. FWIW, I agree. I don't think we're gaining much based on the placement of choose_random_kstack_offset() at the start/end of the entry/exit sequences. As an aside, it looks like x86 calls choose_random_kstack_offset() for *any* return to userspace, including non-syscall returns (e.g. from IRQ), in arch_exit_to_user_mode_prepare(). There's some additional randomness/perturbation that'll cause, but logically it's not necessary to do that for *all* returns to userspace. > So what do you think of this approach? : > > #define add_random_kstack_offset(rand) do { \ > if (static_branch_maybe(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, \ > &randomize_kstack_offset)) { \ > u32 offset = raw_cpu_read(kstack_offset); \ > u8 *ptr; \ > \ > offset = ror32(offset, 5) ^ (rand); \ > raw_cpu_write(kstack_offset, offset); \ > u8 *ptr = __kstack_alloca(KSTACK_OFFSET_MAX(offset)); \ > /* Keep allocation even after "ptr" loses scope. */ \ > asm volatile("" :: "r"(ptr) : "memory"); \ > } \ > } while (0) > > This ignores "Maximize the timing uncertainty" (but that's ok because the > current version doesn't really do that either), but strengthens "Reduce the > lifetime of the new offset sitting in memory". Is this assuming that 'rand' can be generated in a non-preemptible context? If so (and this is non-preemptible), that's fine. I'm not sure whether that was the intent, or this was ignoring the rescheduling problem. If we do this per-task, then that concern disappears, and this can all be preemptible. Mark.