From: Kees Cook <kees@kernel.org>
To: Will Deacon <will@kernel.org>, Ryan Roberts <ryan.roberts@arm.com>
Cc: 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 09:11:23 -0800 [thread overview]
Message-ID: <B696956E-579E-412E-B774-AAADCFA4B31C@kernel.org> (raw)
In-Reply-To: <aSRtaVjfNc11EtKg@willie-the-truck>
On November 24, 2025 6:36:25 AM PST, Will Deacon <will@kernel.org> wrote:
>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.
That it has potential weaknesses doesn't mean it should be entirely removed.
> 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.
That's not a reasonable comparison: the stack canary cannot change arbitrarily for a task or it would immediately crash on a function return. :)
>Speeding up the crypto feels like something that could happen separately.
Sure. But let's see what Ryan's patches look like. The suggested changes sound good to me.
-Kees
--
Kees Cook
next prev parent reply other threads:[~2025-11-24 17:11 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 ` 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
2025-11-24 17:11 ` Kees Cook [this message]
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=B696956E-579E-412E-B774-AAADCFA4B31C@kernel.org \
--to=kees@kernel.org \
--cc=Catalin.Marinas@arm.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=jeremy.linton@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=ryan.roberts@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: 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
all inboxes | Powered by JetHome®