linux-kernel - Re: [PATCH] Force UNIX domain sockets to be built in

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <64bb37e0712311037w42bae43ayb3c10b2e0310586d@mail.gmail.com>
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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/