From: Will Deacon <will@kernel.org>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Kees Cook <kees@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Ard Biesheuvel <ardb@kernel.org>,
Jeremy Linton <jeremy.linton@arm.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [DISCUSSION] kstack offset randomization: bugs and performance
Date: Mon, 24 Nov 2025 14:36:25 +0000 [thread overview]
Message-ID: <aSRtaVjfNc11EtKg@willie-the-truck> (raw)
In-Reply-To: <dd8c37bc-795f-4c7a-9086-69e584d8ab24@arm.com>
On Mon, Nov 17, 2025 at 11:31:22AM +0000, Ryan Roberts wrote:
> On 17/11/2025 11:30, Ryan Roberts wrote:
> > Could this give us a middle ground between strong-crng and
> > weak-timestamp-counter? Perhaps the main issue is that we need to store the
> > secret key for a long period?
> >
> >
> > Anyway, I plan to work up a series with the bugfixes and performance
> > improvements. I'll add the siphash approach as an experimental addition and get
> > some more detailed numbers for all the options. But wanted to raise it all here
> > first to get any early feedback.
FWIW, I share Mark's concerns about using a counter for this. Given that
the feature currently appears to be both slow _and_ broken I'd vote for
either removing it or switching over to per-thread offsets as a first
step. We already have a per-task stack canary with
CONFIG_STACKPROTECTOR_PER_TASK so I don't understand the reluctance to
do something similar here.
Speeding up the crypto feels like something that could happen separately.
Will
next prev parent reply other threads:[~2025-11-24 14:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <66c4e2a0-c7fb-46c2-acce-8a040a71cd8e@arm.com>
2025-11-17 11:31 ` [DISCUSSION] kstack offset randomization: bugs and performance Ryan Roberts
2025-11-17 16:47 ` Arnd Bergmann
2025-11-17 17:23 ` Ryan Roberts
2025-11-17 17:46 ` Mark Rutland
2025-11-17 23:04 ` Arnd Bergmann
2025-11-18 17:15 ` Jason A. Donenfeld
2025-11-18 17:21 ` Ryan Roberts
2025-11-18 17:28 ` Jason A. Donenfeld
2025-11-17 20:27 ` Kees Cook
2025-11-18 10:28 ` Ryan Roberts
2025-11-18 11:25 ` Mark Rutland
2025-11-18 12:16 ` Ryan Roberts
2025-11-18 11:05 ` Mark Rutland
2025-11-17 20:56 ` Jeremy Linton
2025-11-18 11:05 ` Ryan Roberts
2025-11-24 14:36 ` Will Deacon [this message]
2025-11-24 17:11 ` Kees Cook
2025-11-24 17:50 ` Ryan Roberts
2025-11-24 20:51 ` Kees Cook
2025-11-25 11:14 ` Ryan Roberts
2025-11-26 22:58 ` Ard Biesheuvel
2025-11-27 8:00 ` Kees Cook
2025-11-27 11:50 ` Ryan Roberts
2025-11-27 12:19 ` Ard Biesheuvel
2025-11-27 14:09 ` Ryan Roberts
2025-11-27 19:17 ` Kees Cook
2025-11-24 19:08 ` Will Deacon
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=aSRtaVjfNc11EtKg@willie-the-truck \
--to=will@kernel.org \
--cc=Catalin.Marinas@arm.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=jeremy.linton@arm.com \
--cc=kees@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=ryan.roberts@arm.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox