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. > > > > > I agree. Even though the patches have my reviewed-by, I think we should > > > postpone them until we figure out a better W^X solution that does not > > > affect BTI (and if we can't, we revisit these patches). > > > > Indeed. I had been expecting this to follow the pattern of the previous > > nine months or so and be mostly ignored for the time being while > > Catalin's new series goes forward. Now that it's applied it might be > > worth keeping the first patch still in case someone else needs it but > > the second patch can probably wait. > > > > > 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. I would have expected the default to be on, because IMHO this set > corrects what at first glance just looks like a small oversight. 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 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. This fixes a bug we > have today, the other set creates a generic mechanism for the future. Okay, well, how about I drop this for now, and I'll Ack the ELF loader changes so this can go through the arm64 tree if there is consensus. -- Kees Cook
