Re: [vserver] Vserver + grsec thoughts

From: Rik Bobbaers <rik_at_enzoverder.be>
Date: Mon 08 Nov 2010 - 13:02:09 GMT
Message-ID: <17326.193.178.209.214.1289221329.squirrel@www.enzoverder.be>

grep for "unchecked" in the kernel/verver subdirectory (of a vserver+grsec
patch that i made before)... that will give you a list of "unchecked"
atomic definitions, which means they don't cause a refcount overflow panic
in the kernel (if you enabled refcount checking). But as i said, i'm not
100% sure that 's pax-stuff.

grtz...

Rik Bobbaers

-- http://harry.enzoverder.be
linux/unix/system/network/security/hardware admin
infrastructure architect

> On 08/11/2010 09:24, Rik Bobbaers wrote:
>>
>> But... You will run into problems with a vs+pax patch when your
>> refcounters overflow (iirc that's a pax feature). So there is some
>> patching that needs to be done on some vserver related things. I'll try
>> to
>> upload a patch for that (on top of the linux + pax + vserver) patch.
>> This
>> way, you can easily "make new patches" if new versions of pax or vserver
>> come out. (it's definately not much... but check the refcount bugs in
>> the
>> mailinglist archives and you'll know what i'm talking about).
>
> Thanks Rik
>
> So far the only extra patch I have on 2.6.35 is pasted below. This
> solves a compile issue only. (Note that I see the write_locks are
> changed to spin_locks in the 2.6.36 patch.)
>
> However, I haven't *yet* found any ref count issues in the mailing
> list? I did find the thread subject: "Kernel bug in __sock_sendmsg",
> however, that's got quite a bit patch in it?
>
> What I did find was a discussion from Natanael Copa back in 2008
> suggesting we go pax+vserver only and your thoughts on the extra bits of
> grsec which are useful. I wonder if it would be worth pulling out some
> of the extra (simpler) bits of grsec into standalone patch - In an ideal
> world grsec team might even maintain it for us...
>
> Grateful if you can send over any fixes to pax+vserver as you get the time
>
> Cheers
>
> Ed W
>
>
> --- kernel/vserver/context.c.orig 2010-11-08 08:59:43.080799733 +0000
> +++ kernel/vserver/context.c 2010-11-08 10:57:28.192871022 +0000
> @@ -122,7 +122,7 @@
> // preconfig fs entries
> for (index = 0; index < VX_SPACES; index++) {
> write_lock(&init_fs.lock);
> - init_fs.users++;
> + atomic_inc(&init_fs.users);
> write_unlock(&init_fs.lock);
> new->vx_fs[index] = &init_fs;
> }
> @@ -197,7 +197,7 @@
>
> fs = xchg(&vxi->vx_fs[index], NULL);
> write_lock(&fs->lock);
> - kill = !--fs->users;
> + kill = atomic_dec_and_test(&fs->users);
> write_unlock(&fs->lock);
> if (kill)
> free_fs_struct(fs);
> --- kernel/vserver/space.c.orig 2010-11-08 08:59:43.084798404 +0000
> +++ kernel/vserver/space.c 2010-11-08 10:52:06.376871197 +0000
> @@ -220,7 +220,7 @@
> if (mask & CLONE_FS) {
> write_lock(&fs_cur->lock);
> current->fs = fs;
> - kill = !--fs_cur->users;
> + kill = atomic_dec_and_test(&fs_cur->users);
> write_unlock(&fs_cur->lock);
> }
>
> @@ -278,7 +278,7 @@
> if (mask & CLONE_FS) {
> write_lock(&fs_vxi->lock);
> vxi->vx_fs[index] = fs;
> - kill = !--fs_vxi->users;
> + kill = atomic_dec_and_test(&fs_vxi->users);
> write_unlock(&fs_vxi->lock);
> }
>
>
Received on Mon Nov 8 13:02:14 2010

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 08 Nov 2010 - 13:02:16 GMT by hypermail 2.1.8