linux-kernel - Re: [PATCH v2 00/11] Start porting UML to nolibc

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <m2y0q47mbs.wl-thehajime@gmail.com>
Date: Wed, 24 Sep 2025 08:58:47 +0900
From: Hajime Tazaki <thehajime@...il.com>
To: johannes@...solutions.net
Cc: hch@...radead.org,
	benjamin@...solutions.net,
	linux-um@...ts.infradead.org,
	w@....eu,
	linux@...ssschuh.net,
	linux-kselftest@...r.kernel.org,
	acme@...hat.com,
	linux-kernel@...r.kernel.org,
	benjamin.berg@...el.com
Subject: Re: [PATCH v2 00/11] Start porting UML to nolibc


Hello Benjamin, Johannes,

On Mon, 22 Sep 2025 16:41:36 +0900,
Johannes Berg wrote:
> 
> On Fri, 2025-09-19 at 08:40 -0700, Christoph Hellwig wrote:
> > On Fri, Sep 19, 2025 at 05:34:09PM +0200, Benjamin Berg wrote:
> > > From: Benjamin Berg <benjamin.berg@...el.com>
> > > 
> > > This patchset is an attempt to start a nolibc port of UML.
> > 
> > It would be useful to explain why that is desirable.
> 
> Agree, it should be here, but FWIW it's been discussed elsewhere on the
> linux-um list in the past and basically there are various issues around
> it. Off the top of my head:
>  - glibc enabling new features such as rseq that interact badly with how
>    UML manages memory (there were fixes for this, it worked sometimes
>    and sometimes not)
>  - allocation placement for TLS is problematic (see the SMP series)
>  - it's (too) easy to accidentally call glibc functions that require
>    huge amounts of stack space
> 
> There are probably other reasons, but the mixed nature of UML being both
> kernel and "hypervisor" code in a single place doesn't mix well with
> glibc.

just curious

- are those issues not happening in other libc implementation ? (e.g.,
  musl-libc)
- same question to nolibc: is there any possibility that nolibc will
  evolve as glibc does, and this evolution introduces the UML issues ?

-- Hajime