Re: Shadow stack enabling from dynamic loader v/s kernel on exec

[Mark Brown]

On Mon, Nov 27, 2023 at 05:32:24PM +0000, Edgecombe, Rick P wrote:

> security focused runtime environment. So a seccomp mode starts to seem
> like a separate enabling mode with it's own rules, in which case it
> could be left for the future.

My understanding is that seccomp is generic enough to allow you to write
filters without any specific shadow stack support, though I'm not sure
about handling for arch_prctl() so perhaps it's harder on x86.

> I don't think doing exec based enabling will impact the app developers
> expectations, because it should be confined to the loader. So it's fine
> either way from my perspective.

Yes, I don't think there's an issue for apps either way - it's more an
issue for people doing system level security.

> > On arm64 there would be the potential for disrupting some limited and
> > theoretical use cases where GCS is enabled even though some libraries
> > do
> > not support it

> On x86 we see this case already in testing. Why do you think it is
> theoretical?

Right, it's fairly easy to add something not flagged as GCS compatible
at runtime through dlopen().  I think I was thinking of the case where
the program is not marked as supporting GCS but enables GCS usage
selectively at runtime, it wouldn't be able to do that for the main
thread since we don't allow reenabling.

Attachment: signature.asc
Description: PGP signature