Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 25 May 2023 17:20:30 +0100
From:   Mark Brown <broonie@kernel.org>
To:     Deepak Gupta <debug@rivosinc.com>
Cc:     "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
        "Torvalds, Linus" <torvalds@linux-foundation.org>,
        "keescook@chromium.org" <keescook@chromium.org>,
        "x86@kernel.org" <x86@kernel.org>,
        "Hansen, Dave" <dave.hansen@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Subject: Re: [GIT PULL] x86/shstk for 6.4
Message-ID: <b402b80b-a7c6-4ef0-b977-c0f5f582b78a@sirena.org.uk>
References: <20230424212130.590684-1-dave.hansen@linux.intel.com>
 <CAHk-=whn3F1k263SZNUVQK195tcCMAo5E_WbmjUE0qFC5rWg=w@mail.gmail.com>
 <4433c3595db23f7c779b69b222958151b69ddd70.camel@intel.com>
 <148b3edb-b056-11a0-1684-6273a4a2d39a@intel.com>
 <CAHk-=wiuVXTfgapmjYQvrEDzn3naF2oYnHuky+feEJSj_G_yFQ@mail.gmail.com>
 <ad5b44e17c1c17ebdc581169fec7e80f7ef2a4d4.camel@intel.com>
 <CAHk-=wiZjSu7c9sFYZb3q04108stgHff2wfbokGCCgW7riz+8Q@mail.gmail.com>
 <bd7c4f53cd27224308bff305513978dced1495ad.camel@intel.com>
 <20230515212255.GA562920@debug.ba.rivosinc.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="4xDnJ/JT4ZY6//sb"
Content-Disposition: inline
In-Reply-To: <20230515212255.GA562920@debug.ba.rivosinc.com>
Precedence: bulk


--4xDnJ/JT4ZY6//sb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, May 15, 2023 at 02:22:55PM -0700, Deepak Gupta wrote:
> On Sun, May 07, 2023 at 04:24:24PM +0000, Edgecombe, Rick P wrote:

> > BTW, I forgot to mention that there is another architecture (maybe 2)
> > that is expected to use this refactor for implementing their shadow
> > stacks. So FWIW, this churn is not just for x86.

> That's right, one of them is RISC-V.

Also arm64.

> RISC-V control-flow integrity: https://github.com/riscv/riscv-cfi

> Since RISC-V PTE have 3 separate bits for read, write and execute. Write
> only (R=0, W=1, X=0) encodings had been reserved and thus cpu supporting
> this extension will treat this reserved encoding as shadow stack.

> It doesn't get messy as in case of x86 (due to overloading of dirty bit),
> but it still will need pte helper which marks a page "shadow stack
> writeable" or "regular writeable" depending on vma.

For arm64 GCS (our shadow stack equivalent) is built on top of another
extension that allows us to assign arbitrary meanings to four of the
bits (they become an index into an array of actual permissions) so we
might be able to avoid having to look at the VMA, though we might want
to in future in order to make better use of the other features of the
indirection extension.

--4xDnJ/JT4ZY6//sb
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmRvis0ACgkQJNaLcl1U
h9BKswf/WpINbiUBFLGfCXGwM0YsASUPoJoK1V7g+saDH9q66NEq4yB1t/UFPSPY
bylxlSVk97TTHlTDR5Z6twr/YdVX5hqcszBMOhUBqgImKGBHvc10+mBj3dIUeUCR
/zexGgbk/vZw9zmzBdRwK4bZESO44DZC+lYpKjxoXct2wYrZuzLz+dlE/fvYTa93
1mq6fU6tel2Rnxk5EUoE1PC4wYIGsMEzDcHccfl2O/xwcvwDgIR6xQ7hHSRqyzDC
JoH0C4PklIJFs1151uCvO8m2qIM3gJqJGGXHrYi3qs1gAdebWbQywdx59hFHNAnG
+JONah/5gMlQ6ER7q29Cd0o21gzNag==
=46DT
-----END PGP SIGNATURE-----

--4xDnJ/JT4ZY6//sb--