+Yan
On Wed, 2024-06-05 at 14:44 -0700, Rick Edgecombe wrote:
> > I will take a look at rebasing the selftests on top of the Intel
> > development branch and I can post it on our github branch. We can talk
> > about co-development offline. We already have some code that was
> > suggested by Isaku
On Wed, 2024-06-05 at 16:34 -0500, Sagi Shahar wrote:
> > We don't currently have plans to post a whole ~130 patch series. Instead we
> > plan
> > to post subsections out of the series as they slowly move into a maintainer
> > branch.
>
> So this means that we won't be able to post an updated
On Wed, 2024-06-05 at 15:42 -0500, Sagi Shahar wrote:
> > > Hm you're right, I was looking more narrowly because of the kvm-coco-
> > > queue conflicts, for some of which even v19 might be too old. The MMU
> > > prep series uses a much more recent kvm-coco-queue baseline.
> > >
> > > Rick, can we
On Wed, 2024-02-21 at 14:06 -0500, dal...@libc.org wrote:
> Due to arbitrarily nestable signal frames, no, this does not suffice.
> An interrupted operation using the lock could be arbitrarily delayed,
> even never execute again, making any call to dlopen deadlock.
Doh! Yep, it is not robust to
On Wed, 2024-02-21 at 13:30 -0500, dal...@libc.org wrote:
> > 3 is the cleanest and safest I think, and it was thought it might
> > not
> > need kernel help, due to a scheme Florian had to direct signals to
> > specific threads. It's my preference at this point.
>
> The operations where the
On Wed, 2024-02-21 at 12:57 -0500, dal...@libc.org wrote:
> > This feels like it's getting complicated and I fear it may be an
> > uphill
> > struggle to get such code merged, at least for arm64. My instinct
> > is
> > that it's going to be much more robust and generally tractable to
> > let
> >
On Tue, 2024-02-20 at 18:59 -0500, Stefan O'Rear wrote:
>
> Ideally for riscv only writes would cause conversion, an incssp
> underflow
> which performs shadow stack reads would be able to fault early.
Why can't makecontext() just clobber part of the low address side of
the passed in stack with
On Tue, 2024-02-20 at 18:11 -0800, Rick Edgecombe wrote:
> Some specific cases that were still open were longjmp()ing off of a
> custom userspace threading library stack, which may not have left a
> token behind when it jumped to a new stack. And also, potentially off
> of an alt shadow stack in
On Tue, 2024-02-20 at 20:27 -0500, dal...@libc.org wrote:
> > Then I think WRSS might fit your requirements better than what
> > glibc
> > did. It was considered a reduced security mode that made libc's job
> > much easier and had better compatibility, but the last discussion
> > was
> > to try to
On Tue, 2024-02-20 at 18:54 -0500, dal...@libc.org wrote:
> On Tue, Feb 20, 2024 at 11:30:22PM +0000, Edgecombe, Rick P wrote:
> > On Tue, 2024-02-20 at 13:57 -0500, Rich Felker wrote:
> > > On Tue, Feb 20, 2024 at 06:41:05PM +0000, Edgecombe, Rick P
> > > wrote:
&g
On Tue, 2024-02-20 at 20:14 +, Mark Brown wrote:
> > Hmm, could the shadow stack underflow onto the real stack then? Not
> > sure how bad that is. INCSSP (incrementing the SSP register on x86)
> > loops are not rare so it seems like something that could happen.
>
> Yes, they'd trash any pages
On Tue, 2024-02-20 at 13:57 -0500, Rich Felker wrote:
> On Tue, Feb 20, 2024 at 06:41:05PM +0000, Edgecombe, Rick P wrote:
> > Hmm, could the shadow stack underflow onto the real stack then? Not
> > sure how bad that is. INCSSP (incrementing the SSP register on x86)
> >
Hi,
I worked on the x86 kernel shadow stack support. I think it is an
interesting suggestion. Some questions below, and I will think more on
it.
On Tue, 2024-02-20 at 11:36 -0500, Stefan O'Rear wrote:
> While discussing the ABI implications of shadow stacks in the context
> of
> Zicfiss and musl
On Sat, 2024-02-03 at 00:05 +, Mark Brown wrote:
> + if (args->shadow_stack) {
> + addr = args->shadow_stack;
> + size = args->shadow_stack_size;
>
> - size = adjust_shstk_size(stack_size);
> - addr = alloc_shstk(0, size, 0, false);
> - if
On Fri, 2024-02-09 at 12:18 -0800, Rick Edgecombe wrote:
>
> So, don't we want to consume the token on the *new* task's MM, which
> was already duplicated but still unmapped? In which case I think the
> other arch's would need to GUP regardless of the existence of shadow
> stack atomic ops.
I
On Wed, 2024-01-24 at 22:21 -0800, de...@rivosinc.com wrote:
> From: Deepak Gupta
>
> As discussed extensively in the changelog for the addition of this
> syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the
> existing mmap() and madvise() syscalls do not map entirely well onto
>
On Wed, 2024-01-24 at 22:21 -0800, de...@rivosinc.com wrote:
> + /*
> + * PROT_SHADOWSTACK is a kernel only protection flag on risc-
> v.
> + * mmap doesn't expect PROT_SHADOWSTACK to be set by user
> space.
> + * User space can rely on `map_shadow_stack` syscall to
>
On Sat, 2024-02-03 at 00:04 +, Mark Brown wrote:
> While almost all users of shadow stacks should be relying on the
> dynamic
> linker and libc to enable the feature there are several low level
> test
> programs where it is useful to enable without any libc support,
> allowing
> testing
On Sat, 2024-02-03 at 00:04 +, Mark Brown wrote:
> Since multiple architectures have support for shadow stacks and we
> need to
> select support for this feature in several places in the generic code
> provide a generic config option that the architectures can select.
>
> Suggested-by: David
On Sat, 2024-02-03 at 00:04 +, Mark Brown wrote:
> Please note that the x86 portions of this code are build tested only,
> I
> don't appear to have a system that can run CET avaible to me, I have
> done testing with an integration into my pending work for GCS. There
> is
> some possibility
On Sat, 2024-02-03 at 00:05 +, Mark Brown wrote:
> +static bool shstk_consume_token(struct task_struct *tsk,
> + unsigned long addr)
> +{
> + /*
> + * SSP is aligned, so reserved bits and mode bit are a zero,
> just mark
> + * the token 64-bit.
+Mike, who did the CRIU work
Re:
https://lore.kernel.org/lkml/e1362732ba86990b7707d3f5b785358b77c5f896.ca...@intel.com/
On Tue, 2023-12-12 at 20:26 +, Mark Brown wrote:
> The set of locked features is read/write via ptrace in my arm64
> series,
> that's architecture specific unfortunately
On Wed, 2023-11-22 at 09:42 +, Mark Brown wrote:
> These features are expected to be inherited by new threads and
> cleared
> on exec(), unknown features should be rejected for enable but
> accepted
> for locking (in order to allow for future proofing).
The reason why I stuck with arch_prctl
On Tue, 2023-12-05 at 16:43 +, Mark Brown wrote:
> Right, it's a small and fairly easily auditable list - it's more
> about
> the app than the double enable which was what I thought your concern
> was. It's a bit annoying definitely and not something we want to do
> in
> general but for
On Tue, 2023-12-05 at 15:51 +, Mark Brown wrote:
> On Tue, Dec 05, 2023 at 12:26:57AM +0000, Edgecombe, Rick P wrote:
> > On Tue, 2023-11-28 at 18:22 +, Mark Brown wrote:
>
> > > - size = adjust_shstk_size(stack_size);
> > > + size = adjust_shstk_
On Tue, 2023-12-05 at 15:05 +, Mark Brown wrote:
> > But I wonder if the clone3 test should get its shadow stack enabled
> > the
> > conventional elf bit way. So if it's all there (HW, kernel, glibc)
> > then
> > the test will run with shadow stack. Otherwise the test will run
> > without
On Tue, 2023-11-28 at 18:22 +, Mark Brown wrote:
> -unsigned long shstk_alloc_thread_stack(struct task_struct *tsk,
> unsigned long clone_flags,
> - unsigned long stack_size)
> +unsigned long shstk_alloc_thread_stack(struct task_struct *tsk,
> +
On Tue, 2023-11-28 at 18:22 +, Mark Brown wrote:
> +
> +#define ENABLE_SHADOW_STACK
> +static inline void enable_shadow_stack(void)
> +{
> + int ret = ARCH_PRCTL(ARCH_SHSTK_ENABLE, ARCH_SHSTK_SHSTK);
> + if (ret == 0)
> + shadow_stack_enabled = true;
> +}
> +
>
On Thu, 2023-11-30 at 21:51 +, Mark Brown wrote:
> On Thu, Nov 30, 2023 at 07:00:58PM +, Catalin Marinas wrote:
>
> > My hope when looking at the arm64 patches was that we can
> > completely
> > avoid the kernel allocation/deallocation of the shadow stack since
> > it
> > doesn't need to
On Tue, 2023-11-14 at 15:11 -0800, Rick Edgecombe wrote:
> The other tests passed in both cases. I'm going to dig into the other
> parts now but can circle back if it's not obvious what's going on
> there.
Finally got back to this. I think it's just a problem with the shadow
stack detection logic
On Thu, 2023-11-16 at 18:41 +, Mark Brown wrote:
> > What about a CLONE_NEW_SHSTK for clone3 that forces a new shadow
> > stack?
> > So keep the existing logic, but the new flag can override the logic
> > for
> > !CLONE_VM and CLONE_VFORK if the caller wants. The behavior of
> >
On Thu, 2023-11-16 at 18:14 +, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 12:52:09AM +0000, Edgecombe, Rick P wrote:
> > On Wed, 2023-11-15 at 18:43 +, Mark Brown wrote:
> > > > end marker token (0) needs it i guess.
>
> > > x86 doesn't currently ha
On Thu, 2023-11-16 at 15:35 +, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 01:55:07PM +,
> szabolcs.n...@arm.com wrote:
> > The 11/16/2023 12:33, Mark Brown wrote:
> > > On Thu, Nov 16, 2023 at 10:32:06AM +,
> > > szabolcs.n...@arm.com wrote:
>
> > > > i guess the tricky case is
On Wed, 2023-11-15 at 18:43 +, Mark Brown wrote:
> > end marker token (0) needs it i guess.
>
> x86 doesn't currently have end markers. Actually, that's a point -
> should we add a flag for specifying the use of end markers here?
> There's code in my map_shadow_stack() implementation for
On Tue, 2023-11-14 at 20:05 +, Mark Brown wrote:
> diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c
> index 59e15dd8d0f8..7ffe90010587 100644
> --- a/arch/x86/kernel/shstk.c
> +++ b/arch/x86/kernel/shstk.c
> @@ -191,18 +191,38 @@ void reset_thread_features(void)
>
On Tue, 2023-11-14 at 20:05 +, Mark Brown wrote:
> +config ARCH_HAS_USER_SHADOW_STACK
> + bool
> + help
> + The architecture has hardware support for userspace shadow
> call
> + stacks (eg, x86 CET, arm64 GCS, RISC-V Zisslpcfi).
I feel like normally a patch like
On Tue, 2023-11-14 at 20:05 +, Mark Brown wrote:
> +static void test_shadow_stack_supported(void)
> +{
> + long shadow_stack;
> +
> + shadow_stack = syscall(__NR_map_shadow_stack, 0,
> getpagesize(), 0);
Hmm, x86 fails this call if user shadow stack is not supported in the
HW or
On Fri, 2023-10-27 at 12:49 +0100, szabolcs.n...@arm.com wrote:
> no. the lifetime is the issue: a stack in principle can outlive
> a thread and resumed even after the original thread exited.
> for that to work the shadow stack has to outlive the thread too.
Hmm, this makes me think about the
On Thu, 2023-10-26 at 13:40 -0700, Deepak Gupta wrote:
>
> FWIW, from arch specific perspective, RISC-V shadow stack extension
> has
> `ssamoswap` to perform this token exchange. But I understand x86 has
> this
> limitation (not sure about arm GCS).
>
> From security perspective:--
> Someone
On Thu, 2023-10-26 at 18:53 +0100, Mark Brown wrote:
> Particularly given my inability to test x86 I'm certainly way
> more happy pushing this series forward implementing size only than I
> am
> doing token validation.
I can help with testing/development once we get the plan settled on.
On Mon, 2023-10-23 at 19:32 +0100, Mark Brown wrote:
> Right. We're already adding the cost of the extra map_shadow_stack()
> so
> it doesn't seem that out of scope. We could also allow clone3() to
> be
> used for allocation, potentially removing the ability to specify the
> address entirely and
+Some security folks
On Mon, 2023-10-23 at 14:20 +0100, Mark Brown wrote:
> Unlike with the normal stack there is no API for configuring the the
> shadow
> stack for a new thread, instead the kernel will dynamically allocate
> a new
> shadow stack with the same size as the normal stack. This
On Mon, 2023-10-02 at 20:49 +0100, Mark Brown wrote:
> On Thu, Sep 28, 2023 at 05:59:25PM +0100, Szabolcs Nagy wrote:
> > The 08/23/2023 14:11, Catalin Marinas wrote:
>
> > > > and there is user code doing raw clone threads (such threads
> > > > are
> > > > technically not allowed to call into
43 matches
Mail list logo
