Re: [PATCH v6 28/41] x86: Introduce userspace API for shadow stack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 24, 2023 at 06:37:57PM +0000, Edgecombe, Rick P wrote:
> In the first patch:
> 
> https://lore.kernel.org/lkml/20230218211433.26859-2-rick.p.edgecombe@xxxxxxxxx/
> 
> Then some more documentation is added about ARCH_SHSTK_UNLOCK and
> ARCH_SHSTK_STATUS (which are for CRIU) in those patches.

Right, I was thinking more about ARCH_PRCTL(2), the man page.

But you can send that to the manpages folks later. I.e., it should be
nearly impossible to be missed. :)

> There are glibc patches prepared by HJ to use the new interface and
> it's my understanding that he has discussed the changes with the other
> glibc folks. Those glibc patches are used for testing these kernel
> patches, but will not get upstream until the kernel patches to avoid
> repeating the past problems. So I think it's as prepared as it can be.

Good.

> One future thing that might come up... Glibc has this mode called
> "permissive mode". When glibc is configured this way (compile time or
> env var), it is supposed to disable shadow stack when dlopen()ing any
> DSO that doesn't have the shadow stack elf header bit.

Maybe I don't understand all the possible use cases but if I were
interested in using shadow stack, then I'd enable it for all objects.
And if I want permissive, I'd disable it for all. A mixed thing sounds
like a mixed can of worms waiting to be opened.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux