On 3 August 2017 at 12:11, Maxime Villard <[email protected]> wrote: > Le 03/08/2017 à 10:42, matthew green a écrit : > >> Otherwise it has to be balanced. >>>> >>> >>> Certainly. It does not seem to me that moving compat_linux* into modules >>> is in >>> any way illegitimate or unbalanced. That's the opinion I was stating. >>> >> >> if you want to move useful and used by a large number of users >> functionality out of GENERIC and into modules then first perhaps >> you should consider fixing modules. >> >> there are a large number of basic functionality issues that no >> one pushing modules has solved yet. for a start, see lukem's >> original proposal about having a kernel+modules container, >> the functionality of which is a _essential_ before it's going >> to be considered OK to remove standard functionality from >> GENERIC. >> > > If your argument now is that there are technical difficulties that make > switching to a module approach a complicated business, beyond the > simplistic "I > don't want to type modload" stuff - which I don't agree with -, then > that's a > fair point. > > As I said, doing this work certainly involves, among others, finding a way > to > remove the many #ifdefs spread across the tree; and having tried to do so > two > years ago, I know it is a painful work. > > claiming that compat_linux isn't a major piece of usability >> is simply ignoring reality. >> > > I have never claimed it is not used. It is an important feature, but it > also > happens to have many places that need special care, which regularly turn > out to > be exploitable. If we can reduce the attack surface and at the same time > keep > the feature nearby, in a balanced way that does not impose too much burden > on > the regular users, then we should do it. But that's indeed ignoring the > technical difficulties behind achieving this goal. >
How about a sysctl to enable/disable any non netbsd_ compat usage. With it off compat code in GENERIC will not be run and (non netbsd32 etc) compat modules not loaded. David
