um: make stub compilation more robust

With clang, stub compilation could result in getting stack
frames where none are allowed, or ways of making it be not
relocatable. Set -ftrivial-auto-var-init=u

um: make stub compilation more robust

With clang, stub compilation could result in getting stack
frames where none are allowed, or ways of making it be not
relocatable. Set -ftrivial-auto-var-init=uninitialized for
more code, and -fomit-frame-pointer as well to avoid these
issues.

Link: https://patch.msgid.link/20260923173523.9cb03214335b.Ie1487657bc0f464f4911e95f532ab010b32864b8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

show more ...

um: nommu: add userspace runner processes

For NOMMU there are not separate address spaces for
each userspace process group, which on the one hand
means we cannot start them on demand, but on the
oth

um: nommu: add userspace runner processes

For NOMMU there are not separate address spaces for
each userspace process group, which on the one hand
means we cannot start them on demand, but on the
other means we can just have one for each (virtual)
CPU, and map all of the memory into them.

Implement such processes, and the remaining bits
needed to compile the kernel without CONFIG_MMU.

Link: https://patch.msgid.link/20260723113633.2184dce9413e.I9f810f3ed177d6dc980cad36c231f8c745dee48f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

show more ...

um: further decouple MMU related code

Since this approach shares more code with the MMU version
in nommu, further move some code around to be able to use
it in nommu (report_enomem) or be able to re

um: further decouple MMU related code

Since this approach shares more code with the MMU version
in nommu, further move some code around to be able to use
it in nommu (report_enomem) or be able to replace it (this
applies to mm_id, stack, sync). Also add empty inlines for
the TLB flushing and decouple trap.c code.

Link: https://patch.msgid.link/20260723113633.163686eb0863.Ibb7f37d5645cbd566ae5b74fbb19c54c7327ba68@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

show more ...

um: fix stub exe build with CONFIG_GCOV

CONFIG_GCOV is special and only in UML since it builds the
kernel with a "userspace" option. This is fine, but the stub
is even more special and not really a

um: fix stub exe build with CONFIG_GCOV

CONFIG_GCOV is special and only in UML since it builds the
kernel with a "userspace" option. This is fine, but the stub
is even more special and not really a full userspace process,
so it then fails to link as reported.

Remove the GCOV options from the stub build.

For good measure, also remove the GPROF options, even though
they don't seem to cause build failures now.

To be able to do this, export the specific options (GCOV_OPT
and GPROF_OPT) but rename them so there's less chance of any
conflicts.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202410242238.SXhs2kQ4-lkp@intel.com/
Fixes: 32e8eaf263d9 ("um: use execveat to create userspace MMs")
Link: https://patch.msgid.link/20241025102700.9fbb9c34473f.I7f1537fe075638f8da64beb52ef6c9e5adc51bc3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

show more ...

um: Disable auto variable initialization for stub_exe.c

When automatic variable initialization is enabled via
CONFIG_INIT_STACK_ALL_{PATTERN,ZERO}, clang will insert a call to
memset() to initialize

um: Disable auto variable initialization for stub_exe.c

When automatic variable initialization is enabled via
CONFIG_INIT_STACK_ALL_{PATTERN,ZERO}, clang will insert a call to
memset() to initialize an object created with __builtin_alloca(). This
ultimately breaks the build when linking stub_exe because it is a
standalone executable that does not include or link against memset().

ld: arch/um/kernel/skas/stub_exe.o: in function `_start':
arch/um/kernel/skas/stub_exe.c:83:(.ltext+0x15): undefined reference to `memset'

Disable automatic variable initialization for stub_exe.c by passing the
default value of 'uninitialized' to '-ftrivial-auto-var-init', which
avoids generating the call to memset(). This code is small and runs
quickly as it is just designed to set up an environment, so stack
variable initialization is unnecessary overhead for little gain.

Fixes: 32e8eaf263d9 ("um: use execveat to create userspace MMs")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20241016-uml-fix-stub_exe-clang-v1-2-3d6381dc5a78@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

show more ...

um: Fix passing '-n' to linker for stub_exe

When building stub_exe with clang, there is an error because '-n' is not
a recognized flag by the clang driver (which is being used to invoke the
linker):

um: Fix passing '-n' to linker for stub_exe

When building stub_exe with clang, there is an error because '-n' is not
a recognized flag by the clang driver (which is being used to invoke the
linker):

clang: error: unknown argument: '-n'

'-n' should be passed along to the linker, as it is the short flag for
'--nmagic', so prefix it with '-Wl,'.

Fixes: 32e8eaf263d9 ("um: use execveat to create userspace MMs")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20241016-uml-fix-stub_exe-clang-v1-1-3d6381dc5a78@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

show more ...

um: use execveat to create userspace MMs

Using clone will not undo features that have been enabled by libc. An
example of this already happening is rseq, which could cause the kernel
to read/write m

um: use execveat to create userspace MMs

Using clone will not undo features that have been enabled by libc. An
example of this already happening is rseq, which could cause the kernel
to read/write memory of the userspace process. In the future the
standard library might also use mseal by default to protect itself,
which would also thwart our attempts at unmapping everything.

Solve all this by taking a step back and doing an execve into a tiny
static binary that sets up the minimal environment required for the
stub without using any standard library. That way we have a clean
execution environment that is fully under the control of UML.

Note that this changes things a bit as the FDs are not anymore shared
with the kernel. Instead, we explicitly share the FDs for the physical
memory and all existing iomem regions. Doing this is fine, as iomem
regions cannot be added at runtime.

Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20240919124511.282088-3-benjamin@sipsolutions.net
[use pipe() instead of pipe2(), remove unneeded close() calls]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

show more ...

um: remove copy_context_skas0

The kernel flushes the memory ranges anyway for CoW and does not assume
that the userspace process has anything set up already. So, start with a
fresh process for the n

um: remove copy_context_skas0

The kernel flushes the memory ranges anyway for CoW and does not assume
that the userspace process has anything set up already. So, start with a
fresh process for the new mm context.

Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20240703134536.1161108-8-benjamin@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

show more ...

um: Rework syscall handling

Rework syscall handling to be platform independent. Also create a clean
split between queueing of syscalls and flushing them out, removing the
need to keep state in the c

um: Rework syscall handling

Rework syscall handling to be platform independent. Also create a clean
split between queueing of syscalls and flushing them out, removing the
need to keep state in the code that triggers the syscalls.

The code adds syscall_data_len to the global mm_id structure. This will
be used later to allow surrounding code to track whether syscalls still
need to run and if errors occurred.

Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
Link: https://patch.msgid.link/20240703134536.1161108-5-benjamin@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

show more ...

kbuild: remove --include-dir MAKEFLAG from top Makefile

I added $(srctree)/ to some included Makefiles in the following commits:

- 3204a7fb98a3 ("kbuild: prefix $(srctree)/ to some included Makefi

kbuild: remove --include-dir MAKEFLAG from top Makefile

I added $(srctree)/ to some included Makefiles in the following commits:

- 3204a7fb98a3 ("kbuild: prefix $(srctree)/ to some included Makefiles")
- d82856395505 ("kbuild: do not require sub-make for separate output tree builds")

They were a preparation for removing --include-dir flag.

I have never thought --include-dir useful. Rather, it _is_ harmful.

For example, run the following commands:

$ make -s ARCH=x86 mrproper defconfig
$ make ARCH=arm O=foo dtbs
make[1]: Entering directory '/tmp/linux/foo'
HOSTCC scripts/basic/fixdep
Error: kernelrelease not valid - run 'make prepare' to update it
UPD include/config/kernel.release
make[1]: Leaving directory '/tmp/linux/foo'

The first command configures the source tree for x86. The next command
tries to build ARM device trees in the separate foo/ directory - this
must stop because the directory foo/ has not been configured yet.

However, due to --include-dir=$(abs_srctree), the top Makefile includes
the wrong include/config/auto.conf from the source tree and continues
building. Kbuild traverses the directory tree, but of course it does
not work correctly. The Error message is also pointless - 'make prepare'
does not help at all for fixing the issue.

This commit fixes more arch Makefile, and finally removes --include-dir
from the top Makefile.

There are more breakages under drivers/, but I do not volunteer to fix
them all. I just moved --include-dir to drivers/Makefile.

With this commit, the second command will stop with a sensible message.

$ make -s ARCH=x86 mrproper defconfig
$ make ARCH=arm O=foo dtbs
make[1]: Entering directory '/tmp/linux/foo'
SYNC include/config/auto.conf.cmd
***
*** The source tree is not clean, please run 'make ARCH=arm mrproper'
*** in /tmp/linux
***
make[2]: *** [../Makefile:646: outputmakefile] Error 1
/tmp/linux/Makefile:770: include/config/auto.conf.cmd: No such file or directory
make[1]: *** [/tmp/linux/Makefile:793: include/config/auto.conf.cmd] Error 2
make[1]: Leaving directory '/tmp/linux/foo'
make: *** [Makefile:226: __sub-make] Error 2

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

show more ...

um: Add SPDX headers to files in arch/um/kernel/

Convert files to use SPDX header. All files are licensed under the
GPLv2.

Signed-off-by: Alex Dewar <alex.dewar@gmx.co.uk>
Signed-off-by: Richard We

um: Add SPDX headers to files in arch/um/kernel/

Convert files to use SPDX header. All files are licensed under the
GPLv2.

Signed-off-by: Alex Dewar <alex.dewar@gmx.co.uk>
Signed-off-by: Richard Weinberger <richard@nod.at>

show more ...

um: Fix kcov crash during startup

Kcov fails to start when compiled with kcov. Disable KCOV on
arch/uml/kernel/skas.

$ gdb -q -ex r ./vmlinux
Program received signal SIGSEGV, Segmentation fault

um: Fix kcov crash during startup

Kcov fails to start when compiled with kcov. Disable KCOV on
arch/uml/kernel/skas.

$ gdb -q -ex r ./vmlinux
Program received signal SIGSEGV, Segmentation fault.
check_kcov_mode (t=<>, needed_mode=<>) at kernel/kcov.c:70
70 mode = READ_ONCE(t->kcov_mode);

Signed-off-by: Marek Majkowski <marek@cloudflare.com>
Signed-off-by: Richard Weinberger <richard@nod.at>

show more ...

uml: style fixes pass 3

Formatting changes in the files which have been changed in the course
of folding foo_skas functions into their callers. These include:
copyright updates
header file trimmi

uml: style fixes pass 3

Formatting changes in the files which have been changed in the course
of folding foo_skas functions into their callers. These include:
copyright updates
header file trimming
style fixes
adding severity to printks

These changes should be entirely non-functional.

Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...

uml: remove code made redundant by CHOOSE_MODE removal

This patch makes a number of simplifications enabled by the removal of
CHOOSE_MODE. There were lots of functions that looked like

int foo(ar

uml: remove code made redundant by CHOOSE_MODE removal

This patch makes a number of simplifications enabled by the removal of
CHOOSE_MODE. There were lots of functions that looked like

int foo(args){
foo_skas(args);
}

The bodies of foo_skas are now folded into foo, and their declarations (and
sometimes entire header files) are deleted.

In addition, the union uml_pt_regs, which was a union between the tt and skas
register formats, is now a struct, with the tt-mode arm of the union being
removed.

It turns out that usr2_handler was unused, so it is gone.

Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...

[PATCH] uml: file renaming

Move some foo_kern.c files to foo.c now that the old foo.c files are out
of the way.

Also cleaned up some whitespace and an emacs formatting comment.

Signed-off-by: Jeff

[PATCH] uml: file renaming

Move some foo_kern.c files to foo.c now that the old foo.c files are out
of the way.

Also cleaned up some whitespace and an emacs formatting comment.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...

[PATCH] uml: cleanup unprofile expression and build infrastructure

*) Rather than duplicate in various buggy ways the application of
CFLAGS_NO_HARDENING and UNPROFILE (which apply to the same fil

[PATCH] uml: cleanup unprofile expression and build infrastructure

*) Rather than duplicate in various buggy ways the application of
CFLAGS_NO_HARDENING and UNPROFILE (which apply to the same files),
centralize it in Makefile.rules. UNPROFILE_OBJS mustn't be listed in
USER_OBJS but are compiled as such.

I've also verified that unprofile didn't work in the current form, because we
set _c_flags directly (using CFLAGS and not USER_CFLAGS, which is wrong),
which is normally used by c_flags, but we also override c_flags for all
USER_OBJS, and there we don't call unprofile.

Instead it only worked for unmap.o, the only one which wasn't a USER_OBJ.

We need to set c_flags (which is not a public Kbuild API) to clear a lot of
compilation flags like -nostdinc which Kbuild forces on everything.

*) Rather than $(CFLAGS_$(notdir $@)), which expands to CFLAGS_anObj.s when
building "anObj.s", use $(CFLAGS_$(*F).o) which always accesses
CFLAGS_anObj.o, like done by Kbuild.

*) Make c_flags apply to all targets having the same basename, rather than
listing .s, .i, .lst and .o, with the use (which I tested) of

$(USER_OBJS:.o=.%): c_flags = ...

and of

- $(obj)/unmap.c: _c_flags = ...
+ $(obj)/unmap.%: _c_flags = ...

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...

[PATCH] uml: fix compilation and execution with hardened GCC

To make some half-assembly stubs compile, disable various "hardened" GCC
features:

*) we can't make it build PIC code as we need %ebx to

[PATCH] uml: fix compilation and execution with hardened GCC

To make some half-assembly stubs compile, disable various "hardened" GCC
features:

*) we can't make it build PIC code as we need %ebx to do syscalls and GCC
wants it free for PIC

*) we can't leave stack protection as the stub is moved (not relocated!) in
memory so the RIP-relative access to the canary tries reading from an
unmapped address and causes a segfault, since we move the stub of various
megabytes (the exact amount will be decided at runtime) away from the
link-time address.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...

[PATCH] uml: move libc-dependent skas process handling

The serial UML OS-abstraction layer patch (um/kernel/skas dir).

This moves all systemcalls from skas/process.c file under os-Linux dir and
joi

[PATCH] uml: move libc-dependent skas process handling

The serial UML OS-abstraction layer patch (um/kernel/skas dir).

This moves all systemcalls from skas/process.c file under os-Linux dir and
join skas/process.c and skas/process_kern.c files.

Signed-off-by: Gennady Sharapov <gennady.v.sharapov@intel.com>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...

[PATCH] uml: move libc-dependent skas memory mapping code

The serial UML OS-abstraction layer patch (um/kernel/skas dir).

This moves all systemcalls from skas/mem_user.c file under os-Linux dir and

[PATCH] uml: move libc-dependent skas memory mapping code

The serial UML OS-abstraction layer patch (um/kernel/skas dir).

This moves all systemcalls from skas/mem_user.c file under os-Linux dir and
join skas/mem_user.c and skas/mem.c files.

Signed-off-by: Gennady Sharapov <gennady.v.sharapov@intel.com>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...

[PATCH] uml: move libc-dependent code from trap_user.c

The serial UML OS-abstraction layer patch (um/kernel dir).

This moves all systemcalls from trap_user.c file under os-Linux dir

Signed-off-by:

[PATCH] uml: move libc-dependent code from trap_user.c

The serial UML OS-abstraction layer patch (um/kernel dir).

This moves all systemcalls from trap_user.c file under os-Linux dir

Signed-off-by: Gennady Sharapov <Gennady.V.Sharapov@intel.com>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...

[PATCH] uml makefiles sanitized

UML makefiles sanitized:
- number of generated headers reduced to 2 (from user-offsets.c and
kernel-offsets.c resp.). The rest is made constant and simply
inc

[PATCH] uml makefiles sanitized

UML makefiles sanitized:
- number of generated headers reduced to 2 (from user-offsets.c and
kernel-offsets.c resp.). The rest is made constant and simply
includes those two.
- mk_... helpers are gone now that we don't need to generate these
headers
- arch/um/include2 removed since everything under arch/um/include/sysdep
is constant now and symlink can point straight to source tree.
- dependencies seriously simplified.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...

[PATCH] uml: system call path cleanup

This merges two sets of files which had no business being split apart in the
first place.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Mo

[PATCH] uml: system call path cleanup

This merges two sets of files which had no business being split apart in the
first place.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...

[PATCH] uml: Proper clone support for skas0

This patch implements the clone-stub mechanism, which allows skas0 to run
with proc_mm==0, even if the clib in UML uses modify_ldt.

Note: There is a bug

[PATCH] uml: Proper clone support for skas0

This patch implements the clone-stub mechanism, which allows skas0 to run
with proc_mm==0, even if the clib in UML uses modify_ldt.

Note: There is a bug in skas3.v7 host patch, that avoids UML-skas from
running properly on a SMP-box. In full skas3, I never really saw problems,
but in skas0 they showed up.

More commentary by jdike - What this patch does is makes sure that the host
parent of each new host process matches the UML parent of the corresponding
UML process. This ensures that any changed LDTs are inherited. This is
done by having clone actually called by the UML process from its stub,
rather than by the kernel. We have special syscall stubs that are loaded
onto the stub code page because that code must be completely
self-contained. These stubs are given C interfaces, and used like normal C
functions, but there are subtleties. Principally, we have to be careful
about stack variables in stub_clone_handler after the clone. The code is
written so that there aren't any - everything boils down to a fixed
address. If there were any locals, references to them after the clone
would be wrong because the stack just changed.

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...

[PATCH] uml: time initialization tidying

user_time_init_skas and user_time_init_tt were essentially the same. So, this
merges them, deleting the mode-specific functions and declarations.

Signed-of

[PATCH] uml: time initialization tidying

user_time_init_skas and user_time_init_tt were essentially the same. So, this
merges them, deleting the mode-specific functions and declarations.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

show more ...