Subject: Re: [PATCH v2 0/3] arm64: Enable BTI for the executable as well as the interpreter

From: Dave Martin <[email-masked]>
Date: Tue, 15 Jun 2021 16:41:08 +0100

On Tue, Jun 15, 2021 at 04:33:41PM +0100, Mark Brown via Libc-alpha wrote:
> On Tue, Jun 15, 2021 at 04:22:06PM +0100, Dave Martin wrote:
> > On Thu, Jun 10, 2021 at 11:28:12AM -0500, Jeremy Linton via Libc-alpha wrote:
> 
> > > Thus, I expect that with his patch applied to 5.13 the service will fail to
> > > start regardless of the state of MDWE, but it seems to continue starting
> > > when I set MDWE=yes. Same behavior with v1 FWTW.
> 
> > If the failure we're trying to detect is that BTI is undesirably left
> > off for the main executable, surely replacing BTIs with NOPs will make
> > no differenece?  The behaviour with PROT_BTI clear is strictly more
> > permissive than with PROT_BTI set, so I'm not sure we can test the
> > behaviour this way.
> 
> > Maybe I'm missing sometihng / confused myself somewhere.
> 
> The issue this patch series is intended to address is that BTI gets
> left off since the dynamic linker is unable to enable PROT_BTI on the
> main executable.  We're looking to see that we end up with the stricter
> permissions checking of BTI, with the issue present landing pads
> replaced by NOPs will not fault but once the issue is addressed they
> should start faulting.

Ah, right -- I got the test backwards in my head.  Yes, that sounds
reasonable.

> > Looking at /proc/<pid>/maps after the process starts up may be a more
> > reliable approach, so see what the actual prot value is on the main
> > executable's text pages.
> 
> smaps rather than maps but yes, executable pages show up as "ex" and BTI
> adds a "bt" tag in VmFlags.

Fumbled that -- yes, I meant smaps!

Ignore me...

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
[email-masked]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel