From: Deepak Gupta <debug@rivosinc.com>
To: Mark Brown <broonie@kernel.org>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"mingo@kernel.org" <mingo@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"bp@alien8.de" <bp@alien8.de>,
"peterz@infradead.org" <peterz@infradead.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"Mehta, Sohil" <sohil.mehta@intel.com>,
"oleg@redhat.com" <oleg@redhat.com>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 5/6] x86/shstk: don't create the shadow stack for PF_USER_WORKERs
Date: Fri, 15 Aug 2025 12:11:47 -0700 [thread overview]
Message-ID: <aJ-Gc0X0J2GzgmnX@debug.ba.rivosinc.com> (raw)
In-Reply-To: <6abf383f-2756-4de6-a951-6121f51263e2@sirena.org.uk>
On Fri, Aug 15, 2025 at 12:44:14PM +0100, Mark Brown wrote:
>On Thu, Aug 14, 2025 at 10:43:45PM +0000, Edgecombe, Rick P wrote:
>> On Thu, 2025-08-14 at 19:33 +0100, Mark Brown wrote:
>
>> > Perhaps we should factor the logic for deciding if we need to allocate a
>> > userspace shadow stack out into the arch independent code and do
>> > something like set a flag in kernel_clone_args that the arches can
>> > check? I think the logic is the same for all arches at the minute and
>> > don't see a reason why it'd diverge.
>
>> Sounds good. Like a little start to this:
>> https://lore.kernel.org/lkml/20241010-shstk_converge-v1-0-631beca676e7@rivosinc.com/
>
>Yes, exactly.
>
>> > That'd collide a bit with my
>> > clone3() series, there's some overlap there with that creating another
>> > reason why the decision would change. Reducing the duplication would be
>> > nice.
>
>> Argh, I need to test the latest of that still.
>
>Yury pointed me at some newer x86 systems I was able to get access to so
>I was finally able to test that one myself before sending it out,
>confirmation would be good but hopefully it's fine. I've been holding
>back on sending a rebased version out since Deepak was going to help me
>get set up to test it on RISC-V. Though I see now that the RISC-V code
>has vanished from -next (I guess due to fallout from the issues with the
>merge to Linus, it looks like there's almost nothing in the branch
>currently), not sure what the plan is there?
>
>Perhaps I should just send it out, but given the difficulty getting
>anyone to pay attention I was trying to avoid issues with missing
>updates for newly added RISC-V shadow stacks.
Yes I was trying to get that sorted as well. Because now I'll have to
rebase my changes to 6.17. So I wanted to make sure that it applies
cleanly. I suggest that you send it out because risc-v was left out
anyways. I'll apply your patch series on my risc-v shadow stack changes
(on top of 6.17) and will report back. It might be easier that way.
How does that sound?
next prev parent reply other threads:[~2025-08-15 19:11 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 10:13 [PATCH 0/6] x86/fpu: don't abuse x86_task_fpu(PF_USER_WORKER) in .regset_get() paths Oleg Nesterov
2025-08-14 10:14 ` [PATCH 1/6] x86/fpu: change copy_xstate_to_uabi_buf() to accept fpstate + pkru instead of task_struct Oleg Nesterov
2025-08-14 16:46 ` Edgecombe, Rick P
2025-08-15 12:22 ` Oleg Nesterov
2025-08-14 10:14 ` [PATCH 2/6] x86/fpu: regset: introduce get_fpstate() helper Oleg Nesterov
2025-08-14 10:14 ` [PATCH 3/6] x86/fpu: fold sync_fpstate() into get_fpstate() Oleg Nesterov
2025-08-14 10:14 ` [PATCH 4/6] x86/shstk: add "task_struct *tsk" argument to reset_thread_features() Oleg Nesterov
2025-08-14 10:14 ` [PATCH 5/6] x86/shstk: don't create the shadow stack for PF_USER_WORKERs Oleg Nesterov
2025-08-14 17:03 ` Edgecombe, Rick P
2025-08-14 18:33 ` Mark Brown
2025-08-14 22:43 ` Edgecombe, Rick P
2025-08-15 11:44 ` Mark Brown
2025-08-15 19:11 ` Deepak Gupta [this message]
2025-08-18 17:27 ` Mark Brown
2025-08-19 17:41 ` Deepak Gupta
2025-08-15 13:01 ` Oleg Nesterov
2025-08-15 13:08 ` Oleg Nesterov
2025-08-15 15:28 ` Mark Brown
2025-08-15 15:43 ` Oleg Nesterov
2025-08-15 15:48 ` Mark Brown
2025-08-15 16:00 ` Oleg Nesterov
2025-08-15 17:08 ` Mark Brown
2025-08-15 12:17 ` Oleg Nesterov
2025-08-15 16:19 ` Edgecombe, Rick P
2025-08-15 16:54 ` Oleg Nesterov
2025-08-15 17:46 ` Edgecombe, Rick P
2025-08-15 19:13 ` Oleg Nesterov
2025-08-14 10:14 ` [PATCH 6/6] x86/fpu: change get_fpstate() to return &init_fpstate if PF_USER_WORKER Oleg Nesterov
2025-08-15 15:52 ` [PATCH 0/6] x86/fpu: don't abuse x86_task_fpu(PF_USER_WORKER) in .regset_get() paths Oleg Nesterov
2025-08-15 15:59 ` Dave Hansen
2025-08-15 16:02 ` Oleg Nesterov
2025-08-15 16:32 ` Sohil Mehta
2025-08-15 19:33 ` Oleg Nesterov
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=aJ-Gc0X0J2GzgmnX@debug.ba.rivosinc.com \
--to=debug@rivosinc.com \
--cc=axboe@kernel.dk \
--cc=bp@alien8.de \
--cc=broonie@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@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 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.