linux-kernel - Re: [PATCH v2 04/10] um: Turn signals

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: <20250912132753.2651038-1-tiwei.bie@linux.dev>
Date: Fri, 12 Sep 2025 21:27:53 +0800
From: Tiwei Bie <tiwei.bie@...ux.dev>
To: benjamin@...solutions.net
Cc: richard@....at,
	anton.ivanov@...bridgegreys.com,
	johannes@...solutions.net,
	arnd@...db.de,
	linux-um@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	tiwei.btw@...group.com,
	tiwei.bie@...ux.dev
Subject: Re: [PATCH v2 04/10] um: Turn signals_* into thread-local variables

On Fri, 12 Sep 2025 09:58:49 +0200, Benjamin Berg wrote:
> On Fri, 2025-09-12 at 08:30 +0800, Tiwei Bie wrote:
> > On Thu, 11 Sep 2025 10:06:53 +0200, Benjamin Berg wrote:
> > 
> > > [SNIP]
> > > That said, I do believe that the allocations from the libc itself are
> > > problematic. A lot of the mappings from UML are there already (i.e. the
> > > physical memory is mapped). However, I believe the vmalloc area for
> > > example is not guarded.
> > > 
> > > So when pthread allocates the thread specific memory (stack, TLS, ...),
> > > we really do not know where this will be mapped into the address space.
> > > If it happens to be in an area that UML wants to use later, then UML
> > > could map e.g. vmalloc data over it.
> > > 
> > > Now, it could be that (currently) the addresses picked by pthread (or
> > > the host kernel) do not actually clash with anything. However, I do not
> > > think there is any guarantee for that.
> > 
> > Indeed. The mmap from libc (pthread, shared libs, ...) can potentially
> > conflict with UML. The reason it has been working on x86_64 so far might
> > be that we did this in linux_main():
> > 
> > 	task_size = task_size & PGDIR_MASK;
> > 
> > The current layout is:
> > 
> > shared libs and pthreads are located at 7ffxxxxxxxxx
> > TASK_SIZE                             = 7f8000000000
> > VMALLOC_END                           = 7f7fffffe000 (which is TASK_SIZE-2*PAGE_SIZE)
> 
> Uh, right, yes. Because of the masking we are capping ourselves to
> 0x7f8000000000. And then all of the interesting bits (vdso, ...) happen
> to be mapped above that address and are effectively protected. And,
> there is also plenty of space for other allocations technically.
> 
> That is kind of horrible, as it only works because all of this happens
> to be mapped into the top of the address space.

+1.

> But, maybe something to
> just wilfully ignore and only fix as part of a nolibc port?

Sure. Thanks!

Regards,
Tiwei