<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/arch/um/os-Linux/helper.c, branch linux-rolling-stable</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2025-03-20T08:26:38Z</updated>
<entry>
<title>um: Prohibit the VM_CLONE flag in run_helper_thread()</title>
<updated>2025-03-20T08:26:38Z</updated>
<author>
<name>Tiwei Bie</name>
<email>tiwei.btw@antgroup.com</email>
</author>
<published>2025-03-19T13:55:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=69f52573c24de9d2919f83e3b3b396a09118b7c4'/>
<id>urn:sha1:69f52573c24de9d2919f83e3b3b396a09118b7c4</id>
<content type='text'>
Directly creating helper threads with VM_CLONE using clone can
compromise the thread safety of errno. Since all these helper
threads have been converted to use os_run_helper_thread(), let's
prevent using this flag in run_helper_thread().

Signed-off-by: Tiwei Bie &lt;tiwei.btw@antgroup.com&gt;
Link: https://patch.msgid.link/20250319135523.97050-5-tiwei.btw@antgroup.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>um: Add pthread-based helper support</title>
<updated>2025-03-20T08:26:38Z</updated>
<author>
<name>Tiwei Bie</name>
<email>tiwei.btw@antgroup.com</email>
</author>
<published>2025-03-19T13:55:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4f087eafdcef24b7160b097ddb9704084767b77a'/>
<id>urn:sha1:4f087eafdcef24b7160b097ddb9704084767b77a</id>
<content type='text'>
Introduce a new set of utility functions that can be used to create
pthread-based helpers. Helper threads created in this way will ensure
thread safety for errno while sharing the same memory space.

Signed-off-by: Tiwei Bie &lt;tiwei.btw@antgroup.com&gt;
Link: https://patch.msgid.link/20250319135523.97050-2-tiwei.btw@antgroup.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>um: Fix naming clash between UML and scheduler</title>
<updated>2024-01-04T20:22:27Z</updated>
<author>
<name>Anton Ivanov</name>
<email>anton.ivanov@cambridgegreys.com</email>
</author>
<published>2023-09-21T14:34:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=541d4e4d435c8b9bfd29f70a1da4a2db97794e0a'/>
<id>urn:sha1:541d4e4d435c8b9bfd29f70a1da4a2db97794e0a</id>
<content type='text'>
__cant_sleep was already used and exported by the scheduler.
The name had to be changed to a UML specific one.

Signed-off-by: Anton Ivanov &lt;anton.ivanov@cambridgegreys.com&gt;
Reviewed-by: Peter Lafreniere &lt;peter@n8pjl.ca&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>um: run_helper: Write error message to kernel log on exec failure on host</title>
<updated>2022-03-11T09:56:17Z</updated>
<author>
<name>Glenn Washburn</name>
<email>development@efficientek.com</email>
</author>
<published>2022-03-03T07:53:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=82017457957a550d7d00dde419435dd74a890887'/>
<id>urn:sha1:82017457957a550d7d00dde419435dd74a890887</id>
<content type='text'>
The best place to log errors from the host side is in the kernel log within
the UML guest. Letting the user now that exec() failed and why is very
helpful when the user is trying to determine why some aspect of UML is not
working. For instance, when telneting into the UML instance, if the
connection is established and then immediately dropped, this may be due to
exec() failing because in.telnetd is not found.

Signed-off-by: Glenn Washburn &lt;development@efficientek.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>um: Fix stack pointer alignment</title>
<updated>2021-06-17T20:08:31Z</updated>
<author>
<name>YiFei Zhu</name>
<email>zhuyifei1999@gmail.com</email>
</author>
<published>2021-04-20T05:56:10Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=558f9b2f94dbd2d5c5c8292aa13e081cc11ea7d9'/>
<id>urn:sha1:558f9b2f94dbd2d5c5c8292aa13e081cc11ea7d9</id>
<content type='text'>
GCC assumes that stack is aligned to 16-byte on call sites [1].
Since GCC 8, GCC began using 16-byte aligned SSE instructions to
implement assignments to structs on stack. When
CC_OPTIMIZE_FOR_PERFORMANCE is enabled, this affects
os-Linux/sigio.c, write_sigio_thread:

  struct pollfds *fds, tmp;
  tmp = current_poll;

Note that struct pollfds is exactly 16 bytes in size.
GCC 8+ generates assembly similar to:

  movdqa (%rdi),%xmm0
  movaps %xmm0,-0x50(%rbp)

This is an issue, because movaps will #GP if -0x50(%rbp) is not
aligned to 16 bytes [2], and how rbp gets assigned to is via glibc
clone thread_start, then function prologue, going though execution
trace similar to (showing only relevant instructions):

  sub    $0x10,%rsi
  mov    %rcx,0x8(%rsi)
  mov    %rdi,(%rsi)
  syscall
  pop    %rax
  pop    %rdi
  callq  *%rax
  push   %rbp
  mov    %rsp,%rbp

The stack pointer always points to the topmost element on stack,
rather then the space right above the topmost. On push, the
pointer decrements first before writing to the memory pointed to
by it. Therefore, there is no need to have the stack pointer
pointer always point to valid memory unless the stack is poped;
so the `- sizeof(void *)` in the code is unnecessary.

On the other hand, glibc reserves the 16 bytes it needs on stack
and pops itself, so by the call instruction the stack pointer
is exactly the caller-supplied sp. It then push the 16 bytes of
the return address and the saved stack pointer, so the base
pointer will be 16-byte aligned if and only if the caller
supplied sp is 16-byte aligned. Therefore, the caller must supply
a 16-byte aligned pointer, which `stack + UM_KERN_PAGE_SIZE`
already satisfies.

On a side note, musl is unaffected by this issue because it forces
16 byte alignment via `and $-16,%rsi` in its clone wrapper.
Similarly, glibc i386 is also unaffected because it has
`andl $0xfffffff0, %ecx`.

To reproduce this bug, enable CONFIG_UML_RTC and
CC_OPTIMIZE_FOR_PERFORMANCE. uml_rtc will call
add_sigio_fd which will then cause write_sigio_thread to either go
into segfault loop or panic with "Segfault with no mm".

Similarly, signal stacks will be aligned by the host kernel upon
signal delivery. `- sizeof(void *)` to sigaltstack is
unconventional and extraneous.

On a related note, initialization of longjmp buffers do require
`- sizeof(void *)`. This is to account for the return address
that would have been pushed to the stack at the call site.

The reason for uml to respect 16-byte alignment, rather than
telling GCC to assume 8-byte alignment like the host kernel since
commit d9b0cde91c60 ("x86-64, gcc: Use
-mpreferred-stack-boundary=3 if supported"), is because uml links
against libc. There is no reason to assume libc is also compiled
with that flag and assumes 8-byte alignment rather than 16-byte.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[2] https://c9x.me/x86/html/file_module_x86_id_180.html

Signed-off-by: YiFei Zhu &lt;zhuyifei1999@gmail.com&gt;
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>Revert "um: allocate a guard page to helper threads"</title>
<updated>2021-01-26T21:11:38Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2021-01-10T18:05:08Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2fcb4090cd7352665ecb756990a3087bfd86a295'/>
<id>urn:sha1:2fcb4090cd7352665ecb756990a3087bfd86a295</id>
<content type='text'>
This reverts commit ef4459a6da09 ("um: allocate a guard page to
helper threads"), it's broken in multiple ways:

 1) the free no longer matches the alloc; and

 2) more importantly, the set_memory_ro() causes allocation of
    page tables for the normal memory that doesn't have any,
    and that later causes corruption and crashes (usually but
    not always in vfree()).

We could fix the first bug and use vmalloc() to work around the
second, but set_memory_ro() actually doesn't do anything either
so I'll just revert that as well.

Reported-by: Benjamin Berg &lt;benjamin@sipsolutions.net&gt;
Fixes: ef4459a6da09 ("um: allocate a guard page to helper threads")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>um: allocate a guard page to helper threads</title>
<updated>2020-12-13T21:38:06Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2020-12-05T20:50:18Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ef4459a6da0955b533ebfc97a7d756ac090f50c9'/>
<id>urn:sha1:ef4459a6da0955b533ebfc97a7d756ac090f50c9</id>
<content type='text'>
We've been running into stack overflows in helper threads
corrupting memory (e.g. because somebody put printf() or
os_info() there), so to avoid those causing hard-to-debug
issues later on, allocate a guard page for helper thread
stacks and mark it read-only.

Unfortunately, the crash dump at that point is useless as
the stack tracer will try to backtrace the *kernel* thread,
not the helper thread, but at least we don't survive to a
random issue caused by corruption.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>um: Add SPDX headers for files in arch/um/os-Linux</title>
<updated>2019-09-15T19:37:17Z</updated>
<author>
<name>Alex Dewar</name>
<email>alex.dewar@gmx.co.uk</email>
</author>
<published>2019-08-25T09:49:18Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=97870c34b453251cda9c2341f8534b78003a74dc'/>
<id>urn:sha1:97870c34b453251cda9c2341f8534b78003a74dc</id>
<content type='text'>
Convert files to use SPDX header. All files are licensed under the GPLv2.

Signed-off-by: Alex Dewar &lt;alex.dewar@gmx.co.uk&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>um: Fix waitpid() usage in helper code</title>
<updated>2015-10-19T20:53:37Z</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2015-08-09T19:49:07Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6b1873371cea13036171d03a7c1e3e59158b4505'/>
<id>urn:sha1:6b1873371cea13036171d03a7c1e3e59158b4505</id>
<content type='text'>
If UML is executing a helper program it is using
waitpid() with the __WCLONE flag to wait for the program
as the helper is executed from a clone()'ed thread.
While using __WCLONE is perfectly fine for clone()'ed
childs it won't detect terminated childs if the helper
has issued an execve().

We have to use __WALL to wait for both clone()'ed and
regular childs to detect the termination before and
after an execve().

Reported-and-tested-by: Thomas Meyer &lt;thomas@m3y3r.de&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>um: get rid of pointless include "..." where include &lt;...&gt; will do</title>
<updated>2012-10-09T20:28:45Z</updated>
<author>
<name>Al Viro</name>
<email>viro@ZenIV.linux.org.uk</email>
</author>
<published>2012-10-08T02:27:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=37185b33240870719b6b5913a46e6a441f1ae96f'/>
<id>urn:sha1:37185b33240870719b6b5913a46e6a441f1ae96f</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
</feed>
