Re: Proposal: Disable autoload of compat_xyz modules
On Sat, 16 Sep 2017, Martin Husemann wrote: On Sat, Sep 16, 2017 at 11:15:04AM -0400, Christos Zoulas wrote: It could be a sysctl listing by name the emulations available and another listing the emulations currently enabled. emul.available=linux,linux_32,svr4,svr4_32 emul.autoload=linux,linux_32 I would not mind excluding emulations from autoload in general, with no switch at all. We currently have a single autoload-enabling sysctl. Perhaps we should instead have several? One for device drivers (called from specfs), another for compat/emulations, etc.? +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Proposal: Disable autoload of compat_xyz modules
Le 16/09/2017 à 17:30, Martin Husemann a écrit : On Sat, Sep 16, 2017 at 11:15:04AM -0400, Christos Zoulas wrote: It could be a sysctl listing by name the emulations available and another listing the emulations currently enabled. emul.available=linux,linux_32,svr4,svr4_32 emul.autoload=linux,linux_32 I would not mind excluding emulations from autoload in general, with no switch at all. Yes, there is little interest for this. My initial noload diff did take that into account transparently, but it is true that it was perhaps too complicated compared to a simple sysctl. Maxime
Re: Proposal: Disable autoload of compat_xyz modules
Le 13/09/2017 à 22:00, Christos Zoulas a écrit : Can't we add a sysctl that controls the behavior and have autoload of the compat modules off by default? Well, let's just do this. I've written (and tested) [1] - it works. A new leaf is added in emul.linux, emul.linux.enabled={0,1}, which registers linux_execsw. Obviously, after applying this patch we'll have to remove compat_linux from the autoload array. And the same will have to be done in compat_linux32. Ok? Maxime [1] http://m00nbsd.net/garbage/module/sysctl.diff
Re: Proposal: Disable autoload of compat_xyz modules
On Sat, Sep 16, 2017 at 11:15:04AM -0400, Christos Zoulas wrote: > It could be a sysctl listing by name the emulations available and another > listing the emulations currently enabled. > > > emul.available=linux,linux_32,svr4,svr4_32 > emul.autoload=linux,linux_32 I would not mind excluding emulations from autoload in general, with no switch at all. When I need them I can do a manual modload, or add them to /etc/modules.conf/ include the option in the kernel and reboot. Martin
Re: Proposal: Disable autoload of compat_xyz modules
Le 16/09/2017 à 16:46, Christos Zoulas a écrit : On Sep 16, 4:42pm, m...@m00nbsd.net (Maxime Villard) wrote: -- Subject: Re: Proposal: Disable autoload of compat_xyz modules | Le 16/09/2017 à 16:36, Christos Zoulas a écrit : | > On Sep 16, 4:15pm, m...@m00nbsd.net (Maxime Villard) wrote: | > -- Subject: Re: Proposal: Disable autoload of compat_xyz modules | > | > | Le 13/09/2017 Ã 22:00, Christos Zoulas a écrit : | > | > Can't we add a sysctl that controls the behavior and have autoload | > | > of the compat modules off by default? | > | | > | Well, let's just do this. I've written (and tested) [1] - it works. A new | > | leaf is added in emul.linux, emul.linux.enabled={0,1}, which registers | > | linux_execsw. | > | | > | Obviously, after applying this patch we'll have to remove compat_linux from | > | the autoload array. And the same will have to be done in compat_linux32. | > | | > | Ok? | > | > Why? Leave it in the autoload, but fail to load it unless the sysctl is | > enabled... | | Does not work, the leaf is added by the module itself, so you can't sysctl it | to 'enabled=1' unless the module is already loaded... The sysctl does not have to live in the module space. Where do you put the helper then? It needs access to linux_execsw, which is in the module space.
Re: Proposal: Disable autoload of compat_xyz modules
On Sep 16, 5:09pm, m...@m00nbsd.net (Maxime Villard) wrote: -- Subject: Re: Proposal: Disable autoload of compat_xyz modules | > The sysctl does not have to live in the module space. | | Where do you put the helper then? It needs access to linux_execsw, which is in | the module space. It could be a sysctl listing by name the emulations available and another listing the emulations currently enabled. emul.available=linux,linux_32,svr4,svr4_32 emul.autoload=linux,linux_32 christos
Re: Proposal: Disable autoload of compat_xyz modules
Le 16/09/2017 à 16:36, Christos Zoulas a écrit : On Sep 16, 4:15pm, m...@m00nbsd.net (Maxime Villard) wrote: -- Subject: Re: Proposal: Disable autoload of compat_xyz modules | Le 13/09/2017 à 22:00, Christos Zoulas a écrit : | > Can't we add a sysctl that controls the behavior and have autoload | > of the compat modules off by default? | | Well, let's just do this. I've written (and tested) [1] - it works. A new | leaf is added in emul.linux, emul.linux.enabled={0,1}, which registers | linux_execsw. | | Obviously, after applying this patch we'll have to remove compat_linux from | the autoload array. And the same will have to be done in compat_linux32. | | Ok? Why? Leave it in the autoload, but fail to load it unless the sysctl is enabled... Does not work, the leaf is added by the module itself, so you can't sysctl it to 'enabled=1' unless the module is already loaded... Maxime
Re: Proposal: Disable autoload of compat_xyz modules
On Sep 16, 4:15pm, m...@m00nbsd.net (Maxime Villard) wrote: -- Subject: Re: Proposal: Disable autoload of compat_xyz modules | Le 13/09/2017 à 22:00, Christos Zoulas a écrit : | > Can't we add a sysctl that controls the behavior and have autoload | > of the compat modules off by default? | | Well, let's just do this. I've written (and tested) [1] - it works. A new | leaf is added in emul.linux, emul.linux.enabled={0,1}, which registers | linux_execsw. | | Obviously, after applying this patch we'll have to remove compat_linux from | the autoload array. And the same will have to be done in compat_linux32. | | Ok? Why? Leave it in the autoload, but fail to load it unless the sysctl is enabled... christos
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Sep 13, 2017 at 08:00:53PM +, Christos Zoulas wrote: > In article <20170910185148.ga7...@antioche.eu.org>, > Manuel Bouyer wrote: > >On Sun, Sep 10, 2017 at 08:46:52PM +0200, Maxime Villard wrote: > >> Le 10/09/2017 à 19:59, Manuel Bouyer a écrit : > >> > There's something I don't understand in this thread: what is the point > >> > of having the code in kernel if you still have to use modload to make it > >> > availble ? Why not comment it out in kernel and have users modload it > >> > if they want to ? > >> > >> said earlier, but on a different list, see > >> > >> http://mail-index.netbsd.org/source-changes-d/2017/08/04/msg009366.html > > > >OK. So you want this because (some?) compat modules can't be dynamically > >loaded. This problem should be fixed, instead of of worked around in > >such a ugly way. > > Can't we add a sysctl that controls the behavior and have autoload > of the compat modules off by default? and make the default conditional on MODULAR ? But still, it looks like a (ugly) hack rather than nice feature. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal: Disable autoload of compat_xyz modules
In article <20170910185148.ga7...@antioche.eu.org>, Manuel Bouyer wrote: >On Sun, Sep 10, 2017 at 08:46:52PM +0200, Maxime Villard wrote: >> Le 10/09/2017 à 19:59, Manuel Bouyer a écrit : >> > There's something I don't understand in this thread: what is the point >> > of having the code in kernel if you still have to use modload to make it >> > availble ? Why not comment it out in kernel and have users modload it >> > if they want to ? >> >> said earlier, but on a different list, see >> >> http://mail-index.netbsd.org/source-changes-d/2017/08/04/msg009366.html > >OK. So you want this because (some?) compat modules can't be dynamically >loaded. This problem should be fixed, instead of of worked around in >such a ugly way. Can't we add a sysctl that controls the behavior and have autoload of the compat modules off by default? christos
Re: Proposal: Disable autoload of compat_xyz modules
> A secure system is also a system which is simple. That ship sailed long ago, back around "options LKM" time. Indeed, security is most of why I turn that off in my kernels (MODULAR too, for OS revs recent enough to have it). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal: Disable autoload of compat_xyz modules
On Sun, Sep 10, 2017 at 09:03:27PM +0200, Maxime Villard wrote: > If you have a fix to untangle this mess, be my guest. I proposed to > reimplement > the 43* functions separately into compat_linux, people disagreed. Others have proposed to move it to a compat_common module, and this is the way to go I guess. But I won't do it as I'm happy with COMPAT_LINUX being enabled by default (despite eventual bugs). -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal: Disable autoload of compat_xyz modules
Le 10/09/2017 à 20:51, Manuel Bouyer a écrit : On Sun, Sep 10, 2017 at 08:46:52PM +0200, Maxime Villard wrote: Le 10/09/2017 à 19:59, Manuel Bouyer a écrit : There's something I don't understand in this thread: what is the point of having the code in kernel if you still have to use modload to make it availble ? Why not comment it out in kernel and have users modload it if they want to ? said earlier, but on a different list, see http://mail-index.netbsd.org/source-changes-d/2017/08/04/msg009366.html OK. So you want this because (some?) compat modules can't be dynamically loaded. This problem should be fixed, instead of of worked around in such a ugly way. If you have a fix to untangle this mess, be my guest. I proposed to reimplement the 43* functions separately into compat_linux, people disagreed.
Re: Proposal: Disable autoload of compat_xyz modules
On Sun, Sep 10, 2017 at 08:46:52PM +0200, Maxime Villard wrote: > Le 10/09/2017 à 19:59, Manuel Bouyer a écrit : > > There's something I don't understand in this thread: what is the point > > of having the code in kernel if you still have to use modload to make it > > availble ? Why not comment it out in kernel and have users modload it > > if they want to ? > > said earlier, but on a different list, see > > http://mail-index.netbsd.org/source-changes-d/2017/08/04/msg009366.html OK. So you want this because (some?) compat modules can't be dynamically loaded. This problem should be fixed, instead of of worked around in such a ugly way. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal: Disable autoload of compat_xyz modules
Le 10/09/2017 à 19:59, Manuel Bouyer a écrit : There's something I don't understand in this thread: what is the point of having the code in kernel if you still have to use modload to make it availble ? Why not comment it out in kernel and have users modload it if they want to ? said earlier, but on a different list, see http://mail-index.netbsd.org/source-changes-d/2017/08/04/msg009366.html
Re: Proposal: Disable autoload of compat_xyz modules
There's something I don't understand in this thread: what is the point of having the code in kernel if you still have to use modload to make it availble ? Why not comment it out in kernel and have users modload it if they want to ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal: Disable autoload of compat_xyz modules
Le 10/09/2017 à 17:24, Greg Troxel a écrit : [...] Reading maxv@'s suggestion, I wondered about autoload of non-built-in modules (but maybe that is already disabled). My quick reaction is that it would be nice if the "don't autoload" flag had the same behavior for builtin and non-builtin modules, so that builtin/not is just a linking style thing, and not more. Modules can be autoloaded from the filesystem, in exec_autoload(). In such a case, we want the kernel to do a MODULE_CMD_INIT on them, regardless of whether they have the MODINFO_BUILTIN_NOLOAD flag set or not. This flag must be parsed exclusively for the builtin modules, and not the rest. [...] expand config(8) to be able to set "noautoload", so that if a module is included as part of a kernel, it will be marked noautoload if and noly if the flag is on the line, regardless of defaults. This would not affect the modules in stand; they'd still have the default value of the noautoload flag from the default This would be good. But I guess it entails introducing a new "module" keyword, as opposed to the current "options" used for a certain number of drivers. Another short-term alternative would be to add options that set MODINFO_BUILTIN_NOLOAD. Something like: #ifdef COMPAT_LINUX_BUILTIN_NOLOAD MD1 MD2 MD3, MODINFO_BUILTIN_NOLOAD); #else MD1 MD2 MD3, 0); #endif options COMPAT_LINUX options COMPAT_LINUX_BUILTIN_NOLOAD People that want the module builtin+loaded would comment the second line. Note that this is similar to the notion that shipping functions for a kernel module and dynamically registering them for use are two different unrelated options - which is more or less what was suggested earlier in this thread. But it indeed becomes a bit more complicated to understand and use... Maxime
Re: Proposal: Disable autoload of compat_xyz modules
> Am 10.09.2017 um 12:35 schrieb Maxime Villard : > > Le 10/09/2017 à 12:24, Paul Goyette a écrit : >> On Sun, 10 Sep 2017, Maxime Villard wrote: >>> Re-thinking about this again, it seems to me we could simply add a flags >>> field in modinfo_t, with a bit that says "if this module is builtin, then >>> don't load it". To use compat_xyz, you'll have to type modload, and the >>> kernel will load the module from the builtin list. >>> >>> Something like [1] (from memory, not tested at all). Obviously this patch >>> is not complete, since we need to update each MODULE(). >>> >>> While it is clear that it does not solve the cross-dependency issue we're >>> having, it does reduce the attack surface almost as much as if the module >>> was not builtin, with very little effort. Cheap, but relevant. >>> >>> [1] http://m00nbsd.net/garbage/module/noload.diff >> Well, probably not quite what you wanted, but if a module is built-in >> you can disable it by using modunload(8). Any built-in module which has >> been disabled in this manner needs to be explicitly reload manually, and >> you'll need to additionally specify the -f option to modload(8). > > I know. > >> Perhaps /etc/rc.d/modules can be updated to have both a load and an >> unload phase, with appropriate syntax for the associated config file. > > Thought about this too, but it seemed bizarre to me to have the kernel load > modules, then rc.d/modules unload them, and then the user reload them. > >> This would be a lot cleaner IMHO than updating individual modules. > > I believe per-module flags can be useful in the future, and not just in the > noload case; a module could want to tell the kernel how it wants to be loaded. I think "how a module should be loaded" should be left to the sysadmins discretion, not the module itself. Besides that, I don't like the whole idea of built-in modules not being activated by default, after all that is how it has been for many releases. > > Maxime
Re: Proposal: Disable autoload of compat_xyz modules
Manuel Bouyer writes: > On Sun, Sep 10, 2017 at 12:17:58PM +0200, Maxime Villard wrote: >> Re-thinking about this again, it seems to me we could simply add a flags >> field in modinfo_t, with a bit that says "if this module is builtin, then >> don't load it". To use compat_xyz, you'll have to type modload, and the >> kernel will load the module from the builtin list. > > If I compile a kernel with a built-in module, I expect this module to > be active. Otherwise I don't compile it. But maxv@ is not talking about you deciding to compile a kernel and putting in a line for a module. The question is about compat modules that are in GENERIC, and how to choose defaults so that users who want to use them aren't inconveniencyed and that users that don't want to use them don't have reduced security. Reading maxv@'s suggestion, I wondered about autoload of non-built-in modules (but maybe that is already disabled). My quick reaction is that it would be nice if the "don't autoload" flag had the same behavior for builtin and non-builtin modules, so that builtin/not is just a linking style thing, and not more. But I see your point about respecting explicit configuration. So I wonder about (without providing a patch of course): having a per-compiled-module flag to disable autoload, as suggested (in builtin and not, unless I'm confused) set the noautoload flag to true in modules that are deemed an unnecessary risk to people who have not made a choice to use them [so far this is maxv's proposal, I think] expand config(8) to be able to set "noautoload", so that if a module is included as part of a kernel, it will be marked noautoload if and noly if the flag is on the line, regardless of defaults. This would not affect the modules in stand; they'd still have the default value of the noautoload flag from the default add the noautload flag to in-tree kernel configs for the above modules which means that in Manuel's custom kernel he can just leave out the noautoload flag and then that kernel will behave as always. People trying to run a MODULAR kernel would still need to either edit their module sources to change the flag (which if you are a MODULAR type, is more or less like editing GENERIC) or do manual modload. Overall I find this disabling of things by default but leaving them in far preferable to not building them or removing them from sources in terms of getting to a better place in the security/usability trade space. signature.asc Description: PGP signature
Re: Proposal: Disable autoload of compat_xyz modules
Le 10/09/2017 à 12:43, Manuel Bouyer a écrit : On Sun, Sep 10, 2017 at 12:38:52PM +0200, Maxime Villard wrote: Le 10/09/2017 à 12:22, Manuel Bouyer a écrit : On Sun, Sep 10, 2017 at 12:17:58PM +0200, Maxime Villard wrote: Re-thinking about this again, it seems to me we could simply add a flags field in modinfo_t, with a bit that says "if this module is builtin, then don't load it". To use compat_xyz, you'll have to type modload, and the kernel will load the module from the builtin list. If I compile a kernel with a built-in module, I expect this module to be active. Otherwise I don't compile it. This kind of all-or-nothing mindset just does not work if we want to reduce the attack surface but still have features nearby. A level of indirection is needed, and it didn't seem to me that having per-module flags was a really bad idea. A secure system is also a system which is simple. Adding indirections doesn't keep the system simple. True enough; but in this particular case, leaving compat features enabled just for the sake of simplicity produces a system that is much more vulnerable than if it had one level of indirection.
Re: Proposal: Disable autoload of compat_xyz modules
Le 10/09/2017 à 13:37, Manuel Bouyer a écrit : On Sun, Sep 10, 2017 at 01:32:27PM +0200, Maxime Villard wrote: Le 10/09/2017 à 13:16, Manuel Bouyer a écrit : On Sun, Sep 10, 2017 at 01:13:14PM +0200, Maxime Villard wrote: True enough; but in this particular case, leaving compat features enabled just for the sake of simplicity produces a system that is much more vulnerable than if it had one level of indirection. If you know it's vulnerable then fix it, do not spend time trying to work around it. Yes, compat_linux/linux32/svr4/svr4_32/ibcs2/etc are probably still vulnerable, as is the native exec path or compat_netbsd32 ... yes, but these are critical to the functioning of the system, contrary to the ones I'm talking about
Re: Proposal: Disable autoload of compat_xyz modules
On Sun, Sep 10, 2017 at 01:32:27PM +0200, Maxime Villard wrote: > Le 10/09/2017 à 13:16, Manuel Bouyer a écrit : > > On Sun, Sep 10, 2017 at 01:13:14PM +0200, Maxime Villard wrote: > > > True enough; but in this particular case, leaving compat features enabled > > > just > > > for the sake of simplicity produces a system that is much more vulnerable > > > than > > > if it had one level of indirection. > > > > If you know it's vulnerable then fix it, do not spend time trying to > > work around it. > > Yes, compat_linux/linux32/svr4/svr4_32/ibcs2/etc are probably still > vulnerable, as is the native exec path or compat_netbsd32 ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal: Disable autoload of compat_xyz modules
Le 10/09/2017 à 13:16, Manuel Bouyer a écrit : On Sun, Sep 10, 2017 at 01:13:14PM +0200, Maxime Villard wrote: True enough; but in this particular case, leaving compat features enabled just for the sake of simplicity produces a system that is much more vulnerable than if it had one level of indirection. If you know it's vulnerable then fix it, do not spend time trying to work around it. Yes, compat_linux/linux32/svr4/svr4_32/ibcs2/etc are probably still vulnerable, but in ways that are far from being obvious. Just look at the vulnerability I fixed in linux32 a few days ago. It was agreed here that somehow there needs to be a way to reduce the attack surface by default without totally "disabling" the features that have a common use case - what I'm discussing now is how to achieve that, not whether to do it or not. Having said that, I can understand that my noload proposal may not be the best. Maxime
Re: Proposal: Disable autoload of compat_xyz modules
On Sun, Sep 10, 2017 at 01:13:14PM +0200, Maxime Villard wrote: > True enough; but in this particular case, leaving compat features enabled just > for the sake of simplicity produces a system that is much more vulnerable than > if it had one level of indirection. If you know it's vulnerable then fix it, do not spend time trying to work around it. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal: Disable autoload of compat_xyz modules
Le 10/09/2017 à 12:22, Manuel Bouyer a écrit : On Sun, Sep 10, 2017 at 12:17:58PM +0200, Maxime Villard wrote: Re-thinking about this again, it seems to me we could simply add a flags field in modinfo_t, with a bit that says "if this module is builtin, then don't load it". To use compat_xyz, you'll have to type modload, and the kernel will load the module from the builtin list. If I compile a kernel with a built-in module, I expect this module to be active. Otherwise I don't compile it. This kind of all-or-nothing mindset just does not work if we want to reduce the attack surface but still have features nearby. A level of indirection is needed, and it didn't seem to me that having per-module flags was a really bad idea.
Re: Proposal: Disable autoload of compat_xyz modules
On Sun, Sep 10, 2017 at 12:38:52PM +0200, Maxime Villard wrote: > Le 10/09/2017 à 12:22, Manuel Bouyer a écrit : > > On Sun, Sep 10, 2017 at 12:17:58PM +0200, Maxime Villard wrote: > > > Re-thinking about this again, it seems to me we could simply add a flags > > > field in modinfo_t, with a bit that says "if this module is builtin, then > > > don't load it". To use compat_xyz, you'll have to type modload, and the > > > kernel will load the module from the builtin list. > > > > If I compile a kernel with a built-in module, I expect this module to > > be active. Otherwise I don't compile it. > > This kind of all-or-nothing mindset just does not work if we want to reduce > the attack surface but still have features nearby. A level of indirection is > needed, and it didn't seem to me that having per-module flags was a really bad > idea. A secure system is also a system which is simple. Adding indirections doesn't keep the system simple. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal: Disable autoload of compat_xyz modules
Le 10/09/2017 à 12:24, Paul Goyette a écrit : On Sun, 10 Sep 2017, Maxime Villard wrote: Re-thinking about this again, it seems to me we could simply add a flags field in modinfo_t, with a bit that says "if this module is builtin, then don't load it". To use compat_xyz, you'll have to type modload, and the kernel will load the module from the builtin list. Something like [1] (from memory, not tested at all). Obviously this patch is not complete, since we need to update each MODULE(). While it is clear that it does not solve the cross-dependency issue we're having, it does reduce the attack surface almost as much as if the module was not builtin, with very little effort. Cheap, but relevant. [1] http://m00nbsd.net/garbage/module/noload.diff Well, probably not quite what you wanted, but if a module is built-in you can disable it by using modunload(8). Any built-in module which has been disabled in this manner needs to be explicitly reload manually, and you'll need to additionally specify the -f option to modload(8). I know. Perhaps /etc/rc.d/modules can be updated to have both a load and an unload phase, with appropriate syntax for the associated config file. Thought about this too, but it seemed bizarre to me to have the kernel load modules, then rc.d/modules unload them, and then the user reload them. This would be a lot cleaner IMHO than updating individual modules. I believe per-module flags can be useful in the future, and not just in the noload case; a module could want to tell the kernel how it wants to be loaded. Maxime
Re: Proposal: Disable autoload of compat_xyz modules
On Sun, 10 Sep 2017, Maxime Villard wrote: Re-thinking about this again, it seems to me we could simply add a flags field in modinfo_t, with a bit that says "if this module is builtin, then don't load it". To use compat_xyz, you'll have to type modload, and the kernel will load the module from the builtin list. Something like [1] (from memory, not tested at all). Obviously this patch is not complete, since we need to update each MODULE(). While it is clear that it does not solve the cross-dependency issue we're having, it does reduce the attack surface almost as much as if the module was not builtin, with very little effort. Cheap, but relevant. [1] http://m00nbsd.net/garbage/module/noload.diff Well, probably not quite what you wanted, but if a module is built-in you can disable it by using modunload(8). Any built-in module which has been disabled in this manner needs to be explicitly reload manually, and you'll need to additionally specify the -f option to modload(8). Perhaps /etc/rc.d/modules can be updated to have both a load and an unload phase, with appropriate syntax for the associated config file. This would be a lot cleaner IMHO than updating individual modules. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Proposal: Disable autoload of compat_xyz modules
On Sun, Sep 10, 2017 at 12:17:58PM +0200, Maxime Villard wrote: > Re-thinking about this again, it seems to me we could simply add a flags > field in modinfo_t, with a bit that says "if this module is builtin, then > don't load it". To use compat_xyz, you'll have to type modload, and the > kernel will load the module from the builtin list. If I compile a kernel with a built-in module, I expect this module to be active. Otherwise I don't compile it. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal: Disable autoload of compat_xyz modules
Re-thinking about this again, it seems to me we could simply add a flags field in modinfo_t, with a bit that says "if this module is builtin, then don't load it". To use compat_xyz, you'll have to type modload, and the kernel will load the module from the builtin list. Something like [1] (from memory, not tested at all). Obviously this patch is not complete, since we need to update each MODULE(). While it is clear that it does not solve the cross-dependency issue we're having, it does reduce the attack surface almost as much as if the module was not builtin, with very little effort. Cheap, but relevant. [1] http://m00nbsd.net/garbage/module/noload.diff
Re: Proposal: Disable autoload of compat_xyz modules
On Mon, Jul 31, 2017 at 09:39:42PM +, Taylor R Campbell wrote: > compat_ultrix You can remove this immediately with no functional change. All of the archs that could run ULTRIX dont have module support on netbsd. (This table is handy: https://www.netbsd.org/developers/features/ )
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 12:35:22PM +, Taylor R Campbell wrote: > > I propose to disable the following modules by default, but leave the > code so you can still modload them or include them in your custom > kernel config if you want: > > compat_osf1 This probably still has users on Alpha. > compat_ultrix > exec_ecoff These definitely have users on pmax, unless the last pmax has finally died. Thor
Re: Proposal: Disable autoload of compat_xyz modules
On Aug 3, 11:35am, m...@netbsd.org wrote: } On Thu, Aug 03, 2017 at 01:23:17AM +0200, Emmanuel Dreyfus wrote: } > Taylor R Campbell wrote: } > } > Once every compatibility module would not loaded by default, pehaps the } > compat_xxx module could be loaded automatically if /emul/xxx/ exists? } > } > The presence of that hierarchy means the system administrator really } > meant to use compat_xxx, and it would avoid breaking existing system at } > upgrade time. } } Sounds good. } } By the way, isn't that what happens in practice anyway? the only way to } reach the COMPAT_OTHEROS code is to first exec a binary, which looks for } an interpreter in /emul/otheros. If one doesn't exist, exec will fail. Not if the binary is statically linked. I suspect that would be the common case for at least some of the emulations. Some of them might not even support dynamic linking. } I would feel more assured if COMPAT_SVR4 didn't exist in my kernels, but } I suspect the vulnerability doesn't affect me. } }-- End of excerpt from m...@netbsd.org
Re: Proposal: Disable autoload of compat_xyz modules
On Aug 3, 4:09pm, Emmanuel Dreyfus wrote: } Subject: Re: Proposal: Disable autoload of compat_xyz modules } wrote: } } > By the way, isn't that what happens in practice anyway? the only way to } > reach the COMPAT_OTHEROS code is to first exec a binary, which looks for } > an interpreter in /emul/otheros. If one doesn't exist, exec will fail. } } Joerg mentionned the statically linked binary. Even for dynamic } binaries, there may also be some code executed in the compat module to } check if it can run the binary. Also, strictly speaking, as I understand it, the interpreter doesn't have to be /emul/otheros. It's just that /emul/otheros is searched first and if not there, then a second check is made without that prefix. Certainly this is the way it used to be. I plopped a NetBSD kernel on an otherwise stock SunOS system once, and apart from KVM grovellers, it worked perfectly. }-- End of excerpt from Emmanuel Dreyfus
Re: Proposal: Disable autoload of compat_xyz modules
On Aug 3, 10:07am, Maxime Villard wrote: } Le 02/08/2017 à 23:08, Joerg Sonnenberger a écrit : } > On Wed, Aug 02, 2017 at 08:52:15PM +0200, Maxime Villard wrote: } >> I disagree. The cost of doing a modload is low enough compared to the } >> configuration needed to use compat_linux. Just like the command you quoted. } > } > If I wanted OpenBSD, I know were to get it. There is a balance between } > pissing off people and providing security. } } In your opinion, what is pissing people off the most: having to do a modload, } or being automatically vulnerable because some guys want to be able to do } "make install opera etc" without typing one more command? What is pissing off people the most is one random developer, who is not even a portmaster or member of core, making major decisions about the project on their own accord, and basically behaving like a petty little dictator. Even if it is the correct thing to do, which is debatable, it is not a decision that should be made by a single random developer. This is NetBSD, not MaxBSD. } Strange understanding of pissing off people. } } > If you want to minimize the } > attack surface at all cost of *your* system, you are free to do so. } } Forgive me for feeling a little sorry for the users that are } regularly affected by vulnerabilities in compat_linux*. Who are these users? Where are the complaints? } > 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. YOU were not talking about turning them into modules. YOU were talking about deleting them. I noted that you already deleted the i386 version and I can't find any public discussion about that. } > So far modules have primarily created } > problems for a lot of people without any gain. } } And so have compat_linux and compat_linux32. Huh?!? } > Disabling rarely used } > code is one thing, disabling commonly used code is something else. Stop } > pushing for "security" as a single goal above else. It doesn't make you } > more credible, it just makes people shot down sensible proposal as knee } > jerk reaction because they are waiting for the insane follow-up. } } Getting credibility and recognition from someone like you, Joerg, is not } something I particularly care about. We're not in the jungle, we're here to } talk; people are giving their opinion, I'm giving mine. I fixed 11 of the 11 YOU are giving a lot more then just opinion. YOU are threatening to single handedly take action if you don't get the response you want. } vulnerabilities that affected our compat options these last ten years, so I do } have my word to say when it comes to security and compatibility, just like } everyone else. "Say" is one thing, action is another thing entirely. }-- End of excerpt from Maxime Villard
Re: Proposal: Disable autoload of compat_xyz modules
wrote: > By the way, isn't that what happens in practice anyway? the only way to > reach the COMPAT_OTHEROS code is to first exec a binary, which looks for > an interpreter in /emul/otheros. If one doesn't exist, exec will fail. Joerg mentionned the statically linked binary. Even for dynamic binaries, there may also be some code executed in the compat module to check if it can run the binary. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: Proposal: Disable autoload of compat_xyz modules
On Thu, Aug 03, 2017 at 11:35:43AM +, m...@netbsd.org wrote: > By the way, isn't that what happens in practice anyway? the only way to > reach the COMPAT_OTHEROS code is to first exec a binary, which looks for > an interpreter in /emul/otheros. If one doesn't exist, exec will fail. Only if it is dynamically linked. It doesn't have to be in the root filesystem either in case of chroots. Joerg
Re: Proposal: Disable autoload of compat_xyz modules
On 3 August 2017 at 12:11, Maxime Villard 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
Re: Proposal: Disable autoload of compat_xyz modules
On Thu, Aug 03, 2017 at 01:23:17AM +0200, Emmanuel Dreyfus wrote: > Taylor R Campbell wrote: > > Once every compatibility module would not loaded by default, pehaps the > compat_xxx module could be loaded automatically if /emul/xxx/ exists? > > The presence of that hierarchy means the system administrator really > meant to use compat_xxx, and it would avoid breaking existing system at > upgrade time. Sounds good. By the way, isn't that what happens in practice anyway? the only way to reach the COMPAT_OTHEROS code is to first exec a binary, which looks for an interpreter in /emul/otheros. If one doesn't exist, exec will fail. I would feel more assured if COMPAT_SVR4 didn't exist in my kernels, but I suspect the vulnerability doesn't affect me.
Re: Proposal: Disable autoload of compat_xyz modules
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. Maxime
Re: Proposal: Disable autoload of compat_xyz modules
Le 03/08/2017 à 04:25, David Holland a écrit : On Wed, Aug 02, 2017 at 08:52:15PM +0200, Maxime Villard wrote: > [stuff] If you insist on going on delete/disable sprees without discussing beforehand, can you at least, when doing these, go through and make sure the things you've removed don't leave behind dangling hooks in the main kernel? Or if they do, at least try to identify them? There was a namei special case in COMPAT_SVR4, and I'm not particularly unhappy to see the end of it, but I can't imagine it was the only such thing we're carrying around. That's an unrelated discussion, but: Which place are you referring to? While it is clear that many pieces of compat_svr4 are spread around the tree, it didn't seem to me that they were specific to the i386 parts I removed. If they are not, there is no reason to remove them, since they are certainly needed on sparc/sparc64. Otherwise if you've identified remaining lurking pieces, feel free to tell me about it - I obviously I'm not interested in letting dead code around. Maxime
Re: Proposal: Disable autoload of compat_xyz modules
On 02.08.2017 22:40, Joerg Sonnenberger wrote: > On Wed, Aug 02, 2017 at 09:17:05PM +0200, Kamil Rytarowski wrote: >> I think we can go into a different direction. Instead of disabling the >> code - we could turn all compat_ into dynamically loadable modules. I >> would profit from it for functional out-of-the-box compat for older >> NetBSD releases (a.out executables). > > No, please not. It is already quite unclear how many of them even work > properly and a GENERIC kernel should continue to work as it is. If you > want a MODULAR kernel, pick one. Don't force it on every one else. > > Joerg > I was experimenting with MODULAR and this kernel certainly needs more work - after fixing some bugs it was still broken for me. I feel like going the path to improve modules and develop syscall fuzzers on releng machines is better than removing code from GENERIC. Paul mentioned few bugs that have to be addressed. I try to help the current efforts with fuzzing the rump kernels. I cannot help with compat layers now, first I will attempt to get better debugging facilities inside the kernel like perhaps kasan. signature.asc Description: OpenPGP digital signature
Re: Proposal: Disable autoload of compat_xyz modules
On Thu, Aug 03, 2017 at 10:07:21AM +0200, Maxime Villard wrote: > Le 02/08/2017 à 23:08, Joerg Sonnenberger a écrit : > > On Wed, Aug 02, 2017 at 08:52:15PM +0200, Maxime Villard wrote: > > > I disagree. The cost of doing a modload is low enough compared to the > > > configuration needed to use compat_linux. Just like the command you > > > quoted. > > > > If I wanted OpenBSD, I know were to get it. There is a balance between > > pissing off people and providing security. > > In your opinion, what is pissing people off the most: having to do a modload, > or being automatically vulnerable because some guys want to be able to do > "make install opera etc" without typing one more command? But it is not just a modload. It means having modules in first place, synchronised with the kernel for starters. But that's pretty irrelevant already. > > If you want to minimize the > > attack surface at all cost of *your* system, you are free to do so. > > Forgive me for feeling a little sorry for the users that are regularly > affected > by vulnerabilities in compat_linux*. It is exactly this attitude that is the problem. > > Disabling rarely used > > code is one thing, disabling commonly used code is something else. Stop > > pushing for "security" as a single goal above else. It doesn't make you > > more credible, it just makes people shot down sensible proposal as knee > > jerk reaction because they are waiting for the insane follow-up. > > Getting credibility and recognition from someone like you, Joerg, is not > something I particularly care about. We're not in the jungle, we're here to > talk; people are giving their opinion, I'm giving mine. I fixed 11 of the 11 > vulnerabilities that affected our compat options these last ten years, so I do > have my word to say when it comes to security and compatibility, just like > everyone else. > > If you want to be among people that cannot talk, you know where to go, and > this place is called openbsd-tech. Let me tell you a little fact of live. Security doesn't "Get the job done". It won't pay the bill, it won't entertain the significant other wanting by showing a movie in the evening etc. In fact, it is more likely to be a hassle for either. Of course, a security problem can also mean a lot of work, but that depends on just as many other factors. Just because a change improves security doesn't make it good. Especially if it stops people from using the system or forces them to jump through hops. There have been many instances lately of "Let's make the system more secure by turning on X by default" lately, most not even triggered by you. Many of those cases have broken a lot of software people care about, often in subtle ways. PaX mprotect and ASLR for example. It doesn't help that there is a strong separation between those pushing for the features to be enabled by default and those having to deal with the fallout. Now, it doesn't matter what you think of my opinion. What *should* matter though is what I tried to explain and what you complete ignored again. If the first reaction to many of your proposals is "stop breaking things", it means that you have at the very least a communication problem. NetBSD works on the principle of building a consensus with arbitration by core when necessary. It doesn't help the process if there is a neagtive majority even before starting reading the proposal. Joerg
re: Proposal: Disable autoload of compat_xyz modules
> > 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. this has nothing to do with compat_linux. it has to do with what we have decided about modules vs GENERIC some years ago, and the reasons haven't changed. claiming that compat_linux isn't a major piece of usability is simply ignoring reality. thus, it still belongs in GENERIC. (we do have some standard functionality in modules, but that is a licensing issue. we can't have dtrace/etc statically in our kernel without it being a problem.) .mrg.
Re: Proposal: Disable autoload of compat_xyz modules
Le 02/08/2017 à 23:08, Joerg Sonnenberger a écrit : On Wed, Aug 02, 2017 at 08:52:15PM +0200, Maxime Villard wrote: I disagree. The cost of doing a modload is low enough compared to the configuration needed to use compat_linux. Just like the command you quoted. If I wanted OpenBSD, I know were to get it. There is a balance between pissing off people and providing security. In your opinion, what is pissing people off the most: having to do a modload, or being automatically vulnerable because some guys want to be able to do "make install opera etc" without typing one more command? Strange understanding of pissing off people. If you want to minimize the attack surface at all cost of *your* system, you are free to do so. Forgive me for feeling a little sorry for the users that are regularly affected by vulnerabilities in compat_linux*. 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. So far modules have primarily created problems for a lot of people without any gain. And so have compat_linux and compat_linux32. Disabling rarely used code is one thing, disabling commonly used code is something else. Stop pushing for "security" as a single goal above else. It doesn't make you more credible, it just makes people shot down sensible proposal as knee jerk reaction because they are waiting for the insane follow-up. Getting credibility and recognition from someone like you, Joerg, is not something I particularly care about. We're not in the jungle, we're here to talk; people are giving their opinion, I'm giving mine. I fixed 11 of the 11 vulnerabilities that affected our compat options these last ten years, so I do have my word to say when it comes to security and compatibility, just like everyone else. If you want to be among people that cannot talk, you know where to go, and this place is called openbsd-tech. Maxime
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 08:52:15PM +0200, Maxime Villard wrote: > [stuff] If you insist on going on delete/disable sprees without discussing beforehand, can you at least, when doing these, go through and make sure the things you've removed don't leave behind dangling hooks in the main kernel? Or if they do, at least try to identify them? There was a namei special case in COMPAT_SVR4, and I'm not particularly unhappy to see the end of it, but I can't imagine it was the only such thing we're carrying around. -- David A. Holland dholl...@netbsd.org
Re: Proposal: Disable autoload of compat_xyz modules
On Aug 2, 5:02pm, Martin Husemann wrote: } On Wed, Aug 02, 2017 at 07:56:50AM -0700, Brian Buhrow wrote: } > Hello. My feeling is that the cost of requiring a modload to use } > compat_linux and compat_linux32 is fine. My concern is that by taking it } > out of the GENERIC kernel configuration, we lose the regular testing, such } > as it is, with the daily builds. Sure, the module gets built, but it could } > be a while before it gets loaded and run by the test harness. Today, with } > these modules in GENERIC, the modules get loaded as a matter of course. } > Is there a way to rig our test harness so that you can take the modules out } > of the GENERIC kernel configuration and still do more than compile-time } > test them? } } The tests exercise quite a few modules, but currently testing compat stuff } is tricky (due to the extra setup needed on the test machine to have a } create the compat runtime environment). } } Just doing a few modctl and load some of them is simple, but what does that } actually buy us? Originally, it was my thought that compiling it as a module and not using it is the same as compiling it into the kernel and not using it. However, it is possible to create a module that fails to load due to run time linking issues. So, having a test that does modload ensures that the module can still linked into the kernel. }-- End of excerpt from Martin Husemann
Re: Proposal: Disable autoload of compat_xyz modules
Taylor R Campbell wrote: > This is a compromise between preserving the functionality and reducing > attack surface for what I hypothesize are a majority of users who do > not use it. Under this proposal, the code will remain, and still be > built, and still be usable -- it will just not be enabled by default. Once every compatibility module would not loaded by default, pehaps the compat_xxx module could be loaded automatically if /emul/xxx/ exists? The presence of that hierarchy means the system administrator really meant to use compat_xxx, and it would avoid breaking existing system at upgrade time. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, 2 Aug 2017, Kamil Rytarowski wrote: I think we can go into a different direction. Instead of disabling the code - we could turn all compat_ into dynamically loadable modules. I would profit from it for functional out-of-the-box compat for older NetBSD releases (a.out executables). Most of the compat code is already available as dynamically-loadable modules. But there are a few exceptions. See my PRs kern/51597 and kern/52193 for a couple examples. For security purposes people can raise securelevel and prevent any modules from insertion into the kernel. They can also adjust kern.moudle.autoload to enable/disable automatic loading of modules (modulo securelevel). +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 08:52:15PM +0200, Maxime Villard wrote: > I disagree. The cost of doing a modload is low enough compared to the > configuration needed to use compat_linux. Just like the command you quoted. If I wanted OpenBSD, I know were to get it. There is a balance between pissing off people and providing security. If you want to minimize the attack surface at all cost of *your* system, you are free to do so. Otherwise it has to be balanced. So far modules have primarily created problems for a lot of people without any gain. Disabling rarely used code is one thing, disabling commonly used code is something else. Stop pushing for "security" as a single goal above else. It doesn't make you more credible, it just makes people shot down sensible proposal as knee jerk reaction because they are waiting for the insane follow-up. Joerg
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 09:17:05PM +0200, Kamil Rytarowski wrote: > I think we can go into a different direction. Instead of disabling the > code - we could turn all compat_ into dynamically loadable modules. I > would profit from it for functional out-of-the-box compat for older > NetBSD releases (a.out executables). No, please not. It is already quite unclear how many of them even work properly and a GENERIC kernel should continue to work as it is. If you want a MODULAR kernel, pick one. Don't force it on every one else. Joerg
Re: Proposal: Disable autoload of compat_xyz modules
Le 02/08/2017 à 20:02, Taylor R Campbell a écrit : Date: Wed, 2 Aug 2017 16:11:16 + From: m...@netbsd.org I can 'cd pkgsrc/www/opera; make install; opera' and get a closed source browser that works as is, without even realizing it relies on COMPAT_LINUX to work. % cd www/opera && bmake package ERROR: This package has set PKG_FAIL_REASON: ERROR: opera-12.16 has an unacceptable license condition: ERROR: opera-1200-license ERROR: You can mark the license ``opera-1200-license'' as acceptable by adding ERROR: ACCEPTABLE_LICENSES+= opera-1200-license ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/mk.conf or by adding ERROR: ACCEPTABLE_LICENSES= opera-1200-license ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/pkg_install.conf. ERROR: The following command will show you the license text: ERROR: /home/riastradh/pkgsrc/current/pkg/bin/bmake show-license Unless some miracle happens, NetBSD will remain an esoteric operating system, and we won't have many closed source programs if any. A fairly small amount of code gives us access to a large number of programs that we would otherwise not have access to. I'm not proposing removing the code. Just having a knob to turn it on before you're exposed to its attack surface. But it sounds like there are a number of people who want compat_linux to remain enabled, and of the compat modules I expect it is the best- maintained, so I will withdraw the proposal to disable it by default. I disagree. The cost of doing a modload is low enough compared to the configuration needed to use compat_linux. Just like the command you quoted. People who regularly use compat_linux can modify /etc/modules.conf, and will never have to worry about it anymore. They may have to worry about the potential vulnerabilities in it, but what's more important, is that those who do not use compat_linux (still a majority of people) don't.
Re: Proposal: Disable autoload of compat_xyz modules
p...@whooppee.com (Paul Goyette) writes: >If you're using /etc/modules.conf, why not just modunload the modules >you want to remove? (Modules "pushed" from /boot.conf cannot be >unloaded, as far as I understand.) It's the loading part that is prohibited :) -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 06:02:57PM +, Taylor R Campbell wrote: > % cd www/opera && bmake package > ERROR: This package has set PKG_FAIL_REASON: > ERROR: opera-12.16 has an unacceptable license condition: > ERROR: opera-1200-license > ERROR: You can mark the license ``opera-1200-license'' as acceptable by adding > ERROR: ACCEPTABLE_LICENSES+= opera-1200-license > ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/mk.conf or by adding > ERROR: ACCEPTABLE_LICENSES= opera-1200-license > ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/pkg_install.conf. > ERROR: The following command will show you the license text: > ERROR: /home/riastradh/pkgsrc/current/pkg/bin/bmake show-license Fair enough, I set SKIP_LICENSE_CHECK=yes always for vim.
Re: Proposal: Disable autoload of compat_xyz modules
On 02.08.2017 20:02, Taylor R Campbell wrote: >> Date: Wed, 2 Aug 2017 16:11:16 + >> From: m...@netbsd.org >> >> I can 'cd pkgsrc/www/opera; make install; opera' and get a closed source >> browser that works as is, without even realizing it relies on >> COMPAT_LINUX to work. > > % cd www/opera && bmake package > ERROR: This package has set PKG_FAIL_REASON: > ERROR: opera-12.16 has an unacceptable license condition: > ERROR: opera-1200-license > ERROR: You can mark the license ``opera-1200-license'' as acceptable by adding > ERROR: ACCEPTABLE_LICENSES+= opera-1200-license > ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/mk.conf or by adding > ERROR: ACCEPTABLE_LICENSES= opera-1200-license > ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/pkg_install.conf. > ERROR: The following command will show you the license text: > ERROR: /home/riastradh/pkgsrc/current/pkg/bin/bmake show-license > >> Unless some miracle happens, NetBSD will remain an esoteric operating >> system, and we won't have many closed source programs if any. A fairly >> small amount of code gives us access to a large number of programs that >> we would otherwise not have access to. > > I'm not proposing removing the code. Just having a knob to turn it on > before you're exposed to its attack surface. > > But it sounds like there are a number of people who want compat_linux > to remain enabled, and of the compat modules I expect it is the best- > maintained, so I will withdraw the proposal to disable it by default. > However, we still need some way to automatically test it so that > developers other than manu@ can apply security fixes without blindly > breaking things. > I think we can go into a different direction. Instead of disabling the code - we could turn all compat_ into dynamically loadable modules. I would profit from it for functional out-of-the-box compat for older NetBSD releases (a.out executables). For security purposes people can raise securelevel and prevent any modules from insertion into the kernel. signature.asc Description: OpenPGP digital signature
Re: Proposal: Disable autoload of compat_xyz modules
Le 02/08/2017 à 18:11, m...@netbsd.org a écrit : On Wed, Aug 02, 2017 at 01:04:27PM +, Taylor R Campbell wrote: Does anyone use compat_linux without also doing the additional system configuration steps of setting up /emul? Is it an onerous burden to have to modload or add a line in /etc/modules.conf in those steps? Yes, COMPAT_LINUX is one of netbsd/pkgsrc's biggest user friendliness wins. I can 'cd pkgsrc/www/opera; make install; opera' and get a closed source browser that works as is, without even realizing it relies on COMPAT_LINUX to work. Unless some miracle happens, NetBSD will remain an esoteric operating system, and we won't have many closed source programs if any. A fairly small amount of code gives us access to a large number of programs that we would otherwise not have access to. Certainly. But the problem is, this small amount of code opens the door to a large number of potential vulnerabilities too. The last one was fixed only two or three months ago.
Re: Proposal: Disable autoload of compat_xyz modules
> Date: Wed, 2 Aug 2017 16:11:16 + > From: m...@netbsd.org > > I can 'cd pkgsrc/www/opera; make install; opera' and get a closed source > browser that works as is, without even realizing it relies on > COMPAT_LINUX to work. % cd www/opera && bmake package ERROR: This package has set PKG_FAIL_REASON: ERROR: opera-12.16 has an unacceptable license condition: ERROR: opera-1200-license ERROR: You can mark the license ``opera-1200-license'' as acceptable by adding ERROR: ACCEPTABLE_LICENSES+= opera-1200-license ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/mk.conf or by adding ERROR: ACCEPTABLE_LICENSES= opera-1200-license ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/pkg_install.conf. ERROR: The following command will show you the license text: ERROR: /home/riastradh/pkgsrc/current/pkg/bin/bmake show-license > Unless some miracle happens, NetBSD will remain an esoteric operating > system, and we won't have many closed source programs if any. A fairly > small amount of code gives us access to a large number of programs that > we would otherwise not have access to. I'm not proposing removing the code. Just having a knob to turn it on before you're exposed to its attack surface. But it sounds like there are a number of people who want compat_linux to remain enabled, and of the compat modules I expect it is the best- maintained, so I will withdraw the proposal to disable it by default. However, we still need some way to automatically test it so that developers other than manu@ can apply security fixes without blindly breaking things.
Re: Proposal: Disable autoload of compat_xyz modules
> Unless some miracle happens, NetBSD will remain an esoteric operating > system, and we won't have many closed source programs if any. Wearing my iconoclast hat... ...would that be a bad thing? Those who want Linux do know where to find it, after all. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal: Disable autoload of compat_xyz modules
Taylor R Campbell wrote: >(The code will also continue to be compile-tested as non-module via >the ALL kernels.) Maybe we need an ALL kernel for sparc64.
Re: Proposal: Disable autoload of compat_xyz modules
> Date: Wed, 2 Aug 2017 07:56:50 -0700 > From: Brian Buhrow > > Hello. My feeling is that the cost of requiring a modload to use > compat_linux and compat_linux32 is fine. My concern is that by taking it > out of the GENERIC kernel configuration, we lose the regular testing, such > as it is, with the daily builds. Sure, the module gets built, but it could > be a while before it gets loaded and run by the test harness. Today, with > these modules in GENERIC, the modules get loaded as a matter of course. > Is there a way to rig our test harness so that you can take the modules out > of the GENERIC kernel configuration and still do more than compile-time > test them? We do not currently automatically test the compat modules as far as I know. Volunteers are welcome to write automated tests of compat! (The code will also continue to be compile-tested as non-module via the ALL kernels.)
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 01:04:27PM +, Taylor R Campbell wrote: > Does anyone use compat_linux without also doing the additional system > configuration steps of setting up /emul? Is it an onerous burden to > have to modload or add a line in /etc/modules.conf in those steps? Yes, COMPAT_LINUX is one of netbsd/pkgsrc's biggest user friendliness wins. I can 'cd pkgsrc/www/opera; make install; opera' and get a closed source browser that works as is, without even realizing it relies on COMPAT_LINUX to work. Unless some miracle happens, NetBSD will remain an esoteric operating system, and we won't have many closed source programs if any. A fairly small amount of code gives us access to a large number of programs that we would otherwise not have access to.
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 07:56:50AM -0700, Brian Buhrow wrote: > Hello. My feeling is that the cost of requiring a modload to use > compat_linux and compat_linux32 is fine. My concern is that by taking it > out of the GENERIC kernel configuration, we lose the regular testing, such > as it is, with the daily builds. Sure, the module gets built, but it could > be a while before it gets loaded and run by the test harness. Today, with > these modules in GENERIC, the modules get loaded as a matter of course. > Is there a way to rig our test harness so that you can take the modules out > of the GENERIC kernel configuration and still do more than compile-time > test them? The tests exercise quite a few modules, but currently testing compat stuff is tricky (due to the extra setup needed on the test machine to have a create the compat runtime environment). Just doing a few modctl and load some of them is simple, but what does that actually buy us? Martin
Re: Proposal: Disable autoload of compat_xyz modules
Hello. My feeling is that the cost of requiring a modload to use compat_linux and compat_linux32 is fine. My concern is that by taking it out of the GENERIC kernel configuration, we lose the regular testing, such as it is, with the daily builds. Sure, the module gets built, but it could be a while before it gets loaded and run by the test harness. Today, with these modules in GENERIC, the modules get loaded as a matter of course. Is there a way to rig our test harness so that you can take the modules out of the GENERIC kernel configuration and still do more than compile-time test them? -thanks -Brian
Re: Proposal: Disable autoload of compat_xyz modules
> Does anyone use compat_linux without also doing the additional system > configuration steps of setting up /emul? Is it an onerous burden to > have to modload or add a line in /etc/modules.conf in those steps? Not me. Not for me (I build my custom kernels anyway).
Re: Proposal: Disable autoload of compat_xyz modules
> Date: Wed, 02 Aug 2017 18:19:27 +1000 > from: matthew green > > > compat_linux > > compat_linux32 > > all of these are used regularly by many netbsd users. please don't > include them in your list of targets. Does anyone use compat_linux without also doing the additional system configuration steps of setting up /emul? Is it an onerous burden to have to modload or add a line in /etc/modules.conf in those steps? For users like me who don't care about running proprietary binary blobs for Linux, compat_linux carries no benefit -- only the cost of additional attack surface. (This does not extend beyond compat_linux. E.g., random hardware devices for which we have drivers confer the benefit that I might run into the hardware some day. But I'm not going to run Linux binaries without a clear conscious decision.) For the users who do derive value from compat_linux, the cost of requiring modload to enable it seems negligible to me. > saying "modload is OK" is not how we treat the GENERIC kernel -- if > it's OK, then it's OK for GENERIC is how we treat that. That standard suggests we should remove the buggy unmaintained compat modules altogether, which struck me as a more extreme proposal than I care to push for now. (I'm also not sure the set of modules we build adheres to that standard as is, even outside the compat modules.) If you want to propose deletion, that's fine. What is not tenable is leaving everything as is, as we've done in the past, just because nobody has the energy either to maintain the code or to push for deletion.
Re: Proposal: Disable autoload of compat_xyz modules
> Date: Wed, 02 Aug 2017 18:19:27 +1000 > from: matthew green > > > compat_linux > > compat_linux32 > > compat_netbsd32 > > all of these are used regularly by many netbsd users. please don't > include them in your list of targets. saying "modload is OK" is > not how we treat the GENERIC kernel -- if it's OK, then it's OK for > GENERIC is how we treat that. > > the latter is also essential for our mips64 platforms. Evidently my original message was very confusing, for which I apologize -- you're about the fourth person to have read it this way. Let me try to be a little clearer here. I propose to disable the following modules by default, but leave the code so you can still modload them or include them in your custom kernel config if you want: compat_freebsd compat_ibcs2 compat_linux compat_linux32 compat_ndis compat_osf1 compat_sunos compat_sunos32 compat_svr4 compat_svr4_32 compat_ultrix exec_coff exec_ecoff I *DO NOT* propose *ANY* changes to the following modules, and I make no representation about their notoriety or non-notoriety for bugginess, and I'm not asking about users of them, even though they appear at first glance to match or be relevant to the `compat_xyz' pattern mentioned in the subject or the other modules listed here: compat (i.e., old-NetBSD binary compat) compat_aoutm68k compat_netbsd32 exec_aout exec_elf32 exec_elf64 exec_script
Re: Proposal: Disable autoload of compat_xyz modules
>> exec_elf32 >> exec_elf64 >> exec_script > how else do you expect to be able to run elf binaries or any sort of > scripts? ie, these should never be targets for removal. Even elf64 on a 32-bit system, or elf32 on a 64-bit system? (Uhere "system" refers to userland; sparc32 userland under sparc64 kernel needs elf32 but not elf64) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal: Disable autoload of compat_xyz modules
Le 02/08/2017 à 10:19, matthew green a écrit : compat_linux compat_linux32 compat_netbsd32 all of these are used regularly by many netbsd users. please don't include them in your list of targets. saying "modload is OK" is not how we treat the GENERIC kernel -- if it's OK, then it's OK for GENERIC is how we treat that. the latter is also essential for our mips64 platforms. As said earlier, the last one indeed should not be in this list. But the first two should. If it's not how we treat the GENERIC kernel, then let's treat it this way from now on. There is a clear difference between "modload is ok" and "generic is ok"; the former needs root's intervention at some point, the latter is open to unprivileged users. Closing the door to unprivileged processes by default is precisely the goal here. When a vulnerability is found in compat_linux or compat_linux32 - which regularly is the case -, it won't affect the base system anymore.
re: Proposal: Disable autoload of compat_xyz modules
> compat_linux > compat_linux32 > compat_netbsd32 all of these are used regularly by many netbsd users. please don't include them in your list of targets. saying "modload is OK" is not how we treat the GENERIC kernel -- if it's OK, then it's OK for GENERIC is how we treat that. the latter is also essential for our mips64 platforms. also, these "not now" items you listed: > exec_elf32 > exec_elf64 > exec_script how else do you expect to be able to run elf binaries or any sort of scripts? ie, these should never be targets for removal. .mrg.
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, 2 Aug 2017, Michael van Elst wrote: p...@whooppee.com (Paul Goyette) writes: At least for x86 architectures, you can easily edit /boot.cfg to include the required load commands. This causes the boot loader to "push" the modules before init gets started. You can also load modules listed in /etc/modules.conf at boot time. Yes, /etc/modules.conf will also work, however modules listed there are loaded at a much later point in time. But unlike autoloading the machine has to reboot if you want to change the loaded modules. If you're using /etc/modules.conf, why not just modunload the modules you want to remove? (Modules "pushed" from /boot.conf cannot be unloaded, as far as I understand.) +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Proposal: Disable autoload of compat_xyz modules
p...@whooppee.com (Paul Goyette) writes: >At least for x86 architectures, you can easily edit /boot.cfg to include >the required load commands. This causes the boot loader to "push" the >modules before init gets started. You can also load modules listed in /etc/modules.conf at boot time. But unlike autoloading the machine has to reboot if you want to change the loaded modules. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, 2 Aug 2017, Michael van Elst wrote: e...@math.uni-bonn.de (Edgar =?iso-8859-1?B?RnXf?=) writes: Do you, or does anyone you know, rely on any of these modules? While I do use both linux and linux32 (to execute the proprietary TSM client), I could just modload them if I wouldn't build my own kernel anyway. The difference is to have a fix configuration to load it while booting or to load and unload it on demand. At least for x86 architectures, you can easily edit /boot.cfg to include the required load commands. This causes the boot loader to "push" the modules before init gets started. I do this regularly with ffs & wapbl (these modules are NOT included in my custom kernel configs)! # caqt /boot.cfg load=wapbl load=ffs menu=Boot normally:rndseed /var/db/entropy-file;boot netbsd menu=Boot single user:rndseed /var/db/entropy-file;boot netbsd -s menu=Disable ACPI:rndseed /var/db/entropy-file;boot netbsd -2 menu=Disable ACPI and SMP:rndseed /var/db/entropy-file;boot netbsd -12 menu=Drop to boot prompt:prompt menu=Run memory test:boot memtestplus default=1 timeout=5 clear=1 # +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Proposal: Disable autoload of compat_xyz modules
e...@math.uni-bonn.de (Edgar =?iso-8859-1?B?RnXf?=) writes: >> Do you, or does anyone you know, rely on any of these modules? >While I do use both linux and linux32 (to execute the proprietary TSM client), >I could just modload them if I wouldn't build my own kernel anyway. The difference is to have a fix configuration to load it while booting or to load and unload it on demand. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Proposal: Disable autoload of compat_xyz modules
I like that all the arch-specific code is under sys/arch, and not randomly spread around tree, i.e. I prefer to keep the compat things under sys/arch. For sure, same argument could be used the opposite direction, that it would be neater to have all the compat code together. But IMO the arch-specific bits are more tied to the specific platform, so it makes sense to have them together with their native counterparts - like e.g. signal trampoline code. Jaromir 2017-08-01 13:12 GMT+02:00 Maxime Villard : > Yes, that's the right thing to do. > > I haven't rechecked, but as far as I remember, there will be some issues with > the compat layers that have several #ifdefs deep into the machdep code. > > Apart from that, several files could usefully be moved into the appropriate > compat_xyz directory, instead of polluting sys/arch/. For example: > > sys/arch/amd64/amd64/linux_*-> sys/compat/linux/arch/amd64/ > sys/arch/amd64/amd64/linux32_* -> sys/compat/linux32/arch/amd64/ > > This would provide a better encapsulation.
Re: Proposal: Disable autoload of compat_xyz modules
On Tue, Aug 01, 2017 at 12:44:57PM +, m...@netbsd.org wrote: > netbsd/mips64 runs a 64bit kernel and full 32bit userland, so > compat_netbsd32 is tested very heavily on it. We should build 32-bit tests on amd64 :-) (also we should think about how to set up to be able to compile compat tests...) -- David A. Holland dholl...@netbsd.org
Re: Proposal: Disable autoload of compat_xyz modules
On Tue, Aug 01, 2017 at 07:01:29PM +0200, Maxime Villard wrote: > Typically, the situation I want to avoid is this [1], where you had some > random compat code next to critical native procedures. Note also that the > recent callgate vulnerability in amd64 wouldn't have existed, had the > separation between native and compat code been stark. You could just as easily argue that similar functions should be grouped together, so an issue found in one gets fixed in all versions instead of leading to exploits and embarrassing advisories later on. That said, it's not wrong to have a compat/arch. In fact, after trying out various configurations in research kernels over the years my recommendation is to have an arch dir in each subsystem dir that needs one (thus, sys/uvm/arch, sys/dev/arch, etc.) rather than one big one. Of course we don't really have subsystem dirs yet either. but big reorgs need migration to a version control system that supports rename... (deepseagreen4) -- David A. Holland dholl...@netbsd.org
Re: Proposal: Disable autoload of compat_xyz modules
As you said, this argument also works the other way around: it is good to have compat-specific code under sys/compat, and not randomly spread around the tree. In case you didn't notice, compat/linux/arch is already full of arch- specific code that plays with trap frames, which by definition are tied to the specific platform. So it's not like I'm introducing a new concept. Given Taylor's proposal, I believe it is more important to have the compat code together: in a modularised approach, we will certainly want all of the linux code under compat/linux, to improve readability and maintainability. It also has the advantage of forcing the removal of the #ifdefs in the arch-specific code. Typically, the situation I want to avoid is this [1], where you had some random compat code next to critical native procedures. Note also that the recent callgate vulnerability in amd64 wouldn't have existed, had the separation between native and compat code been stark. Maxime [1] http://mail-index.netbsd.org/source-changes/2017/07/29/msg086828.html Le 01/08/2017 à 18:34, Jaromír Doleček a écrit : I like that all the arch-specific code is under sys/arch, and not randomly spread around tree, i.e. I prefer to keep the compat things under sys/arch. For sure, same argument could be used the opposite direction, that it would be neater to have all the compat code together. But IMO the arch-specific bits are more tied to the specific platform, so it makes sense to have them together with their native counterparts - like e.g. signal trampoline code. Jaromir 2017-08-01 13:12 GMT+02:00 Maxime Villard mailto:m...@m00nbsd.net>>: > Yes, that's the right thing to do. > > I haven't rechecked, but as far as I remember, there will be some issues with > the compat layers that have several #ifdefs deep into the machdep code. > > Apart from that, several files could usefully be moved into the appropriate > compat_xyz directory, instead of polluting sys/arch/. For example: > > sys/arch/amd64/amd64/linux_*-> sys/compat/linux/arch/amd64/ > sys/arch/amd64/amd64/linux32_* -> sys/compat/linux32/arch/amd64/ > > This would provide a better encapsulation.
Re: Proposal: Disable autoload of compat_xyz modules
> Date: Tue, 1 Aug 2017 18:34:56 +0200 > From: Jaromír Doleček > > I like that all the arch-specific code is under sys/arch, and not randomly > spread around tree, i.e. I prefer to keep the compat things under sys/arch. > > For sure, same argument could be used the opposite direction, that it would > be neater to have all the compat code together. > > But IMO the arch-specific bits are more tied to the specific platform, so > it makes sense to have them together with their native counterparts - like > e.g. signal trampoline code. Obviously we need a relational database of source files to maintain physical access-path independence of the semantic relations here.
Re: Proposal: Disable autoload of compat_xyz modules
m...@netbsd.org wrote: On Mon, Jul 31, 2017 at 09:39:42PM +, Taylor R Campbell wrote: >> P.S. The old-NetBSD, a.out, and 32-bit compat modules may be broken >> too, and are probably not automatically tested either, but are more >> likely to be manually tested and I'm not addressing them right now. >> These are: > >netbsd/mips64 runs a 64bit kernel and full 32bit userland, so >>compat_netbsd32 is tested very heavily on it. Running NetBSD/sparc on 64bit hardware works like this too.
Re: ndis [was Re: Proposal: Disable autoload of compat_xyz modules]
On Mon, Jul 31, 2017 at 06:00:18PM -0500, Jonathan A. Kollasch wrote: > I might care about it if it worked. I couldn't even make it work for > wired NICs some years ago. I have a feeling it's incomplete and/or > broken. I don't think it does any syscall compat stuff though. The code and some other things claim it is compatible with NDIS 5.1, I am under the impression that means only Windows XP or older drivers will work. I think manufacturers have stopped making such drivers, but they can still be found for hardware.
Re: Proposal: Disable autoload of compat_xyz modules
Taylor R Campbell wrote: >> Date: Tue, 1 Aug 2017 00:45:24 +0200 >> From: Kamil Rytarowski >> >> I use both linux and linux32 ones. > >Can you argue that these and the others you listed should be >automatically enabled by default, and that having to modload them >would be too much of a burden? > >Can you say who maintains them, or volunteer to maintain them, >including writing automatic tests with sample binaries that others can >use to test security fixes? > >I want to learn more than just who uses these -- I want to estimate >the negative impact of disabling them by default, and what effort we >have available to make sure they continue to work reliably. I use linux, linux32 and netbsd32 to run fairly big applications that I think test out a good spread of features. The Xilinx FPGA tools make use of compat_linux and compat_linux32. I have an uncommitted patch to procfs to make the latest version work. I regularly run CMUCL on amd64 using compat_netbsd32.
Re: Proposal: Disable autoload of compat_xyz modules
On Mon, Jul 31, 2017 at 09:39:42PM +, Taylor R Campbell wrote: > Can you tell me who maintains them, or if nobody does, can you > volunteer to maintain them -- by auditing them, by testing them if > someone else applies a security fix, by writing automatic tests with > sample binaries that we can put into atf? I can promise to try to solve any COMPAT_LINUX bug, although I don't promise to succeed. I find it useful, we even have packages relying on its existence, and its nice that they work out of the box, but adding a note to all of them isn't bad. Most of these packages are in pkgsrc/games, but there are some other notable software that has been reported to run under COMPAT_LINUX (recently manu@ added pselect6 stating it allows MATLAB R2016A to run). > P.S. The old-NetBSD, a.out, and 32-bit compat modules may be broken > too, and are probably not automatically tested either, but are more > likely to be manually tested and I'm not addressing them right now. > These are: netbsd/mips64 runs a 64bit kernel and full 32bit userland, so compat_netbsd32 is tested very heavily on it.
Re: Proposal: Disable autoload of compat_xyz modules
Le 31/07/2017 à 23:39, Taylor R Campbell a écrit : Many of our binary compatibility modules are notoriously ridden with bugs. We currently have no way to automatically test them. Some of them are maintained; some of them are not. The value of having NetBSD automatically try to execute a SCO Unix binary, for example, seems rather weak compared to the security risk of the attack surface. So I propose to exclude all non-NetBSD, non-ELF/a.out compat modules from autoloading by exec, and remove them from all GENERIC kernels. Under this proposal, if you want them in your system, you can add them to your kernel config or modload them explicitly. Yes, that's the right thing to do. I haven't rechecked, but as far as I remember, there will be some issues with the compat layers that have several #ifdefs deep into the machdep code. Apart from that, several files could usefully be moved into the appropriate compat_xyz directory, instead of polluting sys/arch/. For example: sys/arch/amd64/amd64/linux_*-> sys/compat/linux/arch/amd64/ sys/arch/amd64/amd64/linux32_* -> sys/compat/linux32/arch/amd64/ This would provide a better encapsulation.
Re: ndis [was Re: Proposal: Disable autoload of compat_xyz modules]
On Mon, Jul 31, 2017 at 06:00:18PM -0500, Jonathan A. Kollasch wrote: > On Mon, Jul 31, 2017 at 10:56:41PM +, Taylor R Campbell wrote: > > > Date: Tue, 1 Aug 2017 00:45:24 +0200 > > > From: Kamil Rytarowski > > > > > > > compat_ndis > > > > > > This one perhaps could stay. It's for network driver. > > > > On review, it appears this is not actually included in any GENERIC > > kernels at all -- or even the x86 ALL kernels. It doesn't even seem > > to build. It is marked as `experimental'. Does anyone care about it? > > > > I might care about it if it worked. I couldn't even make it work for > wired NICs some years ago. I have a feeling it's incomplete and/or > broken. I don't think it does any syscall compat stuff though. Correct. It is an emulation layer of the NDIS kernel API. No user servicable parts here. Joerg
Re: Proposal: Disable autoload of compat_xyz modules
> Do you, or does anyone you know, rely on any of these modules? While I do use both linux and linux32 (to execute the proprietary TSM client), I could just modload them if I wouldn't build my own kernel anyway.
Re: Proposal: Disable autoload of compat_xyz modules
On 01.08.2017 00:48, Taylor R Campbell wrote: >> Date: Tue, 1 Aug 2017 00:45:24 +0200 >> From: Kamil Rytarowski >> >> I use both linux and linux32 ones. > > Can you argue that these and the others you listed should be > automatically enabled by default, and that having to modload them > would be too much of a burden? > > Can you say who maintains them, or volunteer to maintain them, > including writing automatic tests with sample binaries that others can > use to test security fixes? > > I want to learn more than just who uses these -- I want to estimate > the negative impact of disabling them by default, and what effort we > have available to make sure they continue to work reliably. > I think that multimedia/adobe-flash-player is the primary user. Everything else that I'm aware of is more superuser or developer oriented. I'm fine personally to modload(8) it manually. signature.asc Description: OpenPGP digital signature
Re: ndis [was Re: Proposal: Disable autoload of compat_xyz modules]
On Mon, Jul 31, 2017 at 10:56:41PM +, Taylor R Campbell wrote: > > Date: Tue, 1 Aug 2017 00:45:24 +0200 > > From: Kamil Rytarowski > > > > > compat_ndis > > > > This one perhaps could stay. It's for network driver. > > On review, it appears this is not actually included in any GENERIC > kernels at all -- or even the x86 ALL kernels. It doesn't even seem > to build. It is marked as `experimental'. Does anyone care about it? > I might care about it if it worked. I couldn't even make it work for wired NICs some years ago. I have a feeling it's incomplete and/or broken. I don't think it does any syscall compat stuff though. Jonathan Kollasch
ndis [was Re: Proposal: Disable autoload of compat_xyz modules]
> Date: Tue, 1 Aug 2017 00:45:24 +0200 > From: Kamil Rytarowski > > > compat_ndis > > This one perhaps could stay. It's for network driver. On review, it appears this is not actually included in any GENERIC kernels at all -- or even the x86 ALL kernels. It doesn't even seem to build. It is marked as `experimental'. Does anyone care about it? (This is different from and independent of urndis(4), which does build and does work, and which I even use sometimes.)
Re: Proposal: Disable autoload of compat_xyz modules
> Date: Tue, 1 Aug 2017 00:45:24 +0200 > From: Kamil Rytarowski > > I use both linux and linux32 ones. Can you argue that these and the others you listed should be automatically enabled by default, and that having to modload them would be too much of a burden? Can you say who maintains them, or volunteer to maintain them, including writing automatic tests with sample binaries that others can use to test security fixes? I want to learn more than just who uses these -- I want to estimate the negative impact of disabling them by default, and what effort we have available to make sure they continue to work reliably. > > P.S. The old-NetBSD, a.out, and 32-bit compat modules may be broken > > too, and are probably not automatically tested either, but are more > > likely to be manually tested and I'm not addressing them right now. > > These are: > > > > compat (i.e., old-NetBSD binary compat) > > I use NetBSD-0.9 executables and they work for me. Just to be clear: I'm not proposing to change anything about these.
Re: Proposal: Disable autoload of compat_xyz modules
On 31.07.2017 23:39, Taylor R Campbell wrote: > Many of our binary compatibility modules are notoriously ridden with > bugs. We currently have no way to automatically test them. Some of > them are maintained; some of them are not. The value of having NetBSD > automatically try to execute a SCO Unix binary, for example, seems > rather weak compared to the security risk of the attack surface. > > So I propose to exclude all non-NetBSD, non-ELF/a.out compat modules > from autoloading by exec, and remove them from all GENERIC kernels. > Under this proposal, if you want them in your system, you can add them > to your kernel config or modload them explicitly. > > This is a compromise between preserving the functionality and reducing > attack surface for what I hypothesize are a majority of users who do > not use it. Under this proposal, the code will remain, and still be > built, and still be usable -- it will just not be enabled by default. > In particular, I'm not questioning the value of having (e.g.) Linux > binary compatibility support; it'll just be one modload away. > > The modules and kernel options that are currently autoloaded by exec > and/or included in some GENERIC kernels that I propose to disable by > default are: > > compat_freebsd > compat_ibcs2 > compat_linux > compat_linux32 I use both linux and linux32 ones. > compat_ndis This one perhaps could stay. It's for network driver. > compat_osf1 > compat_sunos > compat_sunos32 > compat_svr4 > compat_svr4_32 > compat_ultrix > exec_coff > exec_ecoff > > Do you, or does anyone you know, rely on any of these modules? Can > you argue that they *should* be autoloaded by default for the typical > user, and not enabled explicitly by operators who know they need them? > > Can you tell me who maintains them, or if nobody does, can you > volunteer to maintain them -- by auditing them, by testing them if > someone else applies a security fix, by writing automatic tests with > sample binaries that we can put into atf? > > I'm not asking to delete the code -- only whether it should be enabled > by default. If I hear nothing in one week, then I will disable these > by default, and a week later, I will request pullups to netbsd-7 and > netbsd-8. > > > P.S. The old-NetBSD, a.out, and 32-bit compat modules may be broken > too, and are probably not automatically tested either, but are more > likely to be manually tested and I'm not addressing them right now. > These are: > > compat (i.e., old-NetBSD binary compat) I use NetBSD-0.9 executables and they work for me. > compat_aoutm68k > compat_netbsd32 Works for me. > exec_aout Works for me. > exec_elf32 > exec_elf64 > exec_script > signature.asc Description: OpenPGP digital signature
Proposal: Disable autoload of compat_xyz modules
Many of our binary compatibility modules are notoriously ridden with bugs. We currently have no way to automatically test them. Some of them are maintained; some of them are not. The value of having NetBSD automatically try to execute a SCO Unix binary, for example, seems rather weak compared to the security risk of the attack surface. So I propose to exclude all non-NetBSD, non-ELF/a.out compat modules from autoloading by exec, and remove them from all GENERIC kernels. Under this proposal, if you want them in your system, you can add them to your kernel config or modload them explicitly. This is a compromise between preserving the functionality and reducing attack surface for what I hypothesize are a majority of users who do not use it. Under this proposal, the code will remain, and still be built, and still be usable -- it will just not be enabled by default. In particular, I'm not questioning the value of having (e.g.) Linux binary compatibility support; it'll just be one modload away. The modules and kernel options that are currently autoloaded by exec and/or included in some GENERIC kernels that I propose to disable by default are: compat_freebsd compat_ibcs2 compat_linux compat_linux32 compat_ndis compat_osf1 compat_sunos compat_sunos32 compat_svr4 compat_svr4_32 compat_ultrix exec_coff exec_ecoff Do you, or does anyone you know, rely on any of these modules? Can you argue that they *should* be autoloaded by default for the typical user, and not enabled explicitly by operators who know they need them? Can you tell me who maintains them, or if nobody does, can you volunteer to maintain them -- by auditing them, by testing them if someone else applies a security fix, by writing automatic tests with sample binaries that we can put into atf? I'm not asking to delete the code -- only whether it should be enabled by default. If I hear nothing in one week, then I will disable these by default, and a week later, I will request pullups to netbsd-7 and netbsd-8. P.S. The old-NetBSD, a.out, and 32-bit compat modules may be broken too, and are probably not automatically tested either, but are more likely to be manually tested and I'm not addressing them right now. These are: compat (i.e., old-NetBSD binary compat) compat_aoutm68k compat_netbsd32 exec_aout exec_elf32 exec_elf64 exec_script