From: Kees Cook <keescook@chromium.org> To: Arnd Bergmann <arnd@arndb.de> 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, 7 Mar 2024 11:10:47 -0800 [thread overview] Message-ID: <202403071105.C3B038C@keescook> (raw) In-Reply-To: <f1dd15ce-69af-4315-8d7c-b7a480e541aa@app.fastmail.com> 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? > - 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?) -- Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org> To: Arnd Bergmann <arnd@arndb.de> 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, 7 Mar 2024 11:10:47 -0800 [thread overview] Message-ID: <202403071105.C3B038C@keescook> (raw) In-Reply-To: <f1dd15ce-69af-4315-8d7c-b7a480e541aa@app.fastmail.com> 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? > - 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?) -- Kees Cook _______________________________________________ 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 19:10 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 [this message] 2024-03-07 19:10 ` Kees Cook 2024-03-07 21:56 ` Arnd Bergmann 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=202403071105.C3B038C@keescook \ --to=keescook@chromium.org \ --cc=Jason@zx2c4.com \ --cc=Manoj.Iyer@arm.com \ --cc=arnd@arndb.de \ --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=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.