On Fri, May 13, 2011 at 10:55 AM, Eric Paris 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
>> > new con
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 ma
* James Morris 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
> > account
> ... 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 a
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 don't
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
[dropping microblaze and roland]
On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote:
> * Peter Zijlstra 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 thr
[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 other files is
> allowed.
It's simple en
* Peter Zijlstra 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 such thi
* Peter Zijlstra wrote:
> Cut the microblaze list since its bouncy.
>
> On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote:
> > * Peter Zijlstra 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
Cut the microblaze list since its bouncy.
On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote:
> * Peter Zijlstra 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 use
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
obs
* Peter Zijlstra 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 call all th
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 o
* Peter Zijlstra 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 won't have
* Peter Zijlstra 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 think
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
On Fri, 2011-05-13 at 14:26 +0200, Ingo Molnar wrote:
> * Peter Zijlstra 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 passi
* Peter Zijlstra 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
> (other than t
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 (other than the bare minimal time delay introduced by
[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 a
>Subject: Re: [linuxppc-release] [PATCH 1/2] powerpc, e5500: add networking
>to defconfig
>
>On Thu, 12 May 2011 10:31:08 -0500
>Scott Wood wrote:
>
>> On Thu, 12 May 2011 01:11:03 -0500
>> Li Yang-R58472 wrote:
>>
>> > >diff --git a/arch/powerpc/configs/e55xx_smp_defconfig
>> > >b/arch/powerpc/c
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, wrote:
> > Hi Mattheew,
> >
> > such oops you can get also with spi.
> > For such problem helps to
23 matches
Mail list logo
