linux-kernel - Re: [PATCH v12 01/13] sk_run_filter: add support for custom load

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: <eba2ab81bc32f208b8b94fd959fd7f2f.squirrel@webmail.greenhost.nl>
Date:	Fri, 2 Mar 2012 05:04:41 +0100
From:	"Indan Zupancic" <indan@....nu>
To:	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	"Kees Cook" <keescook@...omium.org>,
	"Stephen Rothwell" <sfr@...b.auug.org.au>,
	"Will Drewry" <wad@...omium.org>, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
	kernel-hardening@...ts.openwall.com, netdev@...r.kernel.org,
	x86@...nel.org, arnd@...db.de, davem@...emloft.net, hpa@...or.com,
	mingo@...hat.com, oleg@...hat.com, peterz@...radead.org,
	rdunlap@...otime.net, mcgrathr@...omium.org, tglx@...utronix.de,
	luto@....edu, eparis@...hat.com, serge.hallyn@...onical.com,
	djm@...drot.org, scarybeasts@...il.com, pmoore@...hat.com,
	corbet@....net, eric.dumazet@...il.com, markus@...omium.org,
	coreyb@...ux.vnet.ibm.com
Subject: Re: [PATCH v12 01/13] sk_run_filter: add support for custom
 load_pointer

On Fri, March 2, 2012 02:19, Andrew Morton wrote:
> That assumes that we're going to merge this stuff into 3.4 - if we
> don't, unwrecker gets rewrecked and grumpy.
>
> I don't know if we're going to merge it into 3.4?  I haven't been
> paying a lot of attention and haven't looked at the patches in a while.

I think it should be merged, but I think 3.5 is probably better.

This because we haven't heard anything from the networking people
about the BPF changes, and I'm also unsure if the current approach
is the best one: It both increases the filter.o size significantly
while slowing down sk_run_filter, while the point was to avoid both.
I'm trying to think of an alternative approach with lower impact.

The ptrace integration may need some more time to settle too, even
just to make sure the latest version does what needs to be done.

Both directly affect the user space ABI, so I think it's best to
not be too hasty with pushing this upstream. Waiting one release
while having a stable final patch gives people the chance to go
and try to use it for their purposes and thus both test the code
more and get experience with the ABI.

Greetings,

Indan

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