linux-stable.git/arch/um/os-Linux, branch v6.1.78

um: Don't use vfprintf() for os_info()

2024-02-05T20:12:57+00:00

[ Upstream commit 236f9fe39b02c15fa5530b53e9cca48354394389 ]

The threads allocated inside the kernel have only a single page of
stack. Unfortunately, the vfprintf function in standard glibc may use
too much stack-space, overflowing it.

To make os_info safe to be used by helper threads, use the kernel
vscnprintf function into a smallish buffer and write out the information
to stderr.

Signed-off-by: Benjamin Berg 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

um: Fix naming clash between UML and scheduler

2024-02-05T20:12:57+00:00

[ Upstream commit 541d4e4d435c8b9bfd29f70a1da4a2db97794e0a ]

__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 
Reviewed-by: Peter Lafreniere 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

Revert "um: Use swap() to make code cleaner"

2023-08-03T08:24:15+00:00

commit dddfa05eb58076ad60f9a66e7155a5b3502b2dd5 upstream.

This reverts commit 9b0da3f22307af693be80f5d3a89dc4c7f360a85.

The sigio.c is clearly user space code which is handled by
arch/um/scripts/Makefile.rules (see USER_OBJS rule).

The above mentioned commit simply broke this agreement,
we may not use Linux kernel internal headers in them without
thorough thinking.

Hence, revert the wrong commit.

Link: https://lkml.kernel.org/r/20230724143131.30090-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko 
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202307212304.cH79zJp1-lkp@intel.com/
Cc: Anton Ivanov 
Cc: Herve Codina 
Cc: Jason A. Donenfeld 
Cc: Johannes Berg 
Cc: Rasmus Villemoes 
Cc: Richard Weinberger 
Cc: Yang Guang 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

um: Enable FORTIFY_SOURCE

2022-09-07T23:37:27+00:00

Enable FORTIFY_SOURCE so running Kunit tests can test fortified
functions.

Signed-off-by: Kees Cook 
Tested-by: David Gow 
Link: https://lore.kernel.org/r/20220210003224.773957-1-keescook@chromium.org

Merge tag 'for-linus-5.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml

2022-08-05T21:03:11+00:00

Pull UML updates from Richard Weinberger:

 - KASAN support for x86_64

 - noreboot command line option, just like qemu's -no-reboot

 - Various fixes and cleanups

* tag 'for-linus-5.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml:
  um: include sys/types.h for size_t
  um: Replace to_phys() and to_virt() with less generic function names
  um: Add missing apply_returns()
  um: add "noreboot" command line option for PANIC_TIMEOUT=-1 setups
  um: include linux/stddef.h for __always_inline
  UML: add support for KASAN under x86_64
  mm: Add PAGE_ALIGN_DOWN macro
  um: random: Don't initialise hwrng struct with zero
  um: remove unused mm_copy_segments
  um: remove unused variable
  um: Remove straying parenthesis
  um: x86: print RIP with symbol
  arch: um: Fix build for statically linked UML w/ constructors
  x86/um: Kconfig: Fix indentation
  um/drivers: Kconfig: Fix indentation
  um: Kconfig: Fix indentation

um: seed rng using host OS rng

2022-07-18T13:04:04+00:00

UML generally does not provide access to special CPU instructions like
RDRAND, and execution tends to be rather deterministic, with no real
hardware interrupts, making good randomness really very hard, if not
all together impossible. Not only is this a security eyebrow raiser, but
it's also quite annoying when trying to do various pieces of UML-based
automation that takes a long time to boot, if ever.

Fix this by trivially calling getrandom() in the host and using that
seed as "bootloader randomness", which initializes the rng immediately
at UML boot.

The old behavior can be restored the same way as on any other arch, by
way of CONFIG_TRUST_BOOTLOADER_RANDOMNESS=n or
random.trust_bootloader=0. So seen from that perspective, this just
makes UML act like other archs, which is positive in its own right.

Additionally, wire up arch_get_random_{int,long}() in the same way, so
that reseeds can also make use of the host RNG, controllable by
CONFIG_TRUST_CPU_RANDOMNESS and random.trust_cpu, per usual.

Cc: stable@vger.kernel.org
Acked-by: Johannes Berg 
Acked-By: Anton Ivanov 
Signed-off-by: Jason A. Donenfeld

um: Replace to_phys() and to_virt() with less generic function names

2022-07-17T21:44:40+00:00

to_virt() and to_phys() are very generic and may be defined by drivers.
As it turns out, commit 9409c9b6709e ("pmem: refactor pmem_clear_poison()")
did exactly that. This results in build errors such as the following
when trying to build um:allmodconfig.

drivers/nvdimm/pmem.c: In function ‘pmem_dax_zero_page_range’:
./arch/um/include/asm/page.h:105:20: error:
			too few arguments to function ‘to_phys’
  105 | #define __pa(virt) to_phys((void *) (unsigned long) (virt))
      |                    ^~~~~~~

Use less generic function names for the um specific to_phys() and to_virt()
functions to fix the problem and to avoid similar problems in the future.

Fixes: 9409c9b6709e ("pmem: refactor pmem_clear_poison()")
Cc: Dan Williams 
Cc: Christoph Hellwig 
Signed-off-by: Guenter Roeck 
Acked-By: Anton Ivanov 
Acked-by: Dan Williams 
Signed-off-by: Richard Weinberger

um: add "noreboot" command line option for PANIC_TIMEOUT=-1 setups

2022-07-17T21:41:02+00:00

QEMU has a -no-reboot option, which halts instead of reboots when the
guest asks to reboot. This is invaluable when used with
CONFIG_PANIC_TIMEOUT=-1 (and panic_on_warn), because it allows panics
and warnings to be caught immediately in CI. Implement this in UML too,
by way of a basic setup param.

Signed-off-by: Jason A. Donenfeld 
Signed-off-by: Richard Weinberger

UML: add support for KASAN under x86_64

2022-07-17T21:35:22+00:00

Make KASAN run on User Mode Linux on x86_64.

The UML-specific KASAN initializer uses mmap to map the ~16TB of shadow
memory to the location defined by KASAN_SHADOW_OFFSET.  kasan_init()
utilizes constructors to initialize KASAN before main().

The location of the KASAN shadow memory, starting at
KASAN_SHADOW_OFFSET, can be configured using the KASAN_SHADOW_OFFSET
option. The default location of this offset is 0x100000000000, which
keeps it out-of-the-way even on UML setups with more "physical" memory.

For low-memory setups, 0x7fff8000 can be used instead, which fits in an
immediate and is therefore faster, as suggested by Dmitry Vyukov. There
is usually enough free space at this location; however, it is a config
option so that it can be easily changed if needed.

Note that, unlike KASAN on other architectures, vmalloc allocations
still use the shadow memory allocated upfront, rather than allocating
and free-ing it per-vmalloc allocation.

If another architecture chooses to go down the same path, we should
replace the checks for CONFIG_UML with something more generic, such
as:
- A CONFIG_KASAN_NO_SHADOW_ALLOC option, which architectures could set
- or, a way of having architecture-specific versions of these vmalloc
  and module shadow memory allocation options.

Also note that, while UML supports both KASAN in inline mode
(CONFIG_KASAN_INLINE) and static linking (CONFIG_STATIC_LINK), it does
not support both at the same time.

Signed-off-by: Patricia Alfonso 
Co-developed-by: Vincent Whitchurch 
Signed-off-by: Vincent Whitchurch 
Signed-off-by: David Gow 
Reviewed-by: Johannes Berg 
Reviewed-by: Dmitry Vyukov 
Reviewed-by: Andrey Konovalov 
Signed-off-by: Richard Weinberger

um: remove unused variable

2022-07-17T21:26:27+00:00

The variable dead is initialized but never used otherwise.

Signed-off-by: Haowen Bai 
Signed-off-by: Richard Weinberger