Hi,
On 4/21/22 04:34, Catalin Marinas wrote:
On Wed, Apr 20, 2022 at 08:39:14AM -0500, Jeremy Linton wrote:
On 4/20/22 06:57, Mark Brown wrote:
On Wed, Apr 20, 2022 at 10:57:30AM +0100, Catalin Marinas wrote:
On Wed, Apr 20, 2022 at 10:36:13AM +0100, Will Deacon wrote:
Kees, please can you drop this series while Catalin's alternative solution
is under discussion (his Reviewed-by preceded the other patches)?
https://lore.kernel.org/r/20220413134946.2732468-1-catalin.marinas@xxxxxxx
Both series expose new behaviours to userspace and we don't need both.
[...]
Arguably, the two approaches are complementary but the way this series
turned out is for the BTI on main executable to be default off. I have a
worry that the feature won't get used, so we just carry unnecessary code
in the kernel. Jeremy also found this approach less than ideal:
https://lore.kernel.org/r/59fc8a58-5013-606b-f544-8277cda18e50@xxxxxxx
I'm not sure there was a fundamental concern with the approach there but
rather some pushback on the instance on turning it off by default.
Right, this one seems to have the smallest impact on systemd as it exists
today.
It had a bigger impact on glibc which had to rework the dynamic library
mapping to use munmap/mmap() instead of an mprotect() (though that's
already done). I think glibc still prefers the mprotect() approach for
dynamic libraries.
I would have expected the default to be on, because IMHO this set
corrects what at first glance just looks like a small oversight.
This was a design decision at the time, maybe not the best but it gives
us some flexibility (and we haven't thought of MDWE).
I find the ABI questions a bit theoretical, given that this should
only affect environments that don't exist outside of labs/development
orgs at this point (aka systemd services on HW that implements BTI).
The worry is not what breaks now but rather what happens when today's
distros will eventually be deployed on large-scale BTI-capable hardware.
It's a very small risk but non-zero. The idea is that if we come across
some weird problem, a fixed-up dynamic loader could avoid enabling BTI
on a per-process basis without the need to do this at the system level.
Personally I'm fine with this risk. Will is not and I respect his
position, hence I started the other thread to come up with a MDWE
alternative.
To clarify though, there is already a way to restore process
functionality to the small subset of services with the MDWE enabled,
which is simply to flip off MDWE on the service and let some future
loader flag clear PROT_BTI in the code path it would normally be setting
PROT_EXE|PROT_BIT on.
Or maybe simpler yet, we provide a tool which wipes out the gnu BTI note
on binaries that are found to have BTI bugs, thereby (correctly) fixing
the problem at its source. This is at least presumably doable if we are
also assuming we can update glibc/etc in any environment with the problem.
But again, systemd MDWE + BTI are less than a dozen processes, and if we
are worried about the big hammer of disabling BTI system wide, we
probably should have the ability to disable it per-process rather than
worrying about this obscure edge case.
The other approach works, and if the systemd folks are on board with it also
should solve the underlying problem, but it creates a bit of a compatibility
problem with existing containers/etc that might exist today (although
running systemd/services in a container is itself a discussion).
So, frankly, I don't see why they aren't complementary.
They are complementary, though if we change the MDWE approach, there's
less of a need for this patchset.
