linux-kernel - Re: [PATCH] Move sysctl check into debugging section and don't make it default y

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: <m1abf6vl7p.fsf@frodo.ebiederm.org>
Date:	Thu, 21 Aug 2008 01:14:18 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andi Kleen <andi@...stfloor.org>
Cc:	torvalds@...l.org, linux-kernel@...r.kernel.org,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH] Move sysctl check into debugging section and don't make it default y

Andi Kleen <andi@...stfloor.org> writes:

>> What is a feature change like this doing coming in after the
>> merge window?
>
> I considered it a "anti bloat bugfix". Adding 30k of 
> object code to allno was a bit too much. 
>
>> Why doesn't an allnoconfig disable sysctl all together?
>
> Because it depends on EMBEDDED and EMBEDDED is not y. Yes it's not
> intuitive, on the other hand the end result is reasonable.

That makes sense in a silly sort of way.  Making
allnoconfig not a particularly good minimal size check.

>> These are the only checks we have against someone doing something
>> nasty in the sysctl hierarchy.   We have proven that we don't
>> have the discipline to do the right thing with code in the
>> core kernel.  I expect out of tree code will be much worse.
>
> My assumption is that they will be run at least once during
> a release cycle by someone and then the messages will appear
> and be reported. We do the same thing with a lot of other
> debug options (lockdep, slab debug, sleep debug etc.,). There's no 
> need for this one to be special.

But it really isn't a debug option.

> Also I'm not sure the check is all that useful anyways. We
> should just not accept any new binary numbered sysctl, and
> that's nearly the case anyways.

This code is the mechanism by which we do not accept any
new binary numbered sysctl into the kernel.

Andrew used to get them just often enough that I would get a message
ever couple of months.  What and why is our policy with respect to new
binary sysctls?

Since this code has yet to ship in any enterprise kernel to my knowledge
I expect there are going to be another raft load of kernel bugs discovered
in out of tree code when it does.  We have a decade or more of near
total neglect to make up for.

As for what the code does.  There is one big expensive (space wise)
check in there that ensures we don't add new sysctl binary names.
Beyond that the checks that sysctl_check performs are actual sanity
checks with the only expensive one being to ensure we don't register
the same name twice.  Real code hits those checks, and frequently not
in development, but in some weird production scenario.  And the code
only runs when we register a sysctl so it is cheap.

Which is the big difference between this code and debugging checks,
even when enabled it barely ever runs.

Now if you would like to fix the size issue.  The thing to do is to
add a type field or a conversion function onto those tables.  Which is
enough to implement all of our binary sysctls by looking up the ascii
equivalents and calling the proc handling functions.  Then those tables
would be much more then dead weight.

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