linux-kernel - Re: [PATCH] exec: Make do_coredump more robust and safer when using pipes in core

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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 28 Jun 2009 14:35:31 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Neil Horman <nhorman@...driver.com>,
	linux-kernel@...r.kernel.org, earl_chew@...lent.com,
	Oleg Nesterov <oleg@...hat.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] exec: Make do_coredump more robust and safer when using pipes in core_pattern

Andrew Morton <akpm@...ux-foundation.org> writes:

> On Sun, 28 Jun 2009 21:31:12 +0200 Andi Kleen <andi@...stfloor.org> wrote:
>
>> > One way would be to add a new sysctl-externs.h and then put all the
>> > declarations in there.  That file gets included by sysctl.c and by each
>> > file which shares a global with sysctl.c
>> 
>> Long ago I had a experimental patch to put sysctls into a new ELF section. The 
>> you could simply put a DEFINE_SYSCTL(....) into the appropiate source file
>> which defined the variable and most of the tables went.
>> 
>> No externs, no mess, no patch collisions, everything much nicer.
>> 
>> The only problem was that it didn't support the numerical sysctl
>> space, so that would need to be removed first.
>> 
>> It's deprecated for quite some time now:
>> 
>>   if (msg_count < 5) {
>>                 msg_count++;
>>                 printk(KERN_INFO
>>                         "warning: process `%s' used the deprecated sysctl "
>>                         "system call with ", current->comm);
>> 
>> Should it finally go now? If yes I could polish up the old patch again.
>> 
>
> I suspect that it will be a long time before we can actually remove the
> numerical sysctl support, if ever.  In _theory_ we should support it
> for ever.  But in practice, we could probably remove it with a minimum
> of disruption a few years hence, but it's hard to work this out.
>
> When was the last time we saw a "warning: process `%s' used the
> obsolete bdflush system call" warning?  A quick google here says 2004. 
> Is that data?  A bit, I guess.
>
> Maybe Eric has thought about this issue?

I have a patchset.  That I intend to dust off now and repost now that the
merge window has closed that converts all of the binary sysctl handling
into compatibility code that calls read/write on the ascii sysctls.

The bulk of the patchset is removing all of the binary sysctl support code
from all of the susbystems that it makes no longer needed.

At which point the maintenance pain is of all of the binary sysctls is
essentially removed.

At which point the technical decisions on dumping binary become much
easier.  They are reduced to one big file that we can keep or compile
out at our leisure.  I still figure September 2010 as documented in
feature-removal.txt sounds like a good date for the final ripping all of
the binary sysctl code out.

It is certainly time to remove the internal ABIs.  The current system
is still too error prone, for users adding new sysctls.  It was only
a week or two ago that I had to nack a patch for adding a binary sysctl.

Once we have purged the binary parts it should be much easier to simplify
the sysctl code.

So my big question:

Andrew should I toss all 100 or so patches over the wall to you
and your -mm tree?  Or should I maintain a public git tree based
at 2.6.31-rc1?  Get it into linux-next and ask Linus to pull it when
the merge window comes?

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/