* Peter Zijlstra wrote:
> On Fri, 2011-05-13 at 16:57 +0200, Ingo Molnar wrote:
> > this is a security mechanism
>
> Who says? [...]
Kernel developers/maintainers of the affected code.
We have security hooks all around the kernel, which can deny/accept execution
at various key points, but we
* Eric Paris wrote:
> [dropping microblaze and roland]
>
> lOn Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
> > * James Morris wrote:
>
> > It is a simple and sensible security feature, agreed? It allows most code
> > to
> > run well and link to countless libraries - but no access to
On Sat, May 14, 2011 at 2:30 AM, Ingo Molnar wrote:
>
> * Eric Paris wrote:
>
>> [dropping microblaze and roland]
>>
>> lOn Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
>> > * James Morris wrote:
>>
>> > It is a simple and sensible security feature, agreed? It allows most code
>> > to
>>
the current kernel source tree contains a Makefile reference to the
above Kconfig variable that doesn't appear to be defined anywhere.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
On Thursday 12 May 2011, Will Drewry wrote:
> This change adds a new seccomp mode based on the work by
> a...@chromium.org in [1]. This new mode, "filter mode", provides a hash
> table of seccomp_filter objects. When in the new mode (2), all system
> calls are checked against the filters - first b
On Fri, May 13, 2011 at 2:35 PM, Arnd Bergmann wrote:
> On Thursday 12 May 2011, Will Drewry wrote:
>> This change adds a new seccomp mode based on the work by
>> a...@chromium.org in [1]. This new mode, "filter mode", provides a hash
>> table of seccomp_filter objects. When in the new mode (2),
