On Thu, Sep 26, 2019 at 10:17:51AM +0200, 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. >
I'm just an user, so I have just a question about the scope of the problem: Are the bugs and vulnerabilities in the compat_linux*, due to the compat glue added, opening code paths that can be exploited by a non-linux program for security threats or are the vulnerabilities only problems if a linux binary is run---and perhaps other (SCO) binaries? Because, as I see it, if this opens security problems even for the ones that do _not_ use linux (or other alien) binaries, as long as the features are still easily added (even by a post-install fix for pkgsrc programs) by loading a module for the ones who have to run alien programs, not including by default the compat_linux* modules (you don't speak about the NetBSD ABI compatibility, right?), seems reasonable. If the vulnerabilities can only be exploited by running Linux binaries, IMHO, the point is moot: the ones that don't run Linux binaries are not affected; the ones that do need to run some Linux binaries will have to add the feature so this adds a user's intervention for the very same result at the end. Furthermore, if the compatibility code is adding/opening problems that do not exist in the linux system emulated, it will mean that the security problem can be only exerted by someone creating a special version of a Linux program hoping it will be run under compat on NetBSD... Security is a matter of probabilities for me, and it seems that bugs (crashes) that is: not intentional "unfelicities" are more probable than malice in this case... Once more, I'm just a user. So the only thing I'm looking for is a precision about the scope of the problem---I will obviously cope with whatever decision is reached since I'm definitively not prepared to fork :-^ Best, -- Thierry Laronde <tlaronde +AT+ polynum +dot+ com> http://www.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C