Re: fsl_udc_core: BUG: scheduling while atomic

2011-05-13 Thread Sergej.Stepanov
I would say it is a general problem by using CONFIG_PREEMPT_VOLUNTARY, not only Freescale... Am Donnerstag, den 12.05.2011, 11:30 -0400 schrieb Matthew L. Creech: On Thu, May 12, 2011 at 4:37 AM, sergej.stepa...@ids.de wrote: Hi Mattheew, such oops you can get also with spi. For such

RE: [linuxppc-release] [PATCH 1/2] powerpc, e5500: add networking to defconfig

2011-05-13 Thread Li Yang-R58472
Subject: Re: [linuxppc-release] [PATCH 1/2] powerpc, e5500: add networking to defconfig On Thu, 12 May 2011 10:31:08 -0500 Scott Wood scottw...@freescale.com wrote: On Thu, 12 May 2011 01:11:03 -0500 Li Yang-R58472 r58...@freescale.com wrote: diff --git

[PATHC] Fix for Pegasos keyboard and mouse

2011-05-13 Thread Gabriel Paubert
[See http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-October/086424.html and followups. Part of the commit message is directly copied from that.] Commit 540c6c392f01887dcc96bef0a41e63e6c1334f01 tries to find i8042 IRQs in the device-tree but doesn't fall back to the old hardcoded 1 and 12 in

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Ingo Molnar
* Peter Zijlstra pet...@infradead.org wrote: On Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote: err = event_vfs_getname(result); I really think we should not do this. Events like we have them should be inactive, totally passive entities, only observe but not affect execution

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Peter Zijlstra
On Fri, 2011-05-13 at 14:26 +0200, Ingo Molnar wrote: * Peter Zijlstra pet...@infradead.org wrote: On Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote: err = event_vfs_getname(result); I really think we should not do this. Events like we have them should be inactive,

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Peter Zijlstra
On Fri, 2011-05-13 at 14:39 +0200, Peter Zijlstra wrote: event_vfs_getname(result); result = check_event_vfs_getname(result); Another fundamental difference is how to treat the callback chains for these two. Observers won't have a return value and are assumed to never fail,

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Ingo Molnar
* Peter Zijlstra pet...@infradead.org wrote: Why should we have two callbacks next to each other: event_vfs_getname(result); result = check_event_vfs_getname(result); if one could do it all? Did you actually read the bit where I said that check_event_* (although I still

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Ingo Molnar
* Peter Zijlstra pet...@infradead.org wrote: On Fri, 2011-05-13 at 14:39 +0200, Peter Zijlstra wrote: event_vfs_getname(result); result = check_event_vfs_getname(result); Another fundamental difference is how to treat the callback chains for these two. Observers

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Peter Zijlstra
On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote: I think the sanest semantics is to run all active callbacks as well. For example if this is used for three stacked security policies - as if 3 LSM modules were stacked at once. We'd call all three, and we'd determine that at least one

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Ingo Molnar
* Peter Zijlstra pet...@infradead.org wrote: On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote: I think the sanest semantics is to run all active callbacks as well. For example if this is used for three stacked security policies - as if 3 LSM modules were stacked at once. We'd

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Peter Zijlstra
On Fri, 2011-05-13 at 14:49 +0200, Ingo Molnar wrote: So given that by your own admission it makes sense to share the facilities at the low level, i also argue that it makes sense to share as high up as possible. I'm not saying any such thing, I'm saying that it might make sense to

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Peter Zijlstra
Cut the microblaze list since its bouncy. On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote: * Peter Zijlstra pet...@infradead.org wrote: On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote: I think the sanest semantics is to run all active callbacks as well. For example if

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Ingo Molnar
* Peter Zijlstra pet...@infradead.org wrote: Cut the microblaze list since its bouncy. On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote: * Peter Zijlstra pet...@infradead.org wrote: On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote: I think the sanest semantics is to run

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Ingo Molnar
* Peter Zijlstra pet...@infradead.org wrote: On Fri, 2011-05-13 at 14:49 +0200, Ingo Molnar wrote: So given that by your own admission it makes sense to share the facilities at the low level, i also argue that it makes sense to share as high up as possible. I'm not saying any

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Eric Paris
[dropping microblaze and roland] lOn Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote: * James Morris jmor...@namei.org 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 other files is allowed.

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Eric Paris
[dropping microblaze and roland] On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote: * Peter Zijlstra pet...@infradead.org wrote: On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote: I think the sanest semantics is to run all active callbacks as well. For example if this is used

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Peter Zijlstra
On Fri, 2011-05-13 at 11:10 -0400, Eric Paris wrote: Then again, I certainly don't see a reason that this syscall hardening patch should be held up while a whole new concept in computer security is contemplated... Which makes me wonder why this syscall hardening stuff is done outside of LSM?

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Peter Zijlstra
On Fri, 2011-05-13 at 16:57 +0200, Ingo Molnar wrote: this is a security mechanism Who says? and why would you want to unify two separate concepts only to them limit it to security that just doesn't make sense. Either you provide a full on replacement for notifier chain like things or you

RE: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system callfiltering

2011-05-13 Thread David Laight
... If you can be completely stateless its easier, but there's a reason that stacking security modules is hard. Serge has tried in the past and both dhowells and casey schaufler are working on it right now. Stacking is never as easy as it sounds :) For a bad example of trying to allow

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Ingo Molnar
* James Morris jmor...@namei.org wrote: On Thu, 12 May 2011, Ingo Molnar wrote: Funnily enough, back then you wrote this: I'm concerned that we're seeing yet another security scheme being designed on the fly, without a well-formed threat model, and without taking into

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Eric Paris
On Fri, 2011-05-13 at 17:23 +0200, Peter Zijlstra wrote: On Fri, 2011-05-13 at 11:10 -0400, Eric Paris wrote: Then again, I certainly don't see a reason that this syscall hardening patch should be held up while a whole new concept in computer security is contemplated... Which makes me

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-13 Thread Will Drewry
On Fri, May 13, 2011 at 10:55 AM, Eric Paris epa...@redhat.com wrote: On Fri, 2011-05-13 at 17:23 +0200, Peter Zijlstra wrote: On Fri, 2011-05-13 at 11:10 -0400, Eric Paris wrote: Then again, I certainly don't see a reason that this syscall hardening patch should be held up while a whole