On Sep 26, 10:17am, Maxime Villard wrote:
}
} I recently made a big set of changes to fix many bugs and vulnerabilities in
} compat_linux and compat_linux32, the majority of which have a security impact
} bigger than the Intel CPU bugs we hear about so much. These compat layers are
} enabled by default, so everybody is affected.
}
} Secteam is in a state where no one is willing to pull up all the changes to
} the stable branches, because of the effort. No one is willing to write a
} security advisory either. When I say "no one", it includes me.
}
} The proposal and discussion held in this 2017 thread still hold and are
} unchanged two years later:
}
} https://mail-index.netbsd.org/tech-kern/2017/07/31/msg022153.html
}
} The compat layers are largely untested, often broken, and are a security risk
} for everybody. Keeping them enabled for the <1% users interested means keeping
} vulnerabilities for the >99% who don't use these features.
Where did you get your statistics? I'm not saying that they
are wrong, just that I won't accept them without evidence.
} In the conversation above, we hit the problem that there was cross-dependency
} among compat modules, and we couldn't selectively disable specific layers.
} Today this is possible thanks to pgoyette's work. That is, it is possible to
} comment out "options COMPAT_LINUX" from GENERIC, and have a compat_linux.kmod
} which will modload correctly and be able to run Linux binaries out of the box.
} Under this scheme, the feature would be only one root command away from being
} enabled in the kernel.
This is assuming that you're running with options INSECURE,
otherwise you need to add it to /etc/modules.conf to have the module
loaded at boot time and remain loaded.
} Therefore, I am making today the same proposal as Taylor in 2017, because the
} problem is still there exactly as-is and we just hit it again; the solution
} however is more straightforward.
}-- End of excerpt from Maxime Villard
