linux-kernel - Re: [uml-devel] uml: pthreads instead of manual clone()?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <AANLkTilQfz-PfNf6ZTqguMKBsADghbK4pEBGVzpjSurm@mail.gmail.com>
Date:	Mon, 17 May 2010 16:41:25 +0200
From:	Paolo Giarrusso <p.giarrusso@...il.com>
To:	Jan Kiszka <jan.kiszka@....de>
Cc:	Jeff Dike <jdike@...toit.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	user-mode-linux-devel@...ts.sourceforge.net
Subject: Re: [uml-devel] uml: pthreads instead of manual clone()?

On Sun, Apr 18, 2010 at 19:50, Jan Kiszka <jan.kiszka@....de> wrote:
> Hi Jeff,
>
> is there (still) any reason to use explicit clone() instead of pthreads
> to spawn UML kernel threads?
>
> While playing with a patch to finally move os_nsecs to proper
> CLOCK_MONOTONIC, I noticed some subtle side-effect: We need to link
> against librt for clock_gettime, but that indirectly drags in
> libpthread. Now gdb gets unhappy when you try to debug the UML kernel.
> It assumes that pthreads are used, but fails to find their IDs and
> terminates the session. So the obvious approach appears to be converting
> kernel threads to pthreads - if there aren't any know pitfalls.

I think you should better manually copy the clock_gettime syscall stub
or function (hoping it's simple enough). Basically, we don't want
glibc to do anything by his own free will, like doing TLS setup
(pthread could do that), allocating memory from the heap on its own
(we only allow it very early, and we try to make it still safe - see
the malloc replacement stuff we do through linker and
__real_malloc/_whatever_I_dont_recall_malloc). We got a bug once we
called getpid() just to get a ptrace notification, but glibc cached
the getpid() result: we have our own getpid() syscall stub (at some
point I was writing actual UML code, and I wrote some TLS code myself
- not sure whether it's the current implementation or it was
rewritten).

Then, maybe, it can be made to work, even if I really wonder about the
TLS setup stuff - we need to allow the guest userspace programs to do
basically any [gs]et_thread_area() calls. But it's really untrivial
IMHO.
-- 
Paolo Giarrusso
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/