On Thu, May 30, 2013 at 10:28 AM, Eric Paris wrote:
>
> How do I tell what is taking time inside selinux_inode_permission?
Go to "annotate" (just press 'a' when the function is highlighted),
which will show you the disassembly and the cost of each instruction.
That's when you really want to use
On Sat, May 25, 2013 at 10:19 PM, Linus Torvalds
wrote:
> On Sat, May 25, 2013 at 10:04 PM, James Morris wrote:
>> On Sat, 25 May 2013, Linus Torvalds wrote:
>>
>>> But I haven't even looked at what non-selinux setups do to
>>> performance. Last time I tried Ubuntu (they still use apparmor, no?),
On Sun, 26 May 2013 08:02:51 -0400, "Theodore Ts'o" said:
> Have any of the arguments over the proper security models changed over
> or have gotten resolved over the past six years, while I haven't been
> looking?
Doubtful, because the security models are addressing different threat
models. If y
On 5/26/2013 12:32 PM, Linus Torvalds wrote:
> On Sun, May 26, 2013 at 12:11 PM, Theodore Ts'o wrote:
>> And if we can't rip out that fundamental assumption, it's not obvious
>> to me it will be possible to simplify the core LSM architecture.
> One thing that may be sufficient is to maintain a com
On Sun, May 26, 2013 at 12:11 PM, Theodore Ts'o wrote:
>
> And if we can't rip out that fundamental assumption, it's not obvious
> to me it will be possible to simplify the core LSM architecture.
One thing that may be sufficient is to maintain a complex model as a
*possible* case, but make sure t
On Sun, May 26, 2013 at 11:23:01AM -0700, Casey Schaufler wrote:
> I believe that Yama points to a serious change in the way
> "operating systems" are being developed. The desktop is not
> the sweet spot for Linux development, nor is the enterprise
> server. Six years ago the Bell & LaPadula subjec
On 5/26/2013 11:17 AM, Linus Torvalds wrote:
> On Sun, May 26, 2013 at 10:59 AM, Casey Schaufler
> wrote:
>> The whole secid philosophy comes out of the need to keep security out
>> of other people's way. It has performance impact. Sure, SELinux
>> hashes lookups, but a blob pointer gets you right
On 5/26/2013 5:02 AM, Theodore Ts'o wrote:
> On Sat, May 25, 2013 at 11:33:46AM -0700, Casey Schaufler wrote:
>> Now I'll put on my Smack maintainer hat. Performance improvement is
>> always welcome, but I would rather see attention to performance of
>> the LSM architecture than SELinux specific ha
On Sun, May 26, 2013 at 10:59 AM, Casey Schaufler
wrote:
>
> The whole secid philosophy comes out of the need to keep security out
> of other people's way. It has performance impact. Sure, SELinux
> hashes lookups, but a blob pointer gets you right where you want to be.
> When we are constrained i
On 5/25/2013 10:19 PM, Linus Torvalds wrote:
> On Sat, May 25, 2013 at 10:04 PM, James Morris wrote:
>> On Sat, 25 May 2013, Linus Torvalds wrote:
>>
>>> But I haven't even looked at what non-selinux setups do to
>>> performance. Last time I tried Ubuntu (they still use apparmor, no?),
>>> "make m
On Sat, May 25, 2013 at 11:33:46AM -0700, Casey Schaufler wrote:
> Now I'll put on my Smack maintainer hat. Performance improvement is
> always welcome, but I would rather see attention to performance of
> the LSM architecture than SELinux specific hacks. The LSM blob
> pointer scheme is there so t
On Sat, May 25, 2013 at 10:04 PM, James Morris wrote:
> On Sat, 25 May 2013, Linus Torvalds wrote:
>
>> But I haven't even looked at what non-selinux setups do to
>> performance. Last time I tried Ubuntu (they still use apparmor, no?),
>> "make modules_install ; make install" didn't work for the k
On Sat, 25 May 2013, Linus Torvalds wrote:
> But I haven't even looked at what non-selinux setups do to
> performance. Last time I tried Ubuntu (they still use apparmor, no?),
> "make modules_install ; make install" didn't work for the kernel, and
> if the Ubuntu people don't want to support kerne
On Sat, 25 May 2013, Al Viro wrote:
> Well... The problem I see here is not even selinux per se - it's that
> "LSM stacking" insanity.
FWIW, I don't see a concrete rationale for merging this stacking work. That
doesn't mean there won't be one in the future, but I wouldn't let the idea
of a fu
On Sat, May 25, 2013 at 11:33 AM, Casey Schaufler
wrote:
>
> Now I'll put on my Smack maintainer hat. Performance improvement is
> always welcome, but I would rather see attention to performance of
> the LSM architecture than SELinux specific hacks.
I haven't seen huge issues with performance at
On 5/25/2013 9:57 AM, Al Viro wrote:
> On Fri, May 24, 2013 at 08:21:08PM -0700, Linus Torvalds wrote:
>> On Tue, May 21, 2013 at 3:22 PM, Linus Torvalds
>> wrote:
>>> Untested patch attached. It compiles cleanly, looks sane, and most of
>>> it is just making the function prototypes look much nice
On Sat, May 25, 2013 at 9:57 AM, Al Viro wrote:
>
> Well... The problem I see here is not even selinux per se - it's that
> "LSM stacking" insanity. How would your anon union deal with that? Which
> LSM gets to play with it when we have more than one of those turds around?
We don't support st
On Fri, May 24, 2013 at 08:21:08PM -0700, Linus Torvalds wrote:
> On Tue, May 21, 2013 at 3:22 PM, Linus Torvalds
> wrote:
> >
> > Untested patch attached. It compiles cleanly, looks sane, and most of
> > it is just making the function prototypes look much nicer. I think it
> > works.
>
> Ok, her
On Tue, May 21, 2013 at 3:22 PM, Linus Torvalds
wrote:
>
> Untested patch attached. It compiles cleanly, looks sane, and most of
> it is just making the function prototypes look much nicer. I think it
> works.
Ok, here's another patch in the "let's make the VFS go faster series".
This one, sadly,
On Tue, May 21, 2013 at 3:34 PM, Al Viro wrote:
>
> In principle, yes, but... I wonder if those two cases are actually
> safe (especially ncpfs) right now.
Now I can agree that that may well be an issue.
I don't think my patch makes anything worse (because if the inode
isn't stable, we could ha
On Tue, May 21, 2013 at 03:22:44PM -0700, Linus Torvalds wrote:
> The *one* insane exception is ncpfs, which actually wants to look at
> the parent (ie directory) inode data in order to decide if it should
> use a case sensitive hash or not. However, even in that case, I'd
> argue that we could jus
Ok, Al, please tell me why I'm wrong, but I was looking at the hot
code in fs/dcache.c again (__d_lookup_rcu() remains the hottest
function under pathname lookup heavy operations) and that "inode"
argument was mis-commented (it used to be an in-out argument long long
ago) and it just kept bugging m
22 matches
Mail list logo
