On Tue, 2023-02-28 at 11:58 +0100, Borislav Petkov wrote: > 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. :) Sure I can add something. Somewhere I have a man page for map_shadow_stack written up as well. > > > 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. Enabling for all objects is the ideal, but in practice distros don't have that. > 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. It is definitely a can of worms.
