Re: Proposal, again: Disable autoload of compat_xyz modules
In article <201909301931.x8ujvvve028...@server.cornerstoneservice.ca>, John Nemeth wrote: >On Sep 30, 1:06pm, Michael van Elst wrote: >} On Mon, Sep 30, 2019 at 12:37:38AM -0700, John Nemeth wrote: >} >} > BTW, modules.conf isn't read by the kernel, it's read by >} > /etc/rc.d/modules. Putting anything in there that would have a >} > lasting effect (i.e. parameters for autoloaded modules) would >} > require quite a bit of work. >} >} You could just store the parameters in the kernel so that a future >} autoload will use these instead of or merged with the plist. > > You could do this using the backend code for the proposed >sysctl. The question then is how do you know when the .plist is >changed? Would you attach some kind of a kevent to it? If so, then >you need to track the source of the entry in the "blacklist". If >it came from the .plist, then upon receiving notification that it >has changed, then you want to delete the entry. However, if it >came from userland via sysctl or is part of the default list, then >you don't want to delete the entry just because the .plist changed. >This is starting to get complicated with corner cases. I am not sure what gets priority here. The command line arguments in modules.conf or the plist entries (when both exist)? Also while it is attractive to store the plist next to the module we currently install 0 plists. What is the expectation here? That one will use modload to generate plists or that we are going to put the arguments in modules.conf? I think that the plists were meant to be static (as the arguments in modules.conf) and they would take effect only during load time. The variables in the plists are also supposed to be module-specific not global. christos
Re: Proposal, again: Disable autoload of compat_xyz modules
On Sep 30, 1:06pm, Michael van Elst wrote: } On Mon, Sep 30, 2019 at 12:37:38AM -0700, John Nemeth wrote: } } > BTW, modules.conf isn't read by the kernel, it's read by } > /etc/rc.d/modules. Putting anything in there that would have a } > lasting effect (i.e. parameters for autoloaded modules) would } > require quite a bit of work. } } You could just store the parameters in the kernel so that a future } autoload will use these instead of or merged with the plist. You could do this using the backend code for the proposed sysctl. The question then is how do you know when the .plist is changed? Would you attach some kind of a kevent to it? If so, then you need to track the source of the entry in the "blacklist". If it came from the .plist, then upon receiving notification that it has changed, then you want to delete the entry. However, if it came from userland via sysctl or is part of the default list, then you don't want to delete the entry just because the .plist changed. This is starting to get complicated with corner cases. }-- End of excerpt from Michael van Elst
Re: Proposal, again: Disable autoload of compat_xyz modules
On Mon, Sep 30, 2019 at 12:37:38AM -0700, John Nemeth wrote: > Uh, that's not true. If you store .plist in the same > directory with the module, it will be loaded and passed to the > module to provide parameters. Good to know. > BTW, modules.conf isn't read by the kernel, it's read by > /etc/rc.d/modules. Putting anything in there that would have a > lasting effect (i.e. parameters for autoloaded modules) would > require quite a bit of work. You could just store the parameters in the kernel so that a future autoload will use these instead of or merged with the plist. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Proposal, again: Disable autoload of compat_xyz modules
On Sep 30, 7:10am, Michael van Elst wrote: } chris...@astron.com (Christos Zoulas) writes: } >In article <20190929090053.g...@homeworld.netbsd.org>, } > wrote: } >>On Sat, Sep 28, 2019 at 01:29:39AM -, Christos Zoulas wrote: } >>> + "compat_linux", } >>> + "compat_linux32", } >> } >>As for the actual change, I'd like to see it integrated through } >>modules.conf, not via settings of default sysctl values. I think it's } >>bad user experience. } } >modules.conf contains module names and their arguments. It is a configuration } >file for each module. There are already sysctls in the kern.module. tree all } >related to autoloading. } } Everything currently in modules.conf is loaded permanently. One argument } for adding autoload support would be that it allows to configure module } parameters in a common place, as autoloaded modules cannot get parameters } yet. It could also be used to configure policies (e.g. blacklists). Uh, that's not true. If you store .plist in the same directory with the module, it will be loaded and passed to the module to provide parameters. You can use "modload -p" to create the file (see module(7)). Also, if you put a special flag in the .plist the module won't be autoloaded, see this from module(9): The directory from which the module is loaded will be searched for a file with the same name as the module file, but with the suffix ``.plist''. If this file is found, the prop_dictionary it contains will be loaded and passed to the module's modcmd() routine. If this prop_dictionary contains a ``noautoload'' property which is set to ``true'' then the system will refuse to load the module. BTW, modules.conf isn't read by the kernel, it's read by /etc/rc.d/modules. Putting anything in there that would have a lasting effect (i.e. parameters for autoloaded modules) would require quite a bit of work. Although it could be made to specify modules not to autoload by having it use christos' kern.module.noautoload sysctl. }-- End of excerpt from Michael van Elst
Re: Proposal, again: Disable autoload of compat_xyz modules
chris...@astron.com (Christos Zoulas) writes: >In article <20190929090053.g...@homeworld.netbsd.org>, > wrote: >>On Sat, Sep 28, 2019 at 01:29:39AM -, Christos Zoulas wrote: >>> + "compat_linux", >>> + "compat_linux32", >> >>As for the actual change, I'd like to see it integrated through >>modules.conf, not via settings of default sysctl values. I think it's >>bad user experience. >modules.conf contains module names and their arguments. It is a configuration >file for each module. There are already sysctls in the kern.module. tree all >related to autoloading. Everything currently in modules.conf is loaded permanently. One argument for adding autoload support would be that it allows to configure module parameters in a common place, as autoloaded modules cannot get parameters yet. It could also be used to configure policies (e.g. blacklists). But that's a far way. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Proposal, again: Disable autoload of compat_xyz modules
from Kamil Rytarowski: > My primary motivation is running LTP kernel regression tests for > compat_linux and integrate them into ATF (src/tests). > With musl it is posible to get cross-toolchain for the same CPU > configuration as host without building customized gcc/clang. > >>> Did you cross-compile from NetBSD to get the cross-toolchain, or did = > you need some Linux stuff already compiled? > >> I compiled everything natively on NetBSD, from NetBSD. No Linux stuff > >> precompiled. > > Did you not need Linux compat at this stage? > No. It was needed only to test hello-world example. > Such musl-gcc approach to build non-trivial applications will most > likely fail as we will still be detected as NetBSD and this will affect > the end result. I guess I need to go to musl-libc.org website and their git site. I remember seeing something about cross-compiling, also saw some bad links. > For building applications with dependencies we will need to do it at > least in chroot. Applications would be built and installed into a separate sysroot. Question is whether such a sysroot could run mounted on /emul/linux, as well as in its own partition or USB stick. > However.. getting this setup to build larger packages with plain > musl-gcc is viable. It's a matter of cost vs benefit here. I am still not sure whether I do better with musl as opposed to glibc. > > How does the compiler at NetBSD end know what OS to compile for? Is it= > a matter of the appropriate tuple or triplet? > ELF is similar on NetBSD and Linux, the are few differences that are > handled with musl-gcc GCC script. > However it would involve some work to build non-trivial applications. > >>> But I believe you would need Linux kernel headers in any case. > >> This might be the case that the Linux kernel headers needed that are > >> GPLv2. If so, it will be easier and quicker to get > >> MUSL+LTP+GMAKE+LINUX_HEADERS|(+BASH+) as a package in pkgsrc. > > I found musl, uclibc and glibc in pkgsrc/wip . One is not likely to ge= > t far building packages with pkgsrc, or FreeBSD with ports, without gmake= > and bash. > > Linux headers would not have to be built, but it would be necessary to = > configure and build the Linux kernel. > Building the Linux kernel with musl-gcc can be more tricky as there are > certainly hacks assuming uname=3DLinux. > However... it should be doable. > > Perhaps, musl could be downloaded from their website and compiled. > I was wondering whether there would be a use-case for integration of > MUSL into src/? > >> Implementing everything as a part of src/ is possible, but needs more > >> work and more GPL code around. > >>> Where do you get musl-gcc, or is it built as part of the light cross-= > toolchain? > It is part of the musl git repo. > https://git.musl-libc.org/cgit/musl/ > There is need to build musl-gcc.specs.sh and musl-gcc > https://git.musl-libc.org/cgit/musl/tree/Makefile > I had to run "gmake musl-gcc" "gmake musl-gcc.specs" or similar. I would > need to reproduce it or package to recall the exact commands. > I had to install musl into /usr/local + the ELF leader link into > /lib/ld-musl*. Tom
Re: Proposal, again: Disable autoload of compat_xyz modules
In article <20190929090053.g...@homeworld.netbsd.org>, wrote: >On Sat, Sep 28, 2019 at 01:29:39AM -, Christos Zoulas wrote: >> Here's what I've implemented: >> >> kern.module.noautoload="compat_linux* compat_[0-4]?" >> >> This disables autoload for all compat_linux modules as well >> as compat_netbsd < NetBSD-5.0 >> >> Comments? >> >> christos >> >... >> +"compat_linux", >> +"compat_linux32", > >Kinda shocking that nowhere in this thread do we bring up the fact that >compat_linux is not currently being auto-loaded (since a 2017 change by >maxv). > >As for the actual change, I'd like to see it integrated through >modules.conf, not via settings of default sysctl values. I think it's >bad user experience. modules.conf contains module names and their arguments. It is a configuration file for each module. There are already sysctls in the kern.module. tree all related to autoloading. christos
Re: Proposal, again: Disable autoload of compat_xyz modules
On Sat, Sep 28, 2019 at 01:29:39AM -, Christos Zoulas wrote: > Here's what I've implemented: > > kern.module.noautoload="compat_linux* compat_[0-4]?" > > This disables autoload for all compat_linux modules as well > as compat_netbsd < NetBSD-5.0 > > Comments? > > christos > ... > + "compat_linux", > + "compat_linux32", Kinda shocking that nowhere in this thread do we bring up the fact that compat_linux is not currently being auto-loaded (since a 2017 change by maxv). As for the actual change, I'd like to see it integrated through modules.conf, not via settings of default sysctl values. I think it's bad user experience.
Re: Proposal, again: Disable autoload of compat_xyz modules
On 28.09.2019 09:55, Thomas Mueller wrote: > from Kamil Rytarowski and my previous post: > I have managed to get light cross-toolchain producing Linux binaries. > The only dependency is musl (+gmake to build it). > >>> Is it necessary to use musl, as opposed to uClibc-ng or glibc? > > >> MUSL has good license (BSD) and is designed to work well standalone. > >> It would be also possible to add MUSL to src/ directly, but it will >> involve patching tools/. > >> However if we want to use LTP, it is already GPLv2 and some work to >> integrate into ATF, probably it would involve rewritting the tests. > > What is ATF here? But my main interest is building a cross-toolchain on > NetBSD to produce Linux binaries. > > I can't see what I would use LTP for; I looked at their Github site. > My primary motivation is running LTP kernel regression tests for compat_linux and integrate them into ATF (src/tests). With musl it is posible to get cross-toolchain for the same CPU configuration as host without building customized gcc/clang. >>> Did you cross-compile from NetBSD to get the cross-toolchain, or did you >>> need some Linux stuff already compiled? > > >> I compiled everything natively on NetBSD, from NetBSD. No Linux stuff >> precompiled. > > Did you not need Linux compat at this stage? > No. It was needed only to test hello-world example. Such musl-gcc approach to build non-trivial applications will most likely fail as we will still be detected as NetBSD and this will affect the end result. For building applications with dependencies we will need to do it at least in chroot. However.. getting this setup to build larger packages with plain musl-gcc is viable. It's a matter of cost vs benefit here. > How does the compiler at NetBSD end know what OS to compile for? Is it a > matter of the appropriate tuple or triplet? > ELF is similar on NetBSD and Linux, the are few differences that are handled with musl-gcc GCC script. However it would involve some work to build non-trivial applications. >>> But I believe you would need Linux kernel headers in any case. > > >> This might be the case that the Linux kernel headers needed that are >> GPLv2. If so, it will be easier and quicker to get >> MUSL+LTP+GMAKE+LINUX_HEADERS|(+BASH+) as a package in pkgsrc. > > I found musl, uclibc and glibc in pkgsrc/wip . One is not likely to get far > building packages with pkgsrc, or FreeBSD with ports, without gmake and bash. > > Linux headers would not have to be built, but it would be necessary to > configure and build the Linux kernel. > Building the Linux kernel with musl-gcc can be more tricky as there are certainly hacks assuming uname=Linux. However... it should be doable. > Perhaps, musl could be downloaded from their website and compiled. > I was wondering whether there would be a use-case for integration of MUSL into src/? >> Implementing everything as a part of src/ is possible, but needs more >> work and more GPL code around. > >>> Where do you get musl-gcc, or is it built as part of the light >>> cross-toolchain? > It is part of the musl git repo. https://git.musl-libc.org/cgit/musl/ There is need to build musl-gcc.specs.sh and musl-gcc https://git.musl-libc.org/cgit/musl/tree/Makefile I had to run "gmake musl-gcc" "gmake musl-gcc.specs" or similar. I would need to reproduce it or package to recall the exact commands. I had to install musl into /usr/local + the ELF leader link into /lib/ld-musl*. > >> It is shipped together with mainline MUSL, but there is probably need to >> build it manually (I had to do it this way: specify few more 'gmake >> $target' calls). > It works almost out of the box (I had to manually build certain files). > The only think that is required to be tuned is to add a dummy gnu_debuglink. > > > Tom > signature.asc Description: OpenPGP digital signature
Re: Proposal, again: Disable autoload of compat_xyz modules
from Kamil Rytarowski and my previous post: > >> I have managed to get light cross-toolchain producing Linux binaries. > >> The only dependency is musl (+gmake to build it). > > Is it necessary to use musl, as opposed to uClibc-ng or glibc? > MUSL has good license (BSD) and is designed to work well standalone. > It would be also possible to add MUSL to src/ directly, but it will > involve patching tools/. > However if we want to use LTP, it is already GPLv2 and some work to > integrate into ATF, probably it would involve rewritting the tests. What is ATF here? But my main interest is building a cross-toolchain on NetBSD to produce Linux binaries. I can't see what I would use LTP for; I looked at their Github site. > > Did you cross-compile from NetBSD to get the cross-toolchain, or did you > > need some Linux stuff already compiled? > I compiled everything natively on NetBSD, from NetBSD. No Linux stuff > precompiled. Did you not need Linux compat at this stage? How does the compiler at NetBSD end know what OS to compile for? Is it a matter of the appropriate tuple or triplet? > > But I believe you would need Linux kernel headers in any case. > This might be the case that the Linux kernel headers needed that are > GPLv2. If so, it will be easier and quicker to get > MUSL+LTP+GMAKE+LINUX_HEADERS|(+BASH+) as a package in pkgsrc. I found musl, uclibc and glibc in pkgsrc/wip . One is not likely to get far building packages with pkgsrc, or FreeBSD with ports, without gmake and bash. Linux headers would not have to be built, but it would be necessary to configure and build the Linux kernel. Perhaps, musl could be downloaded from their website and compiled. > Implementing everything as a part of src/ is possible, but needs more > work and more GPL code around. > > Where do you get musl-gcc, or is it built as part of the light > > cross-toolchain? > It is shipped together with mainline MUSL, but there is probably need to > build it manually (I had to do it this way: specify few more 'gmake > $target' calls). > >> It works almost out of the box (I had to manually build certain files). > >> The only think that is required to be tuned is to add a dummy > >> gnu_debuglink. Tom
Re: Proposal, again: Disable autoload of compat_xyz modules
In article <20190927125444.gb12...@pony.stderr.spb.ru>,
Valery Ushakov wrote:
>
>May be we should take a look at how SNMP did tables in MIB, b/c we are
>trying to create just such a table indexed by module name.
I think it is simpler than that.
>
>Also, I'm not that sure about autoload of compat stuff especially
>since iirc it currently implies auto-unload too. I vaguely remember
>when I was debugging something in sh3 kobj_machdep.c I had some
>printfs there that made the autoloads visibile and (iirc) each vi
>invocation would trigger an autoload of compat ioctl code (which
>wouldn't recognize the ioctl, and that would be auto-unloaded a few
>seconds later).
>
>-uwe
Here's what I've implemented:
kern.module.noautoload="compat_linux* compat_[0-4]?"
This disables autoload for all compat_linux modules as well
as compat_netbsd < NetBSD-5.0
Comments?
christos
Index: kern_exec.c
===
RCS file: /cvsroot/src/sys/kern/kern_exec.c,v
retrieving revision 1.481
diff -u -u -r1.481 kern_exec.c
--- kern_exec.c 17 Sep 2019 15:19:27 - 1.481
+++ kern_exec.c 28 Sep 2019 01:27:00 -
@@ -626,6 +626,8 @@
"exec_ecoff",
"compat_aoutm68k",
"compat_netbsd32",
+ "compat_linux",
+ "compat_linux32",
"compat_sunos",
"compat_sunos32",
"compat_ultrix",
Index: kern_module.c
===
RCS file: /cvsroot/src/sys/kern/kern_module.c,v
retrieving revision 1.138
diff -u -u -r1.138 kern_module.c
--- kern_module.c 8 Aug 2019 18:08:41 - 1.138
+++ kern_module.c 28 Sep 2019 01:27:00 -
@@ -53,10 +53,16 @@
#include
#include
#include
+#include
#include
#include
+#ifndef MODULE_NOAUTOLOAD
+// Disable compat_linux and compat_linux32 by default for now
+#define MODULE_NOAUTOLOAD "compat_linux*"
+#endif
+
struct vm_map *module_map;
const char *module_machine;
char module_base[MODULE_BASE_SIZE];
@@ -93,6 +99,7 @@
u_int module_gen = 1;
static kcondvar_t module_thread_cv;
static kmutex_t module_thread_lock;
+static kmutex_t module_noautoload_lock;
static int module_thread_ticks;
int (*module_load_vfs_vec)(const char *, int, bool, module_t *,
prop_dictionary_t *) = (void *)eopnotsupp;
@@ -120,6 +127,8 @@
static voidmodule_enqueue(module_t *);
static boolmodule_merge_dicts(prop_dictionary_t, const prop_dictionary_t);
+static boolmodule_allow_autoload(const char *);
+static voidmodule_noautoload_update(const char *);
static voidsysctl_module_setup(void);
static int sysctl_module_autotime(SYSCTLFN_PROTO);
@@ -412,6 +421,7 @@
}
cv_init(_thread_cv, "mod_unld");
mutex_init(_thread_lock, MUTEX_DEFAULT, IPL_NONE);
+ mutex_init(_noautoload_lock, MUTEX_DEFAULT, IPL_NONE);
TAILQ_INIT();
#ifdef MODULAR /* XXX */
@@ -444,6 +454,8 @@
module_netbsd = module_newmodule(MODULE_SOURCE_KERNEL);
module_netbsd->mod_refcnt = 1;
module_netbsd->mod_info = _netbsd_modinfo;
+
+ module_noautoload_update(MODULE_NOAUTOLOAD);
}
/*
@@ -503,6 +515,100 @@
return (0);
}
+struct noautoload {
+ const char *name;
+ SLIST_ENTRY(noautoload) next;
+};
+
+static SLIST_HEAD(, noautoload) noautoload_list =
+SLIST_HEAD_INITIALIZER(noautoload_list);
+
+static char noautoload_buf[1024];
+static char noautoload_nbuf[sizeof(noautoload_buf)];
+
+static void
+module_noautoload_update(const char *cbuf)
+{
+ static const char SEP[] = " \t\n,";
+ struct noautoload *e, *te;
+ char buf[sizeof(noautoload_buf)];
+
+ strlcpy(buf, cbuf, sizeof(buf));
+
+ mutex_enter(_noautoload_lock);
+
+ SLIST_FOREACH_SAFE(e, _list, next, te) {
+ SLIST_REMOVE(_list, e, noautoload, next);
+ kmem_free(e, sizeof(*e));
+ }
+
+ noautoload_nbuf[0] = noautoload_buf[0] = '\0';
+
+ size_t pos = 0;
+ char *p, *str = buf;
+
+ while ((p = strsep(, SEP)) != NULL) {
+ size_t len = strlen(p);
+ if (len == 0)
+ break;
+ e = kmem_alloc(sizeof(*e), KM_SLEEP);
+ e->name = noautoload_nbuf + pos;
+ SLIST_INSERT_HEAD(_list, e, next);
+
+ memcpy(noautoload_buf + pos, p, len);
+ memcpy(noautoload_nbuf + pos, p, len);
+ pos += len;
+ noautoload_buf[pos] = ' ';
+ noautoload_nbuf[pos] = '\0';
+ pos++;
+ }
+
+ if (pos)
+ noautoload_buf[pos - 1] = '\0'; /* space to NUL */
+
+ mutex_exit(_noautoload_lock);
+}
+
+static int
+sysctl_module_noautoload(SYSCTLFN_ARGS)
+{
+ struct sysctlnode node;
+ int error;
+ char newbuf[sizeof(noautoload_buf)];
+
+
Re: Proposal, again: Disable autoload of compat_xyz modules
> I guess the main fear is that the attacker can put a malicious (and likely > explicitly crafted for a certain bug in NetBSD's linux compat) binary on > your machine and exectue it. Yes, I guess that's the (valid) point. My impression (I stay corrected) is that compat_linux is mostly used to run a very restricted set of Linux binaries (proprietary software not available for NetBSD) on a NetBSD host. So what would actually be needed (I guess) is a way to restrict emulation (actually running that emulation, not auto-loading the module) to a known set of binaries. I have no idea whether that's possible.
Re: Proposal, again: Disable autoload of compat_xyz modules
> and I'm making a proposal to disable this feature, to prevent this trouble > in the future. Nothing controversial about that, it just makes sense. > > You are not worth my time. Would you mind taking a deep breath and realize that I'm NOT OBJECTING to your proposal? I was just trying to say that, in my opinion, you are doing neither yourself nor your valid proposal a favour by trying to back your proposal with controversal or disputable claims (about compat_linux user base, its usefulness or usability)---claims that are unnecessary (or so I think) for backing your proposal. The point I was objecting to was your claim that compat_linux was of "little actual use" (because, for me, it's vital for keeping my file server running NetBSD).
Re: Proposal, again: Disable autoload of compat_xyz modules
On Fri, Sep 27, 2019 at 12:41:53AM -0400, Mouse wrote: > > Do you want to contribute and do all the actual dirty work for once, > > or you're just here to talk and give your random opinions on things > > you've never invested yourself in? What is your background? What is > > your portfolio? > > You're right that I'm not particularly invested in the original issue; > I don't use Linux compatability myself and I don't run NetBSD more > recent than 5.2 on my own machines (at one of my jobs it looks as > though 8.0 will get used - the reasons I don't run it don't apply > there). I got involved in this thread because invalid "arguments" like > made-up usage statistics bother me. I'm not opposed to the change per > se (I'm not sure whether I think it would actually be a good thing); > I'm opposed to doing it for specious reasons like "<1% users > interested". > > My background? B.Sc. mathematics major, computer science minor. > Programming since the late '70s, been making my living programming > and/or sysadminning since 1984. Been involved with UNIX as a user > since BSD 4.1c, with NetBSD since shortly before the split that led to > OpenBSD. > > My portfolio? Look for "der Mouse" in mail-index.n.o's archives for my > past presence on the lists (including source-changes for what I did > back when I was still committing). Look for > mo...@rodents-montreal.org for my presence after I dropped the "der" - > possibly mo...@rodents.montreal.qc.ca too; I forget which change > occurred first. Look at ftp.rodents-montreal.org:/mouse/git-repos and > clone whichever of them you care to. Perhaps the most notable ones are > moussh, git-interactive, livebackup, Mouse/games/blockade, > Mouse/dreamcast, Mouse/mousemuck, Mouse/vax-emul, Mouse/netbsd-fork/*. > Historically, there's also Mouse-X (an X implementation for 2bpp NeXT > hardware - that one isn't a git repo AFAIK). Look at > ftp.rodents-montreal.org; much of what's there is old versions of stuff > I now keep in git repos (I really kneed to clean it up), but there's > probably at least a little other stuff there. Probably the coolest thing is resize_ffs! Not sure you noticed, but now ARM images will resize themselves to the full size at boot, so to get a machine functional, all you need is to dd an image to an SD card and plug it in. It's so very convenient.
Re: Proposal, again: Disable autoload of compat_xyz modules
On Fri, 27 Sep 2019, Valery Ushakov wrote:
On Fri, Sep 27, 2019 at 11:36:08 -, Christos Zoulas wrote:
} I propose something very slightly different that can preserve the current
} functionality with user action:
}
} 1. Remove them from standard kernels in architectures where modules are
}supported. Users can add them back or just use modules.
} 2. Disable autoloading, but provide a sysctl to enable autoloading
}(1 global sysctl for all compat modules). Users can change the default
}in /etc/sysctl.conf (adds sysctl to the proposal)
You mean this (first line):
i386devel: {31} sysctl kern.module
kern.module.autoload = 0
kern.module.verbose = 0
kern.module.path = /stand/amd64-xen/8.99.26/modules
kern.module.autotime = 10
Perhaps:
kern.module.autoload.disable = linux,linux32
May be we should take a look at how SNMP did tables in MIB, b/c we are
trying to create just such a table indexed by module name.
Also, I'm not that sure about autoload of compat stuff especially
since iirc it currently implies auto-unload too. I vaguely remember
when I was debugging something in sh3 kobj_machdep.c I had some
printfs there that made the autoloads visibile and (iirc) each vi
invocation would trigger an autoload of compat ioctl code (which
wouldn't recognize the ioctl, and that would be auto-unloaded a few
seconds later).
kern.module.autotime controls the delay before the auto-unload takes
place. I think if you set it to zero, it will never auto-unload.
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Proposal, again: Disable autoload of compat_xyz modules
On Fri, Sep 27, 2019 at 11:36:08 -, Christos Zoulas wrote:
> >} I propose something very slightly different that can preserve the current
> >} functionality with user action:
> >}
> >} 1. Remove them from standard kernels in architectures where modules are
> >}supported. Users can add them back or just use modules.
> >} 2. Disable autoloading, but provide a sysctl to enable autoloading
> >}(1 global sysctl for all compat modules). Users can change the default
> >}in /etc/sysctl.conf (adds sysctl to the proposal)
> >
> > You mean this (first line):
> >
> >i386devel: {31} sysctl kern.module
> >kern.module.autoload = 0
> >kern.module.verbose = 0
> >kern.module.path = /stand/amd64-xen/8.99.26/modules
> >kern.module.autotime = 10
>
> Perhaps:
>
> kern.module.autoload.disable = linux,linux32
May be we should take a look at how SNMP did tables in MIB, b/c we are
trying to create just such a table indexed by module name.
Also, I'm not that sure about autoload of compat stuff especially
since iirc it currently implies auto-unload too. I vaguely remember
when I was debugging something in sh3 kobj_machdep.c I had some
printfs there that made the autoloads visibile and (iirc) each vi
invocation would trigger an autoload of compat ioctl code (which
wouldn't recognize the ioctl, and that would be auto-unloaded a few
seconds later).
-uwe
Re: Proposal, again: Disable autoload of compat_xyz modules
On Fri, Sep 27, 2019 at 10:57:12 +0200, Jarom?r Dole?ek wrote: > Le jeu. 26 sept. 2019 ? 18:08, Manuel Bouyer a ?crit > : > > > > On Thu, Sep 26, 2019 at 05:10:01PM +0200, Maxime Villard wrote: > > > issues for a clearly marginal use case, and given the current general > > ^^^ > > > > This is where we dissagree. You guess it's marginal but there's no > > evidence of that (and there's no evidence of the opposite either). > > FYI - I've put also a lot of efford into fixing & enhancing > compat_linux in past. I also greatly appreciate all the work work of > other folks working on the layer, it's super useful in some situations > - browser with flash support used to be important (thankfully not > anymore), also vmware and matlab, I also used some Oracle dev tools. > However, that is not the topic of the discussion. > > Let's concentrate on whether it should be enabled by default. Yes, please. This discussion has veered way off topic. > Given the history, to me it's completely clear compat_linux shouldn't > be on by default. Any possible linux-specific exploits should only be > problem for people actually explicitly enabling it. Let's just stop > pretending that we'd setup any kind of reasonable testing suite for > this - it has not been done in last >20 years, it's even less likely > to happen now that most of the major use cases are actually moot. > > As Maya suggested, let's keep this concentrated on COMPAT_LINUX only > to avoid further bikeshed flogging, so basically I propose doing this: > 1) Comment out COMPAT_LINUX from all kernels configs for all archs > which support modular > 2) Disable autoload for compat_linux, requiring the user to explicitly > configure system to load it. No extra sysctl. > > Any major and specific objections? At some point it became very hard to follow the technical content of this thread, but I don't think there were any. Thanks! -uwe
Re: Proposal, again: Disable autoload of compat_xyz modules
In article <201909262031.x8qkvnpv021...@server.cornerstoneservice.ca>,
John Nemeth wrote:
>On Sep 26, 7:40pm, Christos Zoulas wrote:
>} In article <390f4c81-bf1c-443f-f7a9-a379c46b7...@m00nbsd.net>,
>} Maxime Villard wrote:
>} >I recently made a big set of changes to fix many bugs and vulnerabilities in
>} >compat_linux and compat_linux32, the majority of which have a security
>impact
>} >bigger than the Intel CPU bugs we hear about so much. These compat layers
>are
>} >enabled by default, so everybody is affected.
>} >
>} >Secteam is in a state where no one is willing to pull up all the changes to
>} >the stable branches, because of the effort. No one is willing to write a
>} >security advisory either. When I say "no one", it includes me.
>} >
>} >The proposal and discussion held in this 2017 thread still hold and are
>} >unchanged two years later:
>} >
>} >https://mail-index.netbsd.org/tech-kern/2017/07/31/msg022153.html
>} >
>} >The compat layers are largely untested, often broken, and are a security
>risk
>} >for everybody. Keeping them enabled for the <1% users interested
>means keeping
>} >vulnerabilities for the >99% who don't use these features.
>} >
>} >In the conversation above, we hit the problem that there was
>cross-dependency
>} >among compat modules, and we couldn't selectively disable specific layers.
>} >Today this is possible thanks to pgoyette's work. That is, it is possible to
>} >comment out "options COMPAT_LINUX" from GENERIC, and have a
>compat_linux.kmod
>} >which will modload correctly and be able to run Linux binaries out of
>the box.
>} >Under this scheme, the feature would be only one root command away from
>being
>} >enabled in the kernel.
>} >
>} >Therefore, I am making today the same proposal as Taylor in 2017, because
>the
>} >problem is still there exactly as-is and we just hit it again; the solution
>} >however is more straightforward.
>}
>} I propose something very slightly different that can preserve the current
>} functionality with user action:
>}
>} 1. Remove them from standard kernels in architectures where modules are
>}supported. Users can add them back or just use modules.
>} 2. Disable autoloading, but provide a sysctl to enable autoloading
>}(1 global sysctl for all compat modules). Users can change the default
>}in /etc/sysctl.conf (adds sysctl to the proposal)
>
> You mean this (first line):
>
>i386devel: {31} sysctl kern.module
>kern.module.autoload = 0
>kern.module.verbose = 0
>kern.module.path = /stand/amd64-xen/8.99.26/modules
>kern.module.autotime = 10
Perhaps:
kern.module.autoload.disable = linux,linux32
christos
Re: Proposal, again: Disable autoload of compat_xyz modules
On Fri, Sep 27, 2019 at 08:30:40AM +0200, Martin Husemann wrote: > On Thu, Sep 26, 2019 at 09:40:22PM +0200, tlaro...@polynum.com wrote: > > If the vulnerabilities can only be exploited by running Linux binaries, > > IMHO, the point is moot: the ones that don't run Linux binaries are not > > affected; the ones that do need to run some Linux binaries will have to > > add the feature so this adds a user's intervention for the very same > > result at the end. > > I guess the main fear is that the attacker can put a malicious (and likely > explicitly crafted for a certain bug in NetBSD's linux compat) binary on > your machine and exectue it. If you have no untrusted local users > and no admin installed linux binaries, the risc should be quite small. Well, I don't think "trusted local users" exist anymore. Because they bring with them (or is it the reverse? The device brings them) i-phones or whatever and connect them, and download applications... Slightly related: is NetBSD providing build services so that someone, not wanting to open his sources, could at least build his program for NetBSD without installing it? Because the best way to avoid the compatibility is to have native NetBSD binaries. -- Thierry Laronde http://www.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: Proposal, again: Disable autoload of compat_xyz modules
On Fri, Sep 27, 2019 at 10:57:12AM +0200, Jaromír Dole?ek wrote: > [...] > Given the history, to me it's completely clear compat_linux shouldn't > be on by default. Any possible linux-specific exploits should only be > problem for people actually explicitly enabling it. Let's just stop > pretending that we'd setup any kind of reasonable testing suite for > this - it has not been done in last >20 years, it's even less likely > to happen now that most of the major use cases are actually moot. > > As Maya suggested, let's keep this concentrated on COMPAT_LINUX only > to avoid further bikeshed flogging, so basically I propose doing this: > 1) Comment out COMPAT_LINUX from all kernels configs for all archs > which support modular > 2) Disable autoload for compat_linux, requiring the user to explicitly > configure system to load it. No extra sysctl. > > Any major and specific objections? not from me. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal, again: Disable autoload of compat_xyz modules
Le jeu. 26 sept. 2019 à 18:08, Manuel Bouyer a écrit : > > On Thu, Sep 26, 2019 at 05:10:01PM +0200, Maxime Villard wrote: > > issues for a clearly marginal use case, and given the current general > ^^^ > > This is where we dissagree. You guess it's marginal but there's no > evidence of that (and there's no evidence of the opposite either). FYI - I've put also a lot of efford into fixing & enhancing compat_linux in past. I also greatly appreciate all the work work of other folks working on the layer, it's super useful in some situations - browser with flash support used to be important (thankfully not anymore), also vmware and matlab, I also used some Oracle dev tools. However, that is not the topic of the discussion. Let's concentrate on whether it should be enabled by default. Given the history, to me it's completely clear compat_linux shouldn't be on by default. Any possible linux-specific exploits should only be problem for people actually explicitly enabling it. Let's just stop pretending that we'd setup any kind of reasonable testing suite for this - it has not been done in last >20 years, it's even less likely to happen now that most of the major use cases are actually moot. As Maya suggested, let's keep this concentrated on COMPAT_LINUX only to avoid further bikeshed flogging, so basically I propose doing this: 1) Comment out COMPAT_LINUX from all kernels configs for all archs which support modular 2) Disable autoload for compat_linux, requiring the user to explicitly configure system to load it. No extra sysctl. Any major and specific objections? Jaromir
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 09:40:22PM +0200, tlaro...@polynum.com wrote: > If the vulnerabilities can only be exploited by running Linux binaries, > IMHO, the point is moot: the ones that don't run Linux binaries are not > affected; the ones that do need to run some Linux binaries will have to > add the feature so this adds a user's intervention for the very same > result at the end. I guess the main fear is that the attacker can put a malicious (and likely explicitly crafted for a certain bug in NetBSD's linux compat) binary on your machine and exectue it. If you have no untrusted local users and no admin installed linux binaries, the risc should be quite small. If you have local users, the risc is pretty high. The relatively bad testing situation for this compat layers could easily lead to non-malicious linux binaries running into strange error cases and triggereing corner cases in the compat layers (most likely variant: a user tries some random linux binary, the emulation is incomplete and the kernel crashes). There are other vectors to get to this vulnerabilities, but they all require exploiting some other serious bug first. Martin
Re: Proposal, again: Disable autoload of compat_xyz modules
> Do you want to contribute and do all the actual dirty work for once, > or you're just here to talk and give your random opinions on things > you've never invested yourself in? What is your background? What is > your portfolio? You're right that I'm not particularly invested in the original issue; I don't use Linux compatability myself and I don't run NetBSD more recent than 5.2 on my own machines (at one of my jobs it looks as though 8.0 will get used - the reasons I don't run it don't apply there). I got involved in this thread because invalid "arguments" like made-up usage statistics bother me. I'm not opposed to the change per se (I'm not sure whether I think it would actually be a good thing); I'm opposed to doing it for specious reasons like "<1% users interested". My background? B.Sc. mathematics major, computer science minor. Programming since the late '70s, been making my living programming and/or sysadminning since 1984. Been involved with UNIX as a user since BSD 4.1c, with NetBSD since shortly before the split that led to OpenBSD. My portfolio? Look for "der Mouse" in mail-index.n.o's archives for my past presence on the lists (including source-changes for what I did back when I was still committing). Look for mo...@rodents-montreal.org for my presence after I dropped the "der" - possibly mo...@rodents.montreal.qc.ca too; I forget which change occurred first. Look at ftp.rodents-montreal.org:/mouse/git-repos and clone whichever of them you care to. Perhaps the most notable ones are moussh, git-interactive, livebackup, Mouse/games/blockade, Mouse/dreamcast, Mouse/mousemuck, Mouse/vax-emul, Mouse/netbsd-fork/*. Historically, there's also Mouse-X (an X implementation for 2bpp NeXT hardware - that one isn't a git repo AFAIK). Look at ftp.rodents-montreal.org; much of what's there is old versions of stuff I now keep in git repos (I really kneed to clean it up), but there's probably at least a little other stuff there. /~\ 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, again: Disable autoload of compat_xyz modules
On 9/26/2019 17:02, Maxime Villard wrote: So here's what's going to happen. I will drop this thread, because in the end I don't care a lot. I will stop doing the work I've been doing, have withdrawn from secteam already, and won't be taking care of any of that from now on. I'm done, this is over. Bye, Felicia!
Re: Proposal, again: Disable autoload of compat_xyz modules
Le 26/09/2019 à 21:21, Mouse a écrit : So why the hell are you throwing in statements like immense trouble for little actual use. Because this is true! Do you understand, or not? Pfff. It's not me you were responding to here. But you appear to be falling into a relatively common trap: operating from the assumption that you are entirely correct and that your underlying assumptions are universally true, and that therefore anyone who disagrees with you must not understand what you are saying. Actually, you are right. This is the N-th time that this problem comes up. For the N-th time, I see people slipping away, trying to find moronic justifi- cations like "maybe the users don't know they use compat_linux". Of course I get upset, I've heard this crap N-1 times before. And the bigger the N gets, the more I am confident that I'm right, yes. And the less I'm tempted to discuss, also. I am absolutely upset at this moronic topic that has to come up again, and again, and again, because people can't process one minute that there is a *RISK* in these compat features. It's been literally years of this total nonsense. And I've heard all of the most idiotic reasons: from the "uh no you are just paranoid", to the "but you have no proof it is buggy", then to the "oh no but every software has bugs", down to now "maybe the users don't know they use compat_linux". You know who's the dumbass who is cleaning all this shit up each time? Well, it's me. I am the one trying to fix the bugs, processing pullups, writing security advisories, and even handling the bad press. And I did that again two weeks ago when I set up a fuzzing VM to find bugs in compat_linux which has resulted in all the fixes that now need even more effort to be pulled up, documented, etc, because this buggy crap is enabled by default. People are here creating a f*cking mess, and I'm here systematically doing the damage control. The slighest proposal is met with the biggest nonsense. Complete lack of engineering spirit on things as simple as disabling risky stuff, while other OSes have done that for years without problem. Idiocy at its finest. That's it, I've said it. I understand what you are claiming. I think most of us do. I simply disagree with some of it and see you as having failed to present a good case for most of the rest. Repeating your unsubstantiated claims - such as the one that you readily admitted was unsubstantiated when I called you on it - is not going to convince anyone of anything, possibly excepting that you have such a weak point that you have to resort to appeals to emotion rather than actual technical arguments to support it. The "unsubstantiated" claim is the percentage which I immediately clarified to you as being illustrative but not definitive. The only ones who are making unsubstianted claims are the ones who keep talking nonsense; like John Nemeth for example, who as usual makes a great demonstration of his intelligence by showing up late in a conversation and answering to each email in backwards order on points that have been addressed already. You are not worth my time. And you're now resorting to...well, it's not a classic ad hominem, but it's pretty close. (It's not any individual that should be "worth [your] time" or not, but rather the arguments presented.) Your arguments are convincing, but what they are convincing me, for one, of is not what you appear to want to convince people of. Well it appears you too have convinced me of something you were not expecting: that you are not worth my time either. Trying to suggest I'm making unsubstianted claims when I'm not. Trying to say I use emotions while I put forward the technical reasons and solution. Quoting single sentences like the above without quoting the paragraph. Do you want to contribute and do all the actual dirty work for once, or you're just here to talk and give your random opinions on things you've never invested yourself in? What is your background? What is your portfolio? Verily, I'm glad this thread has reached this point. Because it has just cleared away the cobwebs in my mind. My current inability to discuss this kind of topic, and to work through the nonsense, irrelevance and profound idiocy in the answers I'm facing, just shows I've accumulated so much frustration and anger towards this project. I believe it is clear, and in this regard, you are not completely wrong. So here's what's going to happen. I will drop this thread, because in the end I don't care a lot. I will stop doing the work I've been doing, have withdrawn from secteam already, and won't be taking care of any of that from now on. I'm done, this is over. Good luck
Re: Proposal, again: Disable autoload of compat_xyz modules
I have gone over your comments, trying to pin down what exactly went wrong. On Thu, Sep 26, 2019 at 07:32:58PM +0200, Maxime Villard wrote: > Le 26/09/2019 à 19:21, Edgar Fuß a écrit : > > I do understand you are not proposing to remove compat_linux. > > I do understand your proposal is just about disabling module auto-load > > (which I don't care about because I run a monolithic kernel). > > > > So why the hell are you throwing in statements like > > > immense trouble for little actual use. > > Because this is true! Do you understand, or not? Pfff. > > Yes, compat_linux has had vulnerabilities, repeatedly, and yes, this has > caused us immense trouble, like the situation right now, where we have things > to pull up and advisories to write but no one willing to do that work. This > has happened repeatedly, and I'm making a proposal to disable this feature, > to prevent this trouble in the future. Nothing controversial about that, it > just makes sense. > > You are not worth my time. First of all, that's not cool. I appreciate Edgar Fuß. Moving on. You see this as an unpopular proposal that will never get through. surely we just want compat forever and ever, and you're just here for round 6 after regaining your strength from the previous time. This is in fact a wildly popular idea, but somehow turned into a huge frustrating bikeshed again. Some pointers for the next time, since this is now so toxic it can't be touched with a ten foot pole: - Limit the scope of the removal/disabling being discussed. If you get no objections, these threads are easy, you can start another in 2 weeks for slightly more scope until you meet resistance. - Calm the worries of people who need this feature: it is just a "sysctl -w security.disable=1" away. We have some features in tree that say: WARNING: ZFS on NetBSD is under development This is OK. - If you are getting angry, take a break. You're antagonizing people as they are trying to relate to you. If you are lucky, and make good arguments, you can even persuade people to help with the changes. We're actually not super opposed to change and removals as a community. pkgsrc-users has a good flow going and now we regularly remove packages.
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 10:17:51AM +0200, Maxime Villard wrote: > I recently made a big set of changes to fix many bugs and vulnerabilities in > compat_linux and compat_linux32, the majority of which have a security impact > bigger than the Intel CPU bugs we hear about so much. These compat layers are > enabled by default, so everybody is affected. > I'm just an user, so I have just a question about the scope of the problem: Are the bugs and vulnerabilities in the compat_linux*, due to the compat glue added, opening code paths that can be exploited by a non-linux program for security threats or are the vulnerabilities only problems if a linux binary is run---and perhaps other (SCO) binaries? Because, as I see it, if this opens security problems even for the ones that do _not_ use linux (or other alien) binaries, as long as the features are still easily added (even by a post-install fix for pkgsrc programs) by loading a module for the ones who have to run alien programs, not including by default the compat_linux* modules (you don't speak about the NetBSD ABI compatibility, right?), seems reasonable. If the vulnerabilities can only be exploited by running Linux binaries, IMHO, the point is moot: the ones that don't run Linux binaries are not affected; the ones that do need to run some Linux binaries will have to add the feature so this adds a user's intervention for the very same result at the end. Furthermore, if the compatibility code is adding/opening problems that do not exist in the linux system emulated, it will mean that the security problem can be only exerted by someone creating a special version of a Linux program hoping it will be run under compat on NetBSD... Security is a matter of probabilities for me, and it seems that bugs (crashes) that is: not intentional "unfelicities" are more probable than malice in this case... Once more, I'm just a user. So the only thing I'm looking for is a precision about the scope of the problem---I will obviously cope with whatever decision is reached since I'm definitively not prepared to fork :-^ Best, -- Thierry Laronde http://www.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: Proposal, again: Disable autoload of compat_xyz modules
On Sep 26, 7:40pm, Christos Zoulas wrote:
} In article <390f4c81-bf1c-443f-f7a9-a379c46b7...@m00nbsd.net>,
} Maxime Villard wrote:
} >I recently made a big set of changes to fix many bugs and vulnerabilities in
} >compat_linux and compat_linux32, the majority of which have a security impact
} >bigger than the Intel CPU bugs we hear about so much. These compat layers are
} >enabled by default, so everybody is affected.
} >
} >Secteam is in a state where no one is willing to pull up all the changes to
} >the stable branches, because of the effort. No one is willing to write a
} >security advisory either. When I say "no one", it includes me.
} >
} >The proposal and discussion held in this 2017 thread still hold and are
} >unchanged two years later:
} >
} > https://mail-index.netbsd.org/tech-kern/2017/07/31/msg022153.html
} >
} >The compat layers are largely untested, often broken, and are a security risk
} >for everybody. Keeping them enabled for the <1% users interested means
keeping
} >vulnerabilities for the >99% who don't use these features.
} >
} >In the conversation above, we hit the problem that there was cross-dependency
} >among compat modules, and we couldn't selectively disable specific layers.
} >Today this is possible thanks to pgoyette's work. That is, it is possible to
} >comment out "options COMPAT_LINUX" from GENERIC, and have a compat_linux.kmod
} >which will modload correctly and be able to run Linux binaries out of the
box.
} >Under this scheme, the feature would be only one root command away from being
} >enabled in the kernel.
} >
} >Therefore, I am making today the same proposal as Taylor in 2017, because the
} >problem is still there exactly as-is and we just hit it again; the solution
} >however is more straightforward.
}
} I propose something very slightly different that can preserve the current
} functionality with user action:
}
} 1. Remove them from standard kernels in architectures where modules are
}supported. Users can add them back or just use modules.
} 2. Disable autoloading, but provide a sysctl to enable autoloading
}(1 global sysctl for all compat modules). Users can change the default
}in /etc/sysctl.conf (adds sysctl to the proposal)
You mean this (first line):
i386devel: {31} sysctl kern.module
kern.module.autoload = 0
kern.module.verbose = 0
kern.module.path = /stand/amd64-xen/8.99.26/modules
kern.module.autotime = 10
Or, did you want an additional sysctl that is specific to compat
modules. Then there is the question of whether it includes
COMPAT_NETBSDxx? I know the discussion has focused on COMPAT_LINUX,
but there are plenty of other COMPAT_*.
There is also my earlier message about only being able to load
modules at secure level 0. This makes them more difficult to use
if you don't have options INSECURE. With the new kernel side
graphics card drivers, we should looking at removing that by default.
}-- End of excerpt from Christos Zoulas
Re: Proposal, again: Disable autoload of compat_xyz modules
chris...@astron.com (Christos Zoulas) writes: > I propose something very slightly different that can preserve the current > functionality with user action: > > 1. Remove them from standard kernels in architectures where modules are >supported. Users can add them back or just use modules. > 2. Disable autoloading, but provide a sysctl to enable autoloading >(1 global sysctl for all compat modules). Users can change the default >in /etc/sysctl.conf (adds sysctl to the proposal) I am assuming that we are talking about disabling autoloading of a number of compat modules that are some combination of believed likely to have security bugs and not used extensively, and this includes compat for foreign OS, but does not, at least for now, include compat for older NetBSD. This situation is basically a balancing act of the needs/benefits somehow aggregated (I will avoid "averaged") over all users. It seems pretty unclear how to evaluate that in total. But, it does seem like your single-sysctl proposal means: people who like compat being autoloaded can add one line in sysctl.conf and be back where they were people who want specific modules can load them and not enable the general sysctl people who don't know about any of this who try to run Linux binaries will lose, and presumably there'd be a line in dmesg that says which module failed to autoload, like policy blocked autoloading compat_linux module; see compat_linux(8) which would then explain. I'm also assuming this is being talked about for HEAD and hence 10, and not 9. Overall, this seems like a reasonable compromise among conflicting goals. If older NetBSD compat were included, I'd want to see a separate sysctl, default-on for now. (My guess is that wanting to disable that is a fairly extreme position, at least these days.)
Re: Proposal, again: Disable autoload of compat_xyz modules
>> So why the hell are you throwing in statements like >>> immense trouble for little actual use. > Because this is true! Do you understand, or not? Pfff. It's not me you were responding to here. But you appear to be falling into a relatively common trap: operating from the assumption that you are entirely correct and that your underlying assumptions are universally true, and that therefore anyone who disagrees with you must not understand what you are saying. I understand what you are claiming. I think most of us do. I simply disagree with some of it and see you as having failed to present a good case for most of the rest. Repeating your unsubstantiated claims - such as the one that you readily admitted was unsubstantiated when I called you on it - is not going to convince anyone of anything, possibly excepting that you have such a weak point that you have to resort to appeals to emotion rather than actual technical arguments to support it. > You are not worth my time. And you're now resorting to...well, it's not a classic ad hominem, but it's pretty close. (It's not any individual that should be "worth [your] time" or not, but rather the arguments presented.) Your arguments are convincing, but what they are convincing me, for one, of is not what you appear to want to convince people of. /~\ 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, again: Disable autoload of compat_xyz modules
On Sep 26, 5:18pm, Maxime Villard wrote: } Le 26/09/2019 à 17:15, Manuel Bouyer a écrit : } > On Thu, Sep 26, 2019 at 05:10:01PM +0200, Maxime Villard wrote: } >> issues for a clearly marginal use case, and given the current general } > ^^^ } > } > This is where we dissagree. You guess it's marginal but there's no } > evidence of that (and there's no evidence of the opposite either). } } Can you provide evidence that it is used by the majority of the users? } And that therefore keeping vulnerabilities for 100% of the people is } legitimate? } } Please provide clear evidence. You are the one making the claim, it is your responsibility to back up the claim. Trying to push the responsibility to disprove your claim to the opposite side is a completely bogus way of debating. }-- End of excerpt from Maxime Villard
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 07:39:45PM +0200, Martin Husemann wrote: > On Thu, Sep 26, 2019 at 07:21:17PM +0200, Kamil Rytarowski wrote: > > As I have proposed. MUSL+LTP for catching functional regressions/bugs > > AND fuzzing to catch crashes can be good enough to keep it trusted. The > > kernel certainly needs a lot of bug fixes, but instead of disabling this > > crucial feature it is better to find a way to make it more trusted. > > Indeed. If we have a toolchain in pkgsrc (or some commparable easy setup) > and a test suite, we can build more trust for some compat feature. If the toolchain can be in pkgsrc, then I it should be much easier. At some point I could build linux binaries running a linux gcc under compat_linux. Maybe it's just a matter of adding a suse_toolchain package ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal, again: Disable autoload of compat_xyz modules
On Sep 26, 4:40pm, Maxime Villard wrote: } Le 26/09/2019 à 16:36, Manuel Bouyer a écrit : } > On Thu, Sep 26, 2019 at 04:29:52PM +0200, Maxime Villard wrote: } >> Le 26/09/2019 à 16:22, Mouse a écrit : } >> Keeping them enabled for the <1% users interested means keeping } >> vulnerabilities for the >99% who don't use these features. } > Are the usage numbers really that extreme? Where'd you get them? I } > didn't think there were any mechanisms in place that would allow } > tracking compat usage. } No, there is no strict procedure to monitor compat usage, and there } never will be. Maybe it's not <1%, but rather 1.5%; or maybe it's } 5%, 10%, 15%. } >>> } Who cares, exactly? } >>> } >>> The short answer is "anyone who wants NetBSD to be useful". } >>> } >>> If it really is only a tiny fraction - under ten people, say - then, } >>> sure, yank it out. If it's 90%, removing it would lose most of the } >>> userbase, possibly provoke a fork. 15%, 40%, I don't think there is a } >>> hard line between "pull it" and "keep it", and even if there were I'm } >>> not sure it would matter because it appears nobody knows what the } >>> actual use rate is anyway. } >> } >> What is known, however, is that 100% of the users are affected by the } >> vulnerabilities. So, do we keep these things enabled by default just } >> because "uh we don't know so we shouldn't do anything"? Even as it's } >> already been clear that the majority doesn't use compat_linux? } > } > Actually this is not clear. We have linux binaries in pkgsrc. } } ... And? We have 22000 packages in pkgsrc. } } >> Is it such a Herculean effort to type "modload compat_linux" for the } >> people that want to use Linux binaries? In order to keep the majority } >> safe from the bugs and vulnerabilities? } > } > Maybe some of them don't even know they are using compat_linux ... } } Yeah, and maybe I'm the Pope also, who knows. Now, you're just being obtuse. Although it is within the realm of possibility that you could be the pope operating under an alias, the likelihood of that being the case is so small as to be negligable. The pope is an extremely well known entity who's every action is closely monitored thus it would be extremely difficult for the pope to live a clandestine life as a TNF developer. Also, the known background of the the pope does not include software developement. If we want to throw out absuridities, it is far more likely that you're Julian Assange. }-- End of excerpt from Maxime Villard
Re: Proposal, again: Disable autoload of compat_xyz modules
> On Sep 26, 2019, at 7:22 AM, Mouse wrote: > > If it really is only a tiny fraction - under ten people, say - then, > sure, yank it out. No one's proposing yanking anything, simply requiring that a complex feature that receives much lest testing coverage require pro-active measures to enable. -- thorpej
Re: Proposal, again: Disable autoload of compat_xyz modules
On Sep 26, 3:51pm, Maxime Villard wrote: } Le 26/09/2019 à 15:06, Mouse a écrit : } >> [...] compat_linux and compat_linux32 [...] } > } >> Keeping them enabled for the <1% users interested means keeping } >> vulnerabilities for the >99% who don't use these features. } > } > Are the usage numbers really that extreme? Where'd you get them? I } > didn't think there were any mechanisms in place that would allow } > tracking compat usage. } } No, there is no strict procedure to monitor compat usage, and there never will } be. Maybe it's not <1%, but rather 1.5%; or maybe it's 5%, 10%, 15%. In other words, you're just pulling numbers out of your butt. There's a common expression, "There are lies, damned lies, and statistics." Things like this contribute to that expression. Of course, this can't be called a statistic in any real sense as it is just a made up number. } Who cares, exactly? Anybody that wants to have a serious discussion. }-- End of excerpt from Maxime Villard
Re: Proposal, again: Disable autoload of compat_xyz modules
Le 26/09/2019 à 19:39, Martin Husemann a écrit : Btw: I find it very strange that this proposal has no concrete proposal. What compat options exactly do you want to disallow from auto loading? What exact sysctls and semantics do you have in mind? My proposal is the same as Taylor's, as I said in the initial email. However, maybe keep the NetBSD-specific compat enabled as far as compat_50 or compat_60. The semantic is the one I stated in the initial email: the use of kernel modules, now that this is doable in practice.
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 07:39:45PM +0200, Martin Husemann wrote: > On Thu, Sep 26, 2019 at 07:21:17PM +0200, Kamil Rytarowski wrote: > > As I have proposed. MUSL+LTP for catching functional regressions/bugs > > AND fuzzing to catch crashes can be good enough to keep it trusted. The > > kernel certainly needs a lot of bug fixes, but instead of disabling this > > crucial feature it is better to find a way to make it more trusted. > > Indeed. If we have a toolchain in pkgsrc (or some commparable easy setup) > and a test suite, we can build more trust for some compat feature. > > This is quite easy for the COMATP_NETBSD_$N options, but extremely hard for > others. We should get this going for some COMATP_NETBSD_$N and COMPAT_LINUX > at least (and maybe make it a QA requirement to keep such options alive > or add new ones). > > Btw: I find it very strange that this proposal has no concrete proposal. > What compat options exactly do you want to disallow from auto loading? > What exact sysctls and semantics do you have in mind? > > Martin If someone wants a quick, already available option to testing linux compat, cd pkgsrc/lang/go112 make test GOOPT="GOOS=linux"
Re: Proposal, again: Disable autoload of compat_xyz modules
On Sep 26, 10:17am, Maxime Villard wrote: } } I recently made a big set of changes to fix many bugs and vulnerabilities in } compat_linux and compat_linux32, the majority of which have a security impact } bigger than the Intel CPU bugs we hear about so much. These compat layers are } enabled by default, so everybody is affected. } } Secteam is in a state where no one is willing to pull up all the changes to } the stable branches, because of the effort. No one is willing to write a } security advisory either. When I say "no one", it includes me. } } The proposal and discussion held in this 2017 thread still hold and are } unchanged two years later: } } https://mail-index.netbsd.org/tech-kern/2017/07/31/msg022153.html } } The compat layers are largely untested, often broken, and are a security risk } for everybody. Keeping them enabled for the <1% users interested means keeping } vulnerabilities for the >99% who don't use these features. Where did you get your statistics? I'm not saying that they are wrong, just that I won't accept them without evidence. } In the conversation above, we hit the problem that there was cross-dependency } among compat modules, and we couldn't selectively disable specific layers. } Today this is possible thanks to pgoyette's work. That is, it is possible to } comment out "options COMPAT_LINUX" from GENERIC, and have a compat_linux.kmod } which will modload correctly and be able to run Linux binaries out of the box. } Under this scheme, the feature would be only one root command away from being } enabled in the kernel. This is assuming that you're running with options INSECURE, otherwise you need to add it to /etc/modules.conf to have the module loaded at boot time and remain loaded. } Therefore, I am making today the same proposal as Taylor in 2017, because the } problem is still there exactly as-is and we just hit it again; the solution } however is more straightforward. }-- End of excerpt from Maxime Villard
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 07:21:17PM +0200, Kamil Rytarowski wrote: > As I have proposed. MUSL+LTP for catching functional regressions/bugs > AND fuzzing to catch crashes can be good enough to keep it trusted. The > kernel certainly needs a lot of bug fixes, but instead of disabling this > crucial feature it is better to find a way to make it more trusted. Indeed. If we have a toolchain in pkgsrc (or some commparable easy setup) and a test suite, we can build more trust for some compat feature. This is quite easy for the COMATP_NETBSD_$N options, but extremely hard for others. We should get this going for some COMATP_NETBSD_$N and COMPAT_LINUX at least (and maybe make it a QA requirement to keep such options alive or add new ones). Btw: I find it very strange that this proposal has no concrete proposal. What compat options exactly do you want to disallow from auto loading? What exact sysctls and semantics do you have in mind? Martin
Re: Proposal, again: Disable autoload of compat_xyz modules
I do understand you are not proposing to remove compat_linux. I do understand your proposal is just about disabling module auto-load (which I don't care about because I run a monolithic kernel). So why the hell are you throwing in statements like > immense trouble for little actual use. which a) are irrelevant for and distract from your original proposal (which, yes I do understand, is about disabling module auto-load) and b) are controversal at best: I run a file server which I need to back up to a server run by central IT (or buy a LTO library and hire some off-the-premisses storage location for a set of tapes). So I either need to run the propriatery client on the file server (which is not available for NetBSD), write my own client or switch to Linux.
Re: Proposal, again: Disable autoload of compat_xyz modules
On 26.09.2019 19:13, Maxime Villard wrote: > I think you are confused. > > Fuzzing does not act as a perfusion to keep something artificially alive. > > Part of the compat_linux bugs and vulns I fixed recently were found with a > simple fuzzing VM I set up. Yet, does it really change anything? My > proposal > is unchanged. The attack surface is huge, I've been able to exercise only a > subset of the syscalls. Now big pullups need to be done, and no one is > willing > to do them. The scanner bot also has found bugs that couldn't be found with > fuzzers. > > Disabling certain compat options preserves the functionality, significantly > reduces the attack surface, and eases maintenance as well. At least the > bugs > do not qualify as critical vulnerabilities if the feature is disabled. > > Fuzzing does not reduce the attack surface, and does not constitute "active > maintenance" either (like pulling up, writing advisories, etc...). As I have proposed. MUSL+LTP for catching functional regressions/bugs AND fuzzing to catch crashes can be good enough to keep it trusted. The kernel certainly needs a lot of bug fixes, but instead of disabling this crucial feature it is better to find a way to make it more trusted. But this is a non-trivial amount of work an likely won't be done without a stimulation. I'm fine to switch sysctl to enable it on boot. signature.asc Description: OpenPGP digital signature
Re: Proposal, again: Disable autoload of compat_xyz modules
> Nobody is making compat_linux work To me, this sounds disgraceful to certain NetBSD developers (thanks!) that repeatedly saved my day/month/year by implementing additional syscalls which were needed to run newer versions of dsmc.
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 06:45:44PM +0200, Maxime Villard wrote: > Le 26/09/2019 à 18:15, Manuel Bouyer a écrit : > > On Thu, Sep 26, 2019 at 05:28:11PM +0200, Maxime Villard wrote: > > > Le 26/09/2019 à 17:25, Brian Buhrow a écrit : > > > > [...] > > > > One implication of your proposal is that you'll disable the > > > > autoload > > > > functionality, users will turn it back on, use it, and be more > > > > vulnerable > > > > than they are now because the primary developers aren't concern with > > > > making > > > > things work or secure anymore. > > > > > > Nobody is making compat_linux work, nobody is making compat_linux secure. > > My experience with a Linux program using forks and signals is that it does not > work at all; the children get killed randomly for no reason, the parent > doesn't > receive the signals, and after some time everything needs to be killed and > restarted to work again. Completely broken. I didn't manage to find where > exactly the problem was. > > Under reasonable assumptions, compat_linux indeed used to be the most > maintained compat layer we had. This isn't the case anymore. Under reasonable > assumptions as well, it has a marginal use case, and can be disabled. > > Maybe Manuel can understand that for a minute? Or is he still looking for > evidence that I'm not the Pope? I'm conviced you're not the pope. You don't seem to understand that I use compat_linux on a regular basis. Probably not with the same softwares as you, but it does work for me. I forgot to mention, I also use it with opera. > > > Secure, I don't know. > > Well Manuel can pretend everything he wants, but when it comes to security and > compat_linux, we're entering the world of facts, and not reasonable > assumptions. I never contested your facts on this topic. "I don't know" just means that: I don't know. I've not looked at the code, nor at any changes in this area for a long time. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal, again: Disable autoload of compat_xyz modules
Le 26/09/2019 à 18:19, Kamil Rytarowski a écrit :
On 26.09.2019 15:55, Kamil Rytarowski wrote:
On 26.09.2019 15:06, Mouse wrote:
[...] compat_linux and compat_linux32 [...]
Keeping them enabled for the <1% users interested means keeping
vulnerabilities for the >99% who don't use these features.
Are the usage numbers really that extreme? Where'd you get them? I
didn't think there were any mechanisms in place that would allow
tracking compat usage.
I depend on compat_linux/compat_linux32 in at least 4 applications. I
don't use them daily, but frequently.
There are use-cases where linux_compat* is to be or not to be for NetBSD
as host. (At least one commercial user of NetBSD depends on it as well.)
In general it is fine to disable linux_compat* unless we can ensure its
correctness with regression tests and continuous fuzzing. As I discussed
with one developer, we could test linux_compat with faked/light linux
libc, unfortunately it still did not realize.
I have managed to get light cross-toolchain producing Linux binaries.
The only dependency is musl (+gmake to build it).
It works almost out of the box (I had to manually build certain files).
The only think that is required to be tuned is to add a dummy gnu_debuglink.
https://nxr.netbsd.org/xref/src/sys/compat/linux/common/linux_exec_elf32.c#214
The kernel shall have a fallback, and probably parse .intrp string and
look for 'ld-musl' in it.
$ cat m.c
#include
int
main(int argc, char **argv)
{
printf("Hello world!\n");
return 0;
}
$ musl-gcc m.c
$ objcopy --add-gnu-debuglink=/dev/null ./a.out
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib/ld-musl-x86_64.so.1, not stripped
$ ./a.out
Hello world!
Another step is to build LTP with musl-gcc and run the tests.
https://github.com/linux-test-project/ltp (LTP supports musl)
There will be some patches involved.
The question is how to setup the tests for it? anita + picking these
packages from pkgsrc?
Making a setup with a syzbot instance for linux32/linux64 target should
be not that difficult.
Unfortunately all that needs some work in various projects, integration,
upstreaming code (to LTP?) etc and maybe TNF could spare someone to do it.
Also linux_compat is getting more and more irrelevant as time pass due
to shortage in our futex code (lack of robust futexes).
This is slowly worked on.
I think you are confused.
Fuzzing does not act as a perfusion to keep something artificially alive.
Part of the compat_linux bugs and vulns I fixed recently were found with a
simple fuzzing VM I set up. Yet, does it really change anything? My proposal
is unchanged. The attack surface is huge, I've been able to exercise only a
subset of the syscalls. Now big pullups need to be done, and no one is willing
to do them. The scanner bot also has found bugs that couldn't be found with
fuzzers.
Disabling certain compat options preserves the functionality, significantly
reduces the attack surface, and eases maintenance as well. At least the bugs
do not qualify as critical vulnerabilities if the feature is disabled.
Fuzzing does not reduce the attack surface, and does not constitute "active
maintenance" either (like pulling up, writing advisories, etc...).
Re: Proposal, again: Disable autoload of compat_xyz modules
On 26.09.2019 19:01, Maxime Villard wrote: > Le 26/09/2019 à 18:56, Kamil Rytarowski a écrit : >> Statement that Linux-compat is not much used is false at least due to >> adobe-flash-plugin-11.2.202.644nb1. >> >> I find this package as a must have for a web browser. > > Uh? No, this is absolutely wrong. Flash player will be completely abandoned > by Adobe in 2020. The vast majority of the internet has switch to > equivalents. > It has also been disabled by default by Firefox and other web browsers for > years. Flash player is absolutely not a justification for compat_linux. In the real world banks and other services depend on it. signature.asc Description: OpenPGP digital signature
Re: Proposal, again: Disable autoload of compat_xyz modules
On 26.09.2019 18:45, Maxime Villard wrote: > Le 26/09/2019 à 18:15, Manuel Bouyer a écrit : >> On Thu, Sep 26, 2019 at 05:28:11PM +0200, Maxime Villard wrote: >>> Le 26/09/2019 à 17:25, Brian Buhrow a écrit : [...] One implication of your proposal is that you'll disable the autoload functionality, users will turn it back on, use it, and be more vulnerable than they are now because the primary developers aren't concern with making things work or secure anymore. >>> >>> Nobody is making compat_linux work, nobody is making compat_linux >>> secure. > > My experience with a Linux program using forks and signals is that it > does not > work at all; the children get killed randomly for no reason, the parent > doesn't > receive the signals, and after some time everything needs to be killed and > restarted to work again. Completely broken. I didn't manage to find where > exactly the problem was. > > Under reasonable assumptions, compat_linux indeed used to be the most > maintained compat layer we had. This isn't the case anymore. Under > reasonable > assumptions as well, it has a marginal use case, and can be disabled. > > Maybe Manuel can understand that for a minute? Or is he still looking for > evidence that I'm not the Pope? > >> Secure, I don't know. > > Well Manuel can pretend everything he wants, but when it comes to > security and > compat_linux, we're entering the world of facts, and not reasonable > assumptions. > > compat_linux has a history of being vulnerable, the main reason being that > it is is poorly tested - no ATF, no reliable way to exercise the code > comprehensively -, and not actively maintained either. This has led to a > series > of exploitable vulnerabilities in the past, and a few weeks ago I found > even > more of them using a rather simplistic QA technique. > > I want to remind you, once again, that no one is talking about removing > functionality. We are talking about disabling it by default. The > functionality > will still be there, and only one command away from being enabled. > FreeBSD has > been doing that for a while, and OpenBSD did too before removing their > version > of compat_linux. It is simple, and it makes sense, and I don't > understand the > fuss and the nonsence that Manuel is trying to throw here. Maybe propose a plan to TNF to get it into a better shape? Statement that Linux-compat is not much used is false at least due to adobe-flash-plugin-11.2.202.644nb1. I find this package as a must have for a web browser. signature.asc Description: OpenPGP digital signature
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 04:40:33PM +0200, Maxime Villard wrote: > > > > Actually this is not clear. We have linux binaries in pkgsrc. > > ... And? We have 22000 packages in pkgsrc. How is it relevant ? I install less than 200. But there is suse_base in them -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal, again: Disable autoload of compat_xyz modules
Le 26/09/2019 à 18:15, Manuel Bouyer a écrit : On Thu, Sep 26, 2019 at 05:28:11PM +0200, Maxime Villard wrote: Le 26/09/2019 à 17:25, Brian Buhrow a écrit : [...] One implication of your proposal is that you'll disable the autoload functionality, users will turn it back on, use it, and be more vulnerable than they are now because the primary developers aren't concern with making things work or secure anymore. Nobody is making compat_linux work, nobody is making compat_linux secure. My experience with a Linux program using forks and signals is that it does not work at all; the children get killed randomly for no reason, the parent doesn't receive the signals, and after some time everything needs to be killed and restarted to work again. Completely broken. I didn't manage to find where exactly the problem was. Under reasonable assumptions, compat_linux indeed used to be the most maintained compat layer we had. This isn't the case anymore. Under reasonable assumptions as well, it has a marginal use case, and can be disabled. Maybe Manuel can understand that for a minute? Or is he still looking for evidence that I'm not the Pope? Secure, I don't know. Well Manuel can pretend everything he wants, but when it comes to security and compat_linux, we're entering the world of facts, and not reasonable assumptions. compat_linux has a history of being vulnerable, the main reason being that it is is poorly tested - no ATF, no reliable way to exercise the code comprehensively -, and not actively maintained either. This has led to a series of exploitable vulnerabilities in the past, and a few weeks ago I found even more of them using a rather simplistic QA technique. I want to remind you, once again, that no one is talking about removing functionality. We are talking about disabling it by default. The functionality will still be there, and only one command away from being enabled. FreeBSD has been doing that for a while, and OpenBSD did too before removing their version of compat_linux. It is simple, and it makes sense, and I don't understand the fuss and the nonsence that Manuel is trying to throw here.
Re: Proposal, again: Disable autoload of compat_xyz modules
On 26.09.2019 15:55, Kamil Rytarowski wrote:
> On 26.09.2019 15:06, Mouse wrote:
>>> [...] compat_linux and compat_linux32 [...]
>>
>>> Keeping them enabled for the <1% users interested means keeping
>>> vulnerabilities for the >99% who don't use these features.
>>
>> Are the usage numbers really that extreme? Where'd you get them? I
>> didn't think there were any mechanisms in place that would allow
>> tracking compat usage.
>>
>
> I depend on compat_linux/compat_linux32 in at least 4 applications. I
> don't use them daily, but frequently.
>
> There are use-cases where linux_compat* is to be or not to be for NetBSD
> as host. (At least one commercial user of NetBSD depends on it as well.)
>
> In general it is fine to disable linux_compat* unless we can ensure its
> correctness with regression tests and continuous fuzzing. As I discussed
> with one developer, we could test linux_compat with faked/light linux
> libc, unfortunately it still did not realize.
>
I have managed to get light cross-toolchain producing Linux binaries.
The only dependency is musl (+gmake to build it).
It works almost out of the box (I had to manually build certain files).
The only think that is required to be tuned is to add a dummy gnu_debuglink.
https://nxr.netbsd.org/xref/src/sys/compat/linux/common/linux_exec_elf32.c#214
The kernel shall have a fallback, and probably parse .intrp string and
look for 'ld-musl' in it.
$ cat m.c
#include
int
main(int argc, char **argv)
{
printf("Hello world!\n");
return 0;
}
$ musl-gcc m.c
$ objcopy --add-gnu-debuglink=/dev/null ./a.out
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib/ld-musl-x86_64.so.1, not stripped
$ ./a.out
Hello world!
Another step is to build LTP with musl-gcc and run the tests.
https://github.com/linux-test-project/ltp (LTP supports musl)
There will be some patches involved.
The question is how to setup the tests for it? anita + picking these
packages from pkgsrc?
Making a setup with a syzbot instance for linux32/linux64 target should
be not that difficult.
Unfortunately all that needs some work in various projects, integration,
upstreaming code (to LTP?) etc and maybe TNF could spare someone to do it.
> Also linux_compat is getting more and more irrelevant as time pass due
> to shortage in our futex code (lack of robust futexes).
>
This is slowly worked on.
>> /~\ The ASCII Mouse
>> \ / Ribbon Campaign
>> X Against HTML mo...@rodents-montreal.org
>> / \ Email!7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
>>
>
>
signature.asc
Description: OpenPGP digital signature
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 05:28:11PM +0200, Maxime Villard wrote: > Le 26/09/2019 à 17:25, Brian Buhrow a écrit : > > [...] > > One implication of your proposal is that you'll disable the autoload > > functionality, users will turn it back on, use it, and be more vulnerable > > than they are now because the primary developers aren't concern with making > > things work or secure anymore. > > Nobody is making compat_linux work, nobody is making compat_linux secure. Actually it *does* work. Secure, I don't know. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal, again: Disable autoload of compat_xyz modules
Le 26/09/2019 à 16:47, Manuel Bouyer a écrit : On Thu, Sep 26, 2019 at 04:40:33PM +0200, Maxime Villard wrote: Actually this is not clear. We have linux binaries in pkgsrc. ... And? We have 22000 packages in pkgsrc. How is it relevant ? I install less than 200. But there is suse_base in them The real question, is how the fact that there are linux binaries in pkgsrc relevant. Yes, there are packages. And? Most of them are completely outdated and haven't been updated in the last 10 years.
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 04:52:35PM +0200, Maxime Villard wrote: > Le 26/09/2019 à 16:47, Manuel Bouyer a écrit : > > On Thu, Sep 26, 2019 at 04:40:33PM +0200, Maxime Villard wrote: > > > > > > > > Actually this is not clear. We have linux binaries in pkgsrc. > > > > > > ... And? We have 22000 packages in pkgsrc. > > > > How is it relevant ? I install less than 200. But there is suse_base in them > > The real question, is how the fact that there are linux binaries in > pkgsrc relevant. Yes, there are packages. And? Most of them are it's relevant because they are in the binary repositories, so anyone can install them with pkg_add or pkgin. And they don't even have to know these are linux binaries. > completely outdated and haven't been updated in the last 10 years. They were usefull 10 years ago; it doen't make then useless now. For example I use then to run eagle, or microchip compilers, on a regular basis. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 05:10:01PM +0200, Maxime Villard wrote: > issues for a clearly marginal use case, and given the current general ^^^ This is where we dissagree. You guess it's marginal but there's no evidence of that (and there's no evidence of the opposite either). -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 05:18:34PM +0200, Maxime Villard wrote: > Le 26/09/2019 à 17:15, Manuel Bouyer a écrit : > > On Thu, Sep 26, 2019 at 05:10:01PM +0200, Maxime Villard wrote: > > > issues for a clearly marginal use case, and given the current general > > ^^^ > > > > This is where we dissagree. You guess it's marginal but there's no > > evidence of that (and there's no evidence of the opposite either). > > Can you provide evidence that it is used by the majority of the users? As I said I don't have evidence either way > And that therefore keeping vulnerabilities for 100% of the people is > legitimate? I never said it is. What I'm saying is that your claim about very few peoples using the compat modules may be wrong. This is different. (and to make it clear: I don't care if modules autoload or not; I'm not using modules). -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal, again: Disable autoload of compat_xyz modules
Le 26/09/2019 à 17:25, Brian Buhrow a écrit : [...] One implication of your proposal is that you'll disable the autoload functionality, users will turn it back on, use it, and be more vulnerable than they are now because the primary developers aren't concern with making things work or secure anymore. Nobody is making compat_linux work, nobody is making compat_linux secure.
Re: Proposal, again: Disable autoload of compat_xyz modules
hello. I make heavy use of the COMPAT_XYZ functions and have done so for many years. As Mouse says, it's what makes NetBSD very usable and easy to maintain. If that functionality left NetBSD, it would reduce its value significantly. I understand it's a lot of work to maintain this functionality and there are a lot of subtle interactions between the modules as they relate to security, but it is a real time saver in terms of being able to maintain OS levels while continuing to be able to use working applications and knowing that the next upgrade of the OS isn't going to break some critical service in my shop. One implication of your proposal is that you'll disable the autoload functionality, users will turn it back on, use it, and be more vulnerable than they are now because the primary developers aren't concern with making things work or secure anymore. If I remember the discussion from a couple of years ago, there was some distinction about the invasiveness of each compat option and its relative security threat. I think a blanket disabling of the compat options is too big of ahammer and a more nuanced approach should be taken. -thanks On Sep 26, 10:22am, Mouse wrote: } Subject: Re: Proposal, again: Disable autoload of compat_xyz modules } >>> Keeping them enabled for the <1% users interested means keeping } >>> vulnerabilities for the >99% who don't use these features. } >> Are the usage numbers really that extreme? Where'd you get them? I } >> didn't think there were any mechanisms in place that would allow } >> tracking compat usage. } > No, there is no strict procedure to monitor compat usage, and there } > never will be. Maybe it's not <1%, but rather 1.5%; or maybe it's } > 5%, 10%, 15%. } } > Who cares, exactly? } } The short answer is "anyone who wants NetBSD to be useful". } } If it really is only a tiny fraction - under ten people, say - then, } sure, yank it out. If it's 90%, removing it would lose most of the } userbase, possibly provoke a fork. 15%, 40%, I don't think there is a } hard line between "pull it" and "keep it", and even if there were I'm } not sure it would matter because it appears nobody knows what the } actual use rate is anyway. } } > This compat topic has been discussed over and over, and the } > conclusion is systematically that these compat options cause immense } > trouble for little actual use. } } Except the "little actual use" is, apparently, nothing but various wild } guesses at the actual proportion. Based on what I've seen in this } thread, it looks as though the use rate is around 1/2 (two users, two } non-users) - but, of course, that has no statistical validity; the } sample is ludicrously small and entirely self-selected. } } /~\ The ASCII Mouse } \ / Ribbon Campaign } X Against HTML mo...@rodents-montreal.org } / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B >-- End of excerpt from Mouse
Re: Proposal, again: Disable autoload of compat_xyz modules
Le 26/09/2019 à 17:15, Manuel Bouyer a écrit : On Thu, Sep 26, 2019 at 05:10:01PM +0200, Maxime Villard wrote: issues for a clearly marginal use case, and given the current general ^^^ This is where we dissagree. You guess it's marginal but there's no evidence of that (and there's no evidence of the opposite either). Can you provide evidence that it is used by the majority of the users? And that therefore keeping vulnerabilities for 100% of the people is legitimate? Please provide clear evidence.
Re: Proposal, again: Disable autoload of compat_xyz modules
Le 26/09/2019 à 17:03, Manuel Bouyer a écrit : On Thu, Sep 26, 2019 at 04:52:35PM +0200, Maxime Villard wrote: Le 26/09/2019 à 16:47, Manuel Bouyer a écrit : On Thu, Sep 26, 2019 at 04:40:33PM +0200, Maxime Villard wrote: Actually this is not clear. We have linux binaries in pkgsrc. ... And? We have 22000 packages in pkgsrc. How is it relevant ? I install less than 200. But there is suse_base in them The real question, is how the fact that there are linux binaries in pkgsrc relevant. Yes, there are packages. And? Most of them are it's relevant because they are in the binary repositories, so anyone can install them with pkg_add or pkgin. And they don't even have to know these are linux binaries. completely outdated and haven't been updated in the last 10 years. They were usefull 10 years ago; it doen't make then useless now. For example I use then to run eagle, or microchip compilers, on a regular basis. Have you at least read my initial email? I am not saying compat_linux is useless, I am saying that it has security issues for a clearly marginal use case, and given the current general unwillingness to maintain it and handle the security issues in it, it is a good candidate for being disabled (!= removed). Same as it was in 2017 when Taylor started the first thread. Can we stop this moronic conversation and get back to the point? Thanks. Disabling it doesn't mean removing it, and "modload compat_linux" will restitute the functionality entirely while perserving against the vulnerabilities by default.
Re: Proposal, again: Disable autoload of compat_xyz modules
Le 26/09/2019 à 16:36, Manuel Bouyer a écrit : On Thu, Sep 26, 2019 at 04:29:52PM +0200, Maxime Villard wrote: Le 26/09/2019 à 16:22, Mouse a écrit : Keeping them enabled for the <1% users interested means keeping vulnerabilities for the >99% who don't use these features. Are the usage numbers really that extreme? Where'd you get them? I didn't think there were any mechanisms in place that would allow tracking compat usage. No, there is no strict procedure to monitor compat usage, and there never will be. Maybe it's not <1%, but rather 1.5%; or maybe it's 5%, 10%, 15%. Who cares, exactly? The short answer is "anyone who wants NetBSD to be useful". If it really is only a tiny fraction - under ten people, say - then, sure, yank it out. If it's 90%, removing it would lose most of the userbase, possibly provoke a fork. 15%, 40%, I don't think there is a hard line between "pull it" and "keep it", and even if there were I'm not sure it would matter because it appears nobody knows what the actual use rate is anyway. What is known, however, is that 100% of the users are affected by the vulnerabilities. So, do we keep these things enabled by default just because "uh we don't know so we shouldn't do anything"? Even as it's already been clear that the majority doesn't use compat_linux? Actually this is not clear. We have linux binaries in pkgsrc. ... And? We have 22000 packages in pkgsrc. Is it such a Herculean effort to type "modload compat_linux" for the people that want to use Linux binaries? In order to keep the majority safe from the bugs and vulnerabilities? Maybe some of them don't even know they are using compat_linux ... Yeah, and maybe I'm the Pope also, who knows.
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 04:29:52PM +0200, Maxime Villard wrote: > Le 26/09/2019 à 16:22, Mouse a écrit : > > > > > Keeping them enabled for the <1% users interested means keeping > > > > > vulnerabilities for the >99% who don't use these features. > > > > Are the usage numbers really that extreme? Where'd you get them? I > > > > didn't think there were any mechanisms in place that would allow > > > > tracking compat usage. > > > No, there is no strict procedure to monitor compat usage, and there > > > never will be. Maybe it's not <1%, but rather 1.5%; or maybe it's > > > 5%, 10%, 15%. > > > > > Who cares, exactly? > > > > The short answer is "anyone who wants NetBSD to be useful". > > > > If it really is only a tiny fraction - under ten people, say - then, > > sure, yank it out. If it's 90%, removing it would lose most of the > > userbase, possibly provoke a fork. 15%, 40%, I don't think there is a > > hard line between "pull it" and "keep it", and even if there were I'm > > not sure it would matter because it appears nobody knows what the > > actual use rate is anyway. > > What is known, however, is that 100% of the users are affected by the > vulnerabilities. So, do we keep these things enabled by default just > because "uh we don't know so we shouldn't do anything"? Even as it's > already been clear that the majority doesn't use compat_linux? Actually this is not clear. We have linux binaries in pkgsrc. > Is it such a Herculean effort to type "modload compat_linux" for the > people that want to use Linux binaries? In order to keep the majority > safe from the bugs and vulnerabilities? Maybe some of them don't even know they are using compat_linux ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal, again: Disable autoload of compat_xyz modules
Le 26/09/2019 à 16:22, Mouse a écrit : Keeping them enabled for the <1% users interested means keeping vulnerabilities for the >99% who don't use these features. Are the usage numbers really that extreme? Where'd you get them? I didn't think there were any mechanisms in place that would allow tracking compat usage. No, there is no strict procedure to monitor compat usage, and there never will be. Maybe it's not <1%, but rather 1.5%; or maybe it's 5%, 10%, 15%. Who cares, exactly? The short answer is "anyone who wants NetBSD to be useful". If it really is only a tiny fraction - under ten people, say - then, sure, yank it out. If it's 90%, removing it would lose most of the userbase, possibly provoke a fork. 15%, 40%, I don't think there is a hard line between "pull it" and "keep it", and even if there were I'm not sure it would matter because it appears nobody knows what the actual use rate is anyway. What is known, however, is that 100% of the users are affected by the vulnerabilities. So, do we keep these things enabled by default just because "uh we don't know so we shouldn't do anything"? Even as it's already been clear that the majority doesn't use compat_linux? Is it such a Herculean effort to type "modload compat_linux" for the people that want to use Linux binaries? In order to keep the majority safe from the bugs and vulnerabilities?
Re: Proposal, again: Disable autoload of compat_xyz modules
>>> Keeping them enabled for the <1% users interested means keeping >>> vulnerabilities for the >99% who don't use these features. >> Are the usage numbers really that extreme? Where'd you get them? I >> didn't think there were any mechanisms in place that would allow >> tracking compat usage. > No, there is no strict procedure to monitor compat usage, and there > never will be. Maybe it's not <1%, but rather 1.5%; or maybe it's > 5%, 10%, 15%. > Who cares, exactly? The short answer is "anyone who wants NetBSD to be useful". If it really is only a tiny fraction - under ten people, say - then, sure, yank it out. If it's 90%, removing it would lose most of the userbase, possibly provoke a fork. 15%, 40%, I don't think there is a hard line between "pull it" and "keep it", and even if there were I'm not sure it would matter because it appears nobody knows what the actual use rate is anyway. > This compat topic has been discussed over and over, and the > conclusion is systematically that these compat options cause immense > trouble for little actual use. Except the "little actual use" is, apparently, nothing but various wild guesses at the actual proportion. Based on what I've seen in this thread, it looks as though the use rate is around 1/2 (two users, two non-users) - but, of course, that has no statistical validity; the sample is ludicrously small and entirely self-selected. /~\ 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, again: Disable autoload of compat_xyz modules
On 26.09.2019 15:06, Mouse wrote: >> [...] compat_linux and compat_linux32 [...] > >> Keeping them enabled for the <1% users interested means keeping >> vulnerabilities for the >99% who don't use these features. > > Are the usage numbers really that extreme? Where'd you get them? I > didn't think there were any mechanisms in place that would allow > tracking compat usage. > I depend on compat_linux/compat_linux32 in at least 4 applications. I don't use them daily, but frequently. There are use-cases where linux_compat* is to be or not to be for NetBSD as host. (At least one commercial user of NetBSD depends on it as well.) In general it is fine to disable linux_compat* unless we can ensure its correctness with regression tests and continuous fuzzing. As I discussed with one developer, we could test linux_compat with faked/light linux libc, unfortunately it still did not realize. Also linux_compat is getting more and more irrelevant as time pass due to shortage in our futex code (lack of robust futexes). > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTML mo...@rodents-montreal.org > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > signature.asc Description: OpenPGP digital signature
Re: Proposal, again: Disable autoload of compat_xyz modules
Le 26/09/2019 à 15:06, Mouse a écrit : [...] compat_linux and compat_linux32 [...] Keeping them enabled for the <1% users interested means keeping vulnerabilities for the >99% who don't use these features. Are the usage numbers really that extreme? Where'd you get them? I didn't think there were any mechanisms in place that would allow tracking compat usage. No, there is no strict procedure to monitor compat usage, and there never will be. Maybe it's not <1%, but rather 1.5%; or maybe it's 5%, 10%, 15%. Who cares, exactly? This compat topic has been discussed over and over, and the conclusion is systematically that these compat options cause immense trouble for little actual use. Now, we are again discussing the matter, because the problem is still there.
Re: Proposal, again: Disable autoload of compat_xyz modules
On Thu, Sep 26, 2019 at 01:47:06PM +, m...@netbsd.org wrote: > Since the subject is a bit generic, I'd like to note that not all > compats are equal. compat netbsd-6 and newer is more widely used due > to programming languages either using custom asm (Go) or binary > bootstrap (Ada). > > These are fairly easy to fix and I don't mind helping with the work but > it would be nice for someone to run a before/after bulk build of pkgsrc > to see what breaks. Sure. Also, I use NETBSD_COMPAT* on a regular basis for upgrade (boot new kernel with old userland then upgrade userland) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Proposal, again: Disable autoload of compat_xyz modules
Since the subject is a bit generic, I'd like to note that not all compats are equal. compat netbsd-6 and newer is more widely used due to programming languages either using custom asm (Go) or binary bootstrap (Ada). These are fairly easy to fix and I don't mind helping with the work but it would be nice for someone to run a before/after bulk build of pkgsrc to see what breaks.
Re: Proposal, again: Disable autoload of compat_xyz modules
> [...] compat_linux and compat_linux32 [...] > Keeping them enabled for the <1% users interested means keeping > vulnerabilities for the >99% who don't use these features. Are the usage numbers really that extreme? Where'd you get them? I didn't think there were any mechanisms in place that would allow tracking compat usage. /~\ 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, again: Disable autoload of compat_xyz modules
Le jeu. 26 sept. 2019 à 10:54, Maxime Villard a écrit : > I recently made a big set of changes to fix many bugs and vulnerabilities in > compat_linux and compat_linux32, the majority of which have a security impact > bigger than the Intel CPU bugs we hear about so much. These compat layers are > enabled by default, so everybody is affected. > ... > Therefore, I am making today the same proposal as Taylor in 2017, because the > problem is still there exactly as-is and we just hit it again; the solution > however is more straightforward. Yes please, it's the right thing to do. Just please still keep also the option to compile it into the kernel. I also now have no objection to moving all the arch-specific bits under sys/compat/ as you suggested in the old thread. Jaromir
Proposal, again: Disable autoload of compat_xyz modules
I recently made a big set of changes to fix many bugs and vulnerabilities in compat_linux and compat_linux32, the majority of which have a security impact bigger than the Intel CPU bugs we hear about so much. These compat layers are enabled by default, so everybody is affected. Secteam is in a state where no one is willing to pull up all the changes to the stable branches, because of the effort. No one is willing to write a security advisory either. When I say "no one", it includes me. The proposal and discussion held in this 2017 thread still hold and are unchanged two years later: https://mail-index.netbsd.org/tech-kern/2017/07/31/msg022153.html The compat layers are largely untested, often broken, and are a security risk for everybody. Keeping them enabled for the <1% users interested means keeping vulnerabilities for the >99% who don't use these features. In the conversation above, we hit the problem that there was cross-dependency among compat modules, and we couldn't selectively disable specific layers. Today this is possible thanks to pgoyette's work. That is, it is possible to comment out "options COMPAT_LINUX" from GENERIC, and have a compat_linux.kmod which will modload correctly and be able to run Linux binaries out of the box. Under this scheme, the feature would be only one root command away from being enabled in the kernel. Therefore, I am making today the same proposal as Taylor in 2017, because the problem is still there exactly as-is and we just hit it again; the solution however is more straightforward.
