lkml.org 
[lkml]   [2002]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] remove sys_security
From
   From: Greg KH <greg@kroah.com>
Date: Thu, 17 Oct 2002 13:36:52 -0700

> Are the LSM modules that exist now using portable types in the objects
> passed into sys_security? Note that pointers and things like "long"
> are not allowed as types, for example, those would need to be translated.

Yes, you are correct, they better be implemented properly, or they will
not work.

How am I supposed to know what the things are being passed in
via these opaque "unsigned long" parameters?

Could they be pointers? If so, game over already, and this needs
to be fixed NOW.

And (ignoring the network hooks) there is not a measurable overhead for
these hooks. We have documented this many times (OLS paper, USENIX
paper, etc.) With the patch I'm about to submit, disabling the option
makes them go away entirely.

Look at the code that gets output, look at the 32K of kernel image
I get even though I have no intention of _ever_ loading a security
module.

So if distribution makers enable CONFIG_SECURITY, EVERY USER eats
this 32K. That _SUCKS_.

And I severely contest your overhead argument, look at the assembler
code being output, the kernel parts where the hooks are placed are
different. Lots of places that used to be leaf functions are no
longer leaf functions due to the security_ops invocation being there
now. Register allocation is also going to be quite different
different.

In short, it's bloat, and if you refuse to realize that perhaps kernel
development is not your true calling in life :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.156 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site