linux-kernel - Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp

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]

Date:	Fri, 1 Jul 2011 07:56:37 -0500
From:	Will Drewry <wad@...omium.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	James Morris <jmorris@...ei.org>,
	Chris Evans <scarybeasts@...il.com>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	djm@...drot.org, segoon@...nwall.com, kees.cook@...onical.com,
	rostedt@...dmis.org, fweisbec@...il.com, tglx@...utronix.de,
	Randy Dunlap <rdunlap@...otime.net>, linux-doc@...r.kernel.org,
	Eric Paris <eparis@...hat.com>,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is
 and how it works.

On Fri, Jul 1, 2011 at 6:56 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * James Morris <jmorris@...ei.org> wrote:
>
>> On Wed, 29 Jun 2011, Will Drewry wrote:
>>
>> > Since it seems that there'll be consumers (openssh, vsftpd,
>> > kvm/qemu, chromium, chromium os) and feedback quieted down, what
>> > are the next steps to get this to a pull/no-pull decision points
>> > (or at least some Ack's or Nack's)?  I know this patch series
>> > crosses a number of maintainers, and I never know exactly what's
>> > next when the feedback slows down.
>>
>> Are there any outstanding objections to this approach?  How do the
>> tracing folk feel about it?
>
> I think i outlined my objections a couple of times and haven't seen
> them addressed.

After our last discussion, I suggested changes which I then undertook
and reposted.  Those changes have been posted for over two weeks.
I've continued to resolve any bugs with the patches and keep them
rebased.

Is it just that you will not accept the prctl()-based approach?  If
that's the case, I'm confused as it doesn't seem like there was
support for a perf-based change or a change that was more fundamental.

If you would re-outline the places where it falls down, that would be
useful.  If it is just that you do not think we can reach agreement,
that would be useful to know as well.

thanks,
will
--
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/