On Wed, 30 Nov 2016 23:13:25 -0500 Don Zickus <dzickus@xxxxxxxxxx> wrote: > On Wed, Nov 30, 2016 at 10:40:02AM -0800, Linus Torvalds wrote: > > On Wed, Nov 30, 2016 at 10:18 AM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote: > > > > > > Here's an initial rough hack at removing modversions. It gives an idea > > > of the complexity we're carrying for this feature (keeping in mind most > > > of the lines removed are generated parser). > > > > You definitely don't have to try to convince me. We've had many issues > > with modversions over the years. This was just the "last drop" as far > > as I'm concerned, we've had random odd crc generation failures due to > > some build races too. > > > > > In its place I just added a simple config option to override vermagic > > > so distros can manage it entirely themselves. > > > > So at least Fedora doesn't even enable CONFIG_MODVERSIONS as-is. I'm > > _hoping_ it's just Debian that wants this, and we'd need to get some > > input from the Debian people whether that "control vermagic" is > > sufficient? I suspect it isn't, but I can't come up with any simple > > alternate model either.. > > Oddly, I just posted a patch to enable this for Fedora and then someone > pointed me at this thread. :-/ > > Sorry for chiming in late, but yes RHEL is a big user of MODVERSIONS for our > kabi protection work. Despite our best intentions we still have lots of > partners and customers that provide value-add out-of-tree drivers to their > customers. These module builders requested we have a mechanism to allow > rolling modules forward for each of our minor RHEL updates without breaking > their drivers. > > They requested this to save time and money on rebuilding and retesting. It > also helps deal with situations where RHEL puts out a security fix or new > minor release and the provider of OOT driver has not released the > appropriate update. Customers like the ability to roll their special > drivers forward quickly to their schedule. > > Now we don't protect every symbol, just a select few that our meets our > customers needs (and developers willing to support it). > > Anyway, MODVERSIONS is our way of protecting our kabi for the last 10 years. > It isn't perfect and we have fixed the genksyms tool over the years, but so > far it mostly works fine. Okay. It would be good to get all the distros in on this. What I want to do is work out exactly what it is that modversions is giving you. We know it's fairly nasty code to maintain and it does not detect ABI changes very well. But it's not such a burden that we can't maintain it if there are good reasons to keep it. > I am not sure what 'control vermagic' is, but it sounds like a string check, > which won't protect against the boatload of backports we do to structs, > enums, and functions. Basically vermagic is the string all modules and the kernel get, which must match in order to load modules. If you have modversions disabled, then vermagic includes the kernel version. If modversions is enabled, then vermagic does not include the kernel version but the CRCs have to also match. Controlling it explicitly is just a couple of lines where a distro can control it (so they can update their kernel version without breaking). It's not meant to solve everything, just the first one. > Currently we are exploring various ways to get smarter here. The genksyms > tool has its limitations and handling kabi hacks in RHEL is getting > tiresome. > > I think GregKH pointed to one such tool, libabigail? We are working on > others too. > > > Circling back to enabling MODVERSIONS in Fedora, that was to start the > process of syncing Fedora with RHEL stuff in preparation for smarter tools. > > > If you take away MODVERSIONS, that would put a damper in our work, but > easily carried privately (much like MODSIGNING for 8 years until it went > upstream :-) ). I don't think that's necessary. A feature requirement for a distro is just as valid as any other user of upstream. I don't want to hinder any distro, I'm just still not quite seeing the big picture of exactly what functionality you need from the kernel. Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
