Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Date:   Tue, 28 Nov 2023 13:55:49 +0000
From:   Mark Brown <broonie@kernel.org>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc:     "debug@rivosinc.com" <debug@rivosinc.com>,
        "keescook@chromium.org" <keescook@chromium.org>,
        "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
        "Pandey, Sunil K" <sunil.k.pandey@intel.com>,
        "szabolcs.nagy@arm.com" <szabolcs.nagy@arm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "hjl.tools@gmail.com" <hjl.tools@gmail.com>,
        "kito.cheng@sifive.com" <kito.cheng@sifive.com>
Subject: Re: Shadow stack enabling from dynamic loader v/s kernel on exec
Message-ID: <ZWXxZYm/t69afFJZ@finisterre.sirena.org.uk>
References: <CAKC1njRkpaqbAFWrZpz75u4M-T8mniY2QHVZEENameqnHOOGPg@mail.gmail.com>
 <ZWHcBq0bJ+15eeKs@finisterre.sirena.org.uk>
 <b2498b8097da6223f54aebd80f2e3f0b06fe47e2.camel@intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="RHQr7V8m/3wCdFHK"
Content-Disposition: inline
In-Reply-To: <b2498b8097da6223f54aebd80f2e3f0b06fe47e2.camel@intel.com>
Precedence: bulk


--RHQr7V8m/3wCdFHK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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.

--RHQr7V8m/3wCdFHK
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmVl8WQACgkQJNaLcl1U
h9AyFAf5AfIg+BaZjkXaiSmsN4zgQJ5QAmBA/ntx6Z7SGGIRRRLSfISISp7SLGcW
+KbkP9KTgt1G9Aku7ycNS6tckK26J+cJLw5n+7Q1Vzdr88dLMQ+a5Jsnznb9J4EC
8FbqdGBj+biihnELtiQJ4xTW00nH3XDRDZyYdZDZuLx1YfWBRojSn6rvazJCAiMH
Hw80cAZAoNLOvrdbLKbmoif0JTfWj1LSCm+M4FnvOBD75W+eWgwDhnW5DHqtJ7Ov
f8U9Gb3yhJBL1sVjZq/bzygUiPb92/e1OBz5K37iAscmjs1CMeR5ALXJhgW2Wsb0
1OAcbg9DTrAjMOeW/83EQGmvdLtmGA==
=9qsU
-----END PGP SIGNATURE-----

--RHQr7V8m/3wCdFHK--