lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 31 Dec 2007 19:37:43 +0100 From: "Torsten Kaiser" <just.for.lkml@...glemail.com> To: "Michael Buesch" <mb@...sch.de> Cc: "Alan Cox" <alan@...rguk.ukuu.org.uk>, "Adrian Bunk" <bunk@...nel.org>, "Bodo Eggert" <7eggert@....de>, "Jan Engelhardt" <jengelh@...putergmbh.de>, devzero@....de, linux-kernel@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH] Force UNIX domain sockets to be built in On Dec 31, 2007 6:18 PM, Michael Buesch <mb@...sch.de> wrote: > On Monday 31 December 2007 17:38:03 Alan Cox wrote: > > On Mon, 31 Dec 2007 17:17:19 +0100 > > "Torsten Kaiser" <just.for.lkml@...glemail.com> wrote: > > > > > a) this could be disabled during development if you want this > > > b) this would even only affect development if you add new code that > > > now needs a EXPORT_SYMBOL that was removed on an earlier build. And > > > right now this would also need to trigger a rerun of depmod. And the > > > same trigger could redo this garbage collect. > > > > > > Or am I missing something obvious? > > > > Development is not a phase seperate from use or distribution. A lot of > > module testers for distributions will not be compiling their own modules > > but loading in ones to test provided by their vendor - which may of > > course then need different ksyms I understand that point. I just always assumed that kernel tests meant 'please test this patch' and doing the compile yourself. But I'm not convinced be the following: > As an example, the whole purpose wireless-compat package is > to load latest bleeding edge wireless stuff into a distribution kernel. > So people are not required to recompile their kernels for using > drivers that support their hardware. > And guess what, it is used a _lot_. And lots of bugs are found with it. > It increases our testing community a lot. This looks more like a "regular" out-of-tree module for the purpose of the suggested symbol garbage collector. And for that case I already a 'don't use it then'-note. The base problem is that there already are many options to break external modules. (CONFIG_MODULES=n ;) ) Or in the case of this wireless module: CONFIG_CRYPTO_ARC4=n (Without 'arc4' ieee80211_wep_init() will fail, that will fail ieee80211_register_hw() and so no mac80211 driver could be loaded) > So, all this wouldn't work, if kernel symbols could randomly get > nuked by some "garbage collector". > > In practice, no distribution would use symbol garbage collection, as the > only benefit from it would be an increased level of bugreports. The question I can't answer in this context is: Do distributions want to support external modules? Only if yes, your argument is valid. But then they could just disable this feature and prevent this kind of bugreports. Torsten -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists