user-mode-linux-devel

1) From 9 to 18 July, I'll be away for study - so I won't be able to
participate in the UML development. Sadly, after coming back I'll be far away
from Internet, after a short time; however I think I'll be able to do
something before starting again (and while away I'll have my new laptop, so
I'll have plenty of time for coding).
2) Especially, I'm near to fixing the host SKAS leak... seems like it's a race
condition when calling alloc_ldt(): one of the two values is overwritten by
the other, and so never freed. In fact for each mm init_new_context() is
called when open()ing it, while __init_new_context() is called when writing a
MM_COPY_SEGMENTS request onto /proc/mm (which happens shortly after).
The mm->context is not locked anyway, and this is a SKAS bug: it makes sense
in mainline, but not when using SKAS. The strange thing is that on
host/kernel configurations where it happens, it is repeatable, i.e. does not
seem a race condition. However the locking must be anyway added.
Bye
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

Alle 18:04, gioved=EC 8 luglio 2004, BlaisorBlade ha scritto:
> 1) From 9 to 18 July, I'll be away for study=20
Ok, I'm back. And glad to see the release of 2.4.26-2um.
> 2) Especially, I'm near to fixing the host SKAS leak... seems like it's a
> race condition when calling alloc_ldt(): one of the two values is
> overwritten by the other, and so never freed. In fact for each mm
> init_new_context() is called when open()ing it, while __init_new_context()
> is called when writing a MM_COPY_SEGMENTS request onto /proc/mm (which
> happens shortly after). The mm->context is not locked anyway, and this is=
a
> SKAS bug: it makes sense in mainline, but not when using SKAS. The strange
> thing is that on host/kernel configurations where it happens, it is
> repeatable, i.e. does not seem a race condition. However the locking must
> be anyway added.
I've attached the patch, but I've not had time to even compile one kernel w=
ith=20
it. However try it if you want: it's for 2.6 and probably works for 2.4.
Ok, the problem is the double call, but it is not a race condition: when=20
calling again __init_new_context, we do mm->context.size =3D 0, so alloc_ld=
t=20
does not free mm->context.ldt. Much simpler. While the race condition is=20
impossible (it is the same thread to open /proc/mm and to write the=20
MM_COPY_SEGMENTS request).
And it did not happen before 2.4.25 because there was no clearing of=20
mm->context.size (it did not exist). There is another strange thing: why th=
e=20
leak does not happen everywhere? To actually have an LDT to allocate, the U=
ML=20
host thread calling new_mm() must have an LDT with size !=3D 0, which will =
then=20
be inherited by every UML thread: I do not think this is nice, and it's=20
unwanted since UML assumes that a kernel thread has not an LDT, see the=20
current->mm !=3D NULL check in new_mm(); I think this can only come from gl=
ibc=20
(for instance to support TLS).
Anyway, that is the problem. And the locking is not the solution (deadlock=
=20
risk): simply it does not make sense to call twice init_new_context(),=20
because after the first time the context is old. I've avoided to add lockin=
g=20
because I fear deadlocks (I would need to lock both the old and the new=20
context) and because the old code worked fine without adding locks; anyway,=
=20
there is no chance that a proper UML can cause a race onto the new LDT; but=
=20
if a process wants to, it can. The fix would be very simple: lock the old=20
context, copy its LDT to a bounce buffer, unlock it, and copy the bounce=20
buffer to the new context under locking; but I don't like this. Maybe it=20
could be deadlock-free to take the old_mm lock and after the new_mm one (it=
's=20
impossible that another process does the reverse copy, or not?)
Bye
=2D-=20
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

Sorry for the patch: the new one should make more sense (it compiles, but be
careful with it). Anyway, you can still wait for it, for now...
Bye
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details