Re: Proposal: Disable autoload of compat_xyz modules

[Paul Goyette]

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

[Maxime Villard]

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

[Maxime Villard]

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

[Martin Husemann]

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

[Maxime Villard]

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

[Maxime Villard]

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

[Christos Zoulas]

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

[Manuel Bouyer]

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

[Mouse]

> 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

[Manuel Bouyer]

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

[Maxime Villard]

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

[Manuel Bouyer]

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

[Maxime Villard]

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

[Manuel Bouyer]

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

[Maxime Villard]

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

[Marc Balmer]

> 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

[Greg Troxel]

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

[Maxime Villard]

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

[Manuel Bouyer]

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

[Manuel Bouyer]

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

[Maxime Villard]

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

[Manuel Bouyer]

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

[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.

Maxime

Re: Proposal: Disable autoload of compat_xyz modules

[Paul Goyette]

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

[Manuel Bouyer]

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

[Maxime Villard]

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

[maya]

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

[Thor Lancelot Simon]

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

[John Nemeth]

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

[John Nemeth]

On Aug 3,  4:09pm, Emmanuel Dreyfus wrote:
} Subject: Re: Proposal: Disable autoload of compat_xyz modules
} <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.
} 
} 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

[John Nemeth]

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

[Emmanuel Dreyfus]

 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

[Joerg Sonnenberger]

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

[David Brownlee]

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

[maya]

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

[Maxime Villard]

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

[Maxime Villard]

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

[matthew green]

> > 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

[Maxime Villard]

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

[David Holland]

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

[John Nemeth]

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

[Emmanuel Dreyfus]

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

[Paul Goyette]

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

[Joerg Sonnenberger]

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

[Joerg Sonnenberger]

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

[Maxime Villard]

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

[Michael van Elst]

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

[coypu]

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

[Kamil Rytarowski]

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

[Maxime Villard]

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

[Taylor R Campbell]

> 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

[Mouse]

> 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

[Robert Swindells]

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

[Taylor R Campbell]

> 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

[maya]

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

[Martin Husemann]

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

[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?

-thanks
-Brian

Re: Proposal: Disable autoload of compat_xyz modules

[Edgar Fuß]

> 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

[Taylor R Campbell]

> 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

[Taylor R Campbell]

> 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

[Mouse]

>> 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

[Maxime Villard]

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

[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.

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

[Paul Goyette]

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

[Michael van Elst]

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

[Paul Goyette]

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

[Michael van Elst]

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

[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.

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

[David Holland]

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

[David Holland]

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

[Maxime Villard]

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 >:
 > 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

[Taylor R Campbell]

> 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

[Robert Swindells]

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]

[maya]

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

[Robert Swindells]

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

[maya]

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: ndis [was Re: Proposal: Disable autoload of compat_xyz modules]

[Joerg Sonnenberger]

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

[Edgar Fuß]

> 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

[Kamil Rytarowski]

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]

[Jonathan A. Kollasch]

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]

[Taylor R Campbell]

> 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

[Taylor R Campbell]

> 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

[Kamil Rytarowski]

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

[Taylor R Campbell]

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