FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 01-03-2012, 05:02 PM
 
Default aufs3.0 fails to emerge on Gentoo hardened and kernel 3.0.4

On 3 Jan 2012 at 18:34, Andrea Zuccherelli wrote:

> hfsnotify.c:208:2: error: assignment of read-only member 'br_hfsn_ops'
>
> I found this to be caused by grsecurity constify_plugin.
> So i tried to disable it using
> '-fplugin-arg-constify_plugin-no-constify' switch.

newer kernels have CONFIG_PAX_CONSTIFY_PLUGIN that let you control
constification .

also gentoo already carries a (now seemingly incomplete) fix but it
was written for the old (manual) ways of doing ops constification,
with the gcc plugin approach i think it'd be enough to use the special
noconst types (say, file_operations_no_const) in aufs.
 
Old 01-03-2012, 05:57 PM
 
Default aufs3.0 fails to emerge on Gentoo hardened and kernel 3.0.4

On 3 Jan 2012 at 20:47, Andrea Zuccherelli wrote:

please don't top post, it makes your responses hard to correlate to what
you're referring to. like right here:

> Ok, but this does not solve the gcc switch bug...

what does 'this' refer to'? if you meant CONFIG_PAX_CONSTIFY_PLUGIN then
there should be no gcc switch bug.

> Either I will have to wait for next hardened-gentoo kernel release and
> aufs3 ebuild mantainer to turn off constification,

the kernel .config is under your control, not theirs, so you can disable
it any time.

> a no_const patch for fsnotify_backend.c or a wise (how?) use of fsnotify struct by
> Okajima.

i think arekm's patch is fine, probably even better than what gentoo includes
now, so feel free to push it into gentoo as well.

> In any case developer work when if this switch would work it woud not be needed.
>
> PS: for the no_const patch found this for aufs3 on PLD Linux:
> http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/packages/kernel/kernel-aufs2-no-const-grsec.patch?revision=1.6&view=markup
 
Old 01-05-2012, 11:45 AM
 
Default aufs3.0 fails to emerge on Gentoo hardened and kernel 3.0.4

On 3 Jan 2012 at 22:10, Andrea Zuccherelli wrote:

> The switch I was referring to is
> '-fplugin-arg-constify_plugin-no-constify' gcc option.
> This should disable the constify_plugin but it is not checked on gcc
> callbacks when a 'no_const' attribute is found.

it doesn't exactly disable the plugin, it disables actually constifying
ops structures, but it still lets gcc understand the special attributes
introduced for this constification effort.

> Using the kernel option will turn off the plugin system wide.

that's because this is the only supported/meaningful way of using the plugin
(that's why modversion now depends on the plugin too).

> Using the gcc flag option willl turn it off only for this case.

and this will never work . consider that you compile your kernel with
constification enabled but some external module without it. now this external
module will believe that it has free reign over ops structures whereas the
kernel will happily enforce the read-only property on at least its own static
instances and may cause the external module to oops at runtime.

now if some code needs writable ops structure variables it has 3 options under
the plugin approach:

1. add __no_const to the structure declaration

2. typedef a __no_const version of the constified structure type

3. use pax_open_kernel/pax_close_kernel to temporarily override
the (runtime enforced) constness of a given variable

each approach has its own conditions to use, here's a quick summary:

1. when all instances of the given structure type are runtime allocated
(i.e., there're no static instances)

2. when some instances of the given structure type are statically allocated
it's best to let them be consitified by the plugin and use the typedef'd
__no_const type for dynamically allocated ones

3. when some constified statically allocated variables do need to be modified
at runtime

if you look at PaX carefully, you'll find use cases for each of the above,
it should be your guidance for patching aufs as well. although i didn't look
at its code, i think aufs is case #1 or #2.
 
Old 01-05-2012, 03:36 PM
 
Default aufs3.0 fails to emerge on Gentoo hardened and kernel 3.0.4

On 5 Jan 2012 at 17:21, Andrea Zuccherelli wrote:

> > now if some code needs writable ops structure variables it has 3 options under
> > the plugin approach:
> >
> > 1. add __no_const to the structure declaration
> >
> > 2. typedef a __no_const version of the constified structure type
> >
> > 3. use pax_open_kernel/pax_close_kernel to temporarily override
> > * the (runtime enforced) constness of a given variable
> >
> > each approach has its own conditions to use, here's a quick summary:
> >
> > 1. when all instances of the given structure type are runtime allocated
> > * (i.e., there're no static instances)
> >
> > 2. when some instances of the given structure type are statically allocated
> > * it's best to let them be consitified by the plugin and use the typedef'd
> > * __no_const type for dynamically allocated ones
> >
> > 3. when some constified statically allocated variables do need to be modified
> > * at runtime
> >
> > if you look at PaX carefully, you'll find use cases for each of the above,
> > it should be your guidance for patching aufs as well. although i didn't look
> > at its code, i think aufs is case #1 or #2.
> >
>
> I agree with option 1: types should be declared const or no_const
> As enforcing this should lead to a more robust kernel.
> And this means there should not be any constify_plugin trick to infer
> if a type is const or not.
> The compiler should require attribute declaration.
> But this is just utopia....

i think you misunderstood something . the above 3 cases are not something you
can agree/disagree with, they're cases that may or may not apply to a given piece
of code and depending on the exact situation you have 3 ways to adjust the code
to work with the constification plugin (it is also a valid/possible adjustment
to turn the code from one case to another, e.g., by getting rid of runtime ops
structure allocation, PaX has examples of this kind of change too, but i didn't
want to complicate my initial explanation .

so with that said, the constify plugin has to exist exactly because the kernel
has all kinds of ops structure types (as in, there're legitimate use cases for
each of the 3 situations) and we need the do_const/no_const attributes because
the compiler cannot in general determine how a given ops structure type is used
in the entire code base (with LTO it may be feasible though).

> The problem with option 2 is that this leaves the constification
> question unsolved.

i don't understand this...

> Beside that this forces developers to modify their code either to use
> "no_const" types or to write specific patches.

exactly. consider this as documenting the behaviour of the code. not unlike
you do every time you use 'const' or 'unsigned' or any attributes, etc.

> Looking at code I don't understand why, for example, grsecurity patch
> provides a "no_const" struct for seq_operations (in include/linux/seq_file.h)

it's simple, you'd have had to grep for seq_operations_no_const only
(hint: it's case #2).

> and no special "typedef" for "struct fsnotify_ops"...

because fsnotify_ops is not case #2 in the vanilla kernel but now you appear
to be saying that aufs makes it into case #2 (can you/anyone confirm it?) in
which case i'll add the typedef to PaX and aufs can rely on fsnotify_ops_no_const
from then on.

and if there's anything else, just let me know (obviously for ops structures
declared by aufs itself it's up to aufs to provide/use the typedefs, __no_const,
etc).

> This means I cannot support option 1 and then the best is to bypass
> compiler constification, using Okajima trick...
>
> //br->br_hfsn_ops = au_hfsn_ops;
> BUILD_BUG_ON(sizeof(br->br_hfsn_ops) != sizeof(au_hfsn_ops));
> memcoy((void *)&br->br_hfsn_ops, (void *)&au_hfsn_ops, sizeof(au_hfsn_ops));
>
> instead of the more clear:
>
> br->br_hfsn_ops = au_hfsn_ops;

you can keep using the simple code if you use the proper types .

> Is this going to work?

you/someone will have to determine which of the 3 cases you have in aufs (for
each affected type).

here, if 'br' points to a dynamically allocated structure (think kmalloc) then
it means that for this ops type you have case #1 or #2, so you'll either need
__no_const on the original declaration or a new typedef'ed no_const type.

> Aren't const struct enforced at runtime?

it depends on where the given object is stored. runtime enforcement normally
applies only to variables of static storage (i.e., variables declared in global
scope), local variables and dynamically allocated ones remain writable (as far
as the CPU is concerned, that's why cast tricks work there whereas they'd fail
at runtime if used against static variables). with some ugly hacks you could make
dynamically allocated objects read-only as well, but i don't know of anyone who
went that far yet.
 
Old 01-05-2012, 05:08 PM
 
Default aufs3.0 fails to emerge on Gentoo hardened and kernel 3.0.4

On 5 Jan 2012 at 19:13, Andrea Zuccherelli wrote:

> zrouter aufs # cat kernel-aufs3-no-const-grsec.patch
> --- /usr/src/linux/include/linux/fsnotify_backend.h
> +++ /usr/src/linux/include/linux/fsnotify_backend.h
> @@ -105,6 +105,7 @@ struct fsnotify_ops {
> void (*freeing_mark)(struct fsnotify_mark *mark, struct
> fsnotify_group *group);
> void (*free_event_priv)(struct fsnotify_event_private_data *priv);
> };
> +typedef struct fsnotify_ops __no_const fsnotify_ops_no_const;
>
> /*
> * A group is a "thing" that wants to receive notification about filesystem

i've added this to PaX now.

> --- fs/aufs/branch.h
> +++ fs/aufs/branch.h
> @@ -83,7 +83,7 @@ struct au_branch {
>
> #ifdef CONFIG_AUFS_HFSNOTIFY
> struct fsnotify_group *br_hfsn_group;
> - struct fsnotify_ops br_hfsn_ops;
> + fsnotify_ops_no_const br_hfsn_ops;
> #endif
>
> #ifdef CONFIG_SYSFS
>
>
> This should be integrated in Gentoo Hardened aufs3 ebuild, right?

for current/older versions yes, future ones will have the first chunk
in PaX itself. and maybe in some distant future the plugin will be smart
enough to figure this case out at compile time...

> If #1 could be confirmed then the patch would be in grsec,

both the __no_const and the new typedef would be in PaX in any case, aufs
would always only have to make use of the old/new types.

> but looking for fsnotify_ops use cases I have found only static const initializers
> (inotify for instance).

yes, that's why there was no extra no_const typedef for it so far, but now
there is. i could of course proactively add such typedefs to all otherwise
constified ops types but i'd rather not make my own life harder when it comes
to porting to a new version .
 

Thread Tools




All times are GMT. The time now is 12:12 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org