From: "Arnd Bergmann" <arnd@arndb.de> To: "Kees Cook" <keescook@chromium.org> Cc: "Jeremy Linton" <jeremy.linton@arm.com>, linux-arm-kernel@lists.infradead.org, "Catalin Marinas" <catalin.marinas@arm.com>, "Will Deacon" <will@kernel.org>, "Jason A . Donenfeld" <Jason@zx2c4.com>, "Gustavo A. R. Silva" <gustavoars@kernel.org>, "Mark Rutland" <mark.rutland@arm.com>, "Steven Rostedt" <rostedt@goodmis.org>, "Mark Brown" <broonie@kernel.org>, "Guo Hui" <guohui@uniontech.com>, Manoj.Iyer@arm.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, "James Yang" <james.yang@arm.com>, "Shiyou Huang" <shiyou.huang@arm.com> Subject: Re: [PATCH 1/1] arm64: syscall: Direct PRNG kstack randomization Date: Thu, 07 Mar 2024 22:56:56 +0100 [thread overview] Message-ID: <50d4146e-57a2-48a8-809f-713279935f32@app.fastmail.com> (raw) In-Reply-To: <202403071105.C3B038C@keescook> On Thu, Mar 7, 2024, at 20:10, Kees Cook wrote: > On Thu, Mar 07, 2024 at 12:10:34PM +0100, Arnd Bergmann wrote: >> For the strength, we have at least four options: >> >> - strong rng, most expensive >> - your new prng, less strong but somewhat cheaper and/or more >> predictable overhead >> - cycle counter, cheap but probably even less strong, >> needs architecture code. > > Are the low bits of a cycler counter really less safe than a > deterministic pRNG? I don't know, that was based on Jeremy's assertion. I'm not even convinced that either one is actually safer than no randomization. ;-) For both the timer and the pRNG, I guess you'd need a gadget to extract the current offset and from there extract the per-cpu state value. Once you know the state and there is no reseed, you can pick the value you want for the next syscall by either calling getpid() repeatedly or waiting for the cycle counter to reach the desired value before calling a vulnerable syscall. At that point the pRNG and no randomization are reliably predictable, while the timer may still have some jitter left. >> - no rng, no overhead and no protection. > > For the pRNG, why not just add a reseed timer or something that'll > happen outside the syscall window, if that's the concern about reseeding > delay? (In which case, why not continue to use the strong rng?) I fear a timer or workqueue would be both weaker than a forced reseed if the attacker wins the race against the reseed, and still cause latency that hurts realtime usecases. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de> To: "Kees Cook" <keescook@chromium.org> Cc: "Jeremy Linton" <jeremy.linton@arm.com>, linux-arm-kernel@lists.infradead.org, "Catalin Marinas" <catalin.marinas@arm.com>, "Will Deacon" <will@kernel.org>, "Jason A . Donenfeld" <Jason@zx2c4.com>, "Gustavo A. R. Silva" <gustavoars@kernel.org>, "Mark Rutland" <mark.rutland@arm.com>, "Steven Rostedt" <rostedt@goodmis.org>, "Mark Brown" <broonie@kernel.org>, "Guo Hui" <guohui@uniontech.com>, Manoj.Iyer@arm.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, "James Yang" <james.yang@arm.com>, "Shiyou Huang" <shiyou.huang@arm.com> Subject: Re: [PATCH 1/1] arm64: syscall: Direct PRNG kstack randomization Date: Thu, 07 Mar 2024 22:56:56 +0100 [thread overview] Message-ID: <50d4146e-57a2-48a8-809f-713279935f32@app.fastmail.com> (raw) In-Reply-To: <202403071105.C3B038C@keescook> On Thu, Mar 7, 2024, at 20:10, Kees Cook wrote: > On Thu, Mar 07, 2024 at 12:10:34PM +0100, Arnd Bergmann wrote: >> For the strength, we have at least four options: >> >> - strong rng, most expensive >> - your new prng, less strong but somewhat cheaper and/or more >> predictable overhead >> - cycle counter, cheap but probably even less strong, >> needs architecture code. > > Are the low bits of a cycler counter really less safe than a > deterministic pRNG? I don't know, that was based on Jeremy's assertion. I'm not even convinced that either one is actually safer than no randomization. ;-) For both the timer and the pRNG, I guess you'd need a gadget to extract the current offset and from there extract the per-cpu state value. Once you know the state and there is no reseed, you can pick the value you want for the next syscall by either calling getpid() repeatedly or waiting for the cycle counter to reach the desired value before calling a vulnerable syscall. At that point the pRNG and no randomization are reliably predictable, while the timer may still have some jitter left. >> - no rng, no overhead and no protection. > > For the pRNG, why not just add a reseed timer or something that'll > happen outside the syscall window, if that's the concern about reseeding > delay? (In which case, why not continue to use the strong rng?) I fear a timer or workqueue would be both weaker than a forced reseed if the attacker wins the race against the reseed, and still cause latency that hurts realtime usecases. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-07 21:57 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-05 22:18 [PATCH 0/1] Bring kstack randomized perf closer to unrandomized Jeremy Linton 2024-03-05 22:18 ` Jeremy Linton 2024-03-05 22:18 ` [PATCH 1/1] arm64: syscall: Direct PRNG kstack randomization Jeremy Linton 2024-03-05 22:18 ` Jeremy Linton 2024-03-05 23:33 ` Kees Cook 2024-03-05 23:33 ` Kees Cook 2024-03-06 20:46 ` Arnd Bergmann 2024-03-06 20:46 ` Arnd Bergmann 2024-03-06 21:54 ` Jeremy Linton 2024-03-06 21:54 ` Jeremy Linton 2024-03-07 11:10 ` Arnd Bergmann 2024-03-07 11:10 ` Arnd Bergmann 2024-03-07 19:10 ` Kees Cook 2024-03-07 19:10 ` Kees Cook 2024-03-07 21:56 ` Arnd Bergmann [this message] 2024-03-07 21:56 ` Arnd Bergmann 2024-03-07 19:15 ` Kees Cook 2024-03-07 19:15 ` Kees Cook 2024-03-07 22:02 ` Arnd Bergmann 2024-03-07 22:02 ` Arnd Bergmann 2024-03-08 16:49 ` Jeremy Linton 2024-03-08 16:49 ` Jeremy Linton 2024-03-08 20:29 ` Arnd Bergmann 2024-03-08 20:29 ` Arnd Bergmann 2024-03-22 23:40 ` Jeremy Linton 2024-03-22 23:40 ` Jeremy Linton 2024-03-23 12:47 ` Arnd Bergmann 2024-03-23 12:47 ` Arnd Bergmann 2024-03-07 19:05 ` kernel test robot 2024-03-07 19:05 ` kernel test robot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=50d4146e-57a2-48a8-809f-713279935f32@app.fastmail.com \ --to=arnd@arndb.de \ --cc=Jason@zx2c4.com \ --cc=Manoj.Iyer@arm.com \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=guohui@uniontech.com \ --cc=gustavoars@kernel.org \ --cc=james.yang@arm.com \ --cc=jeremy.linton@arm.com \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-hardening@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=rostedt@goodmis.org \ --cc=shiyou.huang@arm.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.