kernel/linux.git/arch/um/os-Linux, branch v6.1.168

um: remove copy_from_kernel_nofault_allowed

2025-04-10T12:33:36+00:00

[ Upstream commit 84a6fc378471fbeaf48f8604566a5a33a3d63c18 ] There is no need to override the default version of this function anymore as UML now has proper _nofault memory access functions. Doing this also fixes the fact that the implementation was incorrect as using mincore() will incorrectly flag pages as inaccessible if they were swapped out by the host. Fixes: f75b1b1bedfb ("um: Implement probe_kernel_read()") Signed-off-by: Benjamin Berg Link: https://patch.msgid.link/20250210160926.420133-3-benjamin@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

um: time-travel: fix signal blocking race/hang

2024-08-03T06:49:47+00:00

[ Upstream commit 2cf3a3c4b84def5406b830452b1cb8bbfffe0ebe ] When signals are hard-blocked in order to do time-travel socket processing, we set signals_blocked and then handle SIGIO signals by setting the SIGIO bit in signals_pending. When unblocking, we first set signals_blocked to 0, and then handle all pending signals. We have to set it first, so that we can again properly block/unblock inside the unblock, if the time-travel handlers need to be processed. Unfortunately, this is racy. We can get into this situation: // signals_pending = SIGIO_MASK unblock_signals_hard() signals_blocked = 0; if (signals_pending && signals_enabled) { block_signals(); unblock_signals() ... sig_handler_common(SIGIO, NULL, NULL); sigio_handler() ... sigio_reg_handler() irq_do_timetravel_handler() reg->timetravel_handler() == vu_req_interrupt_comm_handler() vu_req_read_message() vhost_user_recv_req() vhost_user_recv() vhost_user_recv_header() // reads 12 bytes header of // 20 bytes message <-- receive SIGIO here <-- sig_handler() int enabled = signals_enabled; // 1 if ((signals_blocked || !enabled) && (sig == SIGIO)) { if (!signals_blocked && time_travel_mode == TT_MODE_EXTERNAL) sigio_run_timetravel_handlers() _sigio_handler() sigio_reg_handler() ... as above ... vhost_user_recv_header() // reads 8 bytes that were message payload // as if it were header - but aborts since // it then gets -EAGAIN ... --> end signal handler --> // continue in vhost_user_recv() // full_read() for 8 bytes payload busy loops // entire process hangs here Conceptually, to fix this, we need to ensure that the signal handler cannot run while we hard-unblock signals. The thing that makes this more complex is that we can be doing hard-block/unblock while unblocking. Introduce a new signals_blocked_pending variable that we can keep at non-zero as long as pending signals are being processed, then we only need to ensure it's decremented safely and the signal handler will only increment it if it's already non-zero (or signals_blocked is set, of course.) Note also that only the outermost call to hard-unblock is allowed to decrement signals_blocked_pending, since it could otherwise reach zero in an inner call, and leave the same race happening if the timetravel_handler loops, but that's basically required of it. Fixes: d6b399a0e02a ("um: time-travel/signals: fix ndelay() in interrupt") Link: https://patch.msgid.link/20240703110144.28034-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

um: Fix the declaration of kasan_map_memory

2024-06-12T09:03:48+00:00

[ Upstream commit 6a85e34c4d07d2ec0c153067baff338ac0db55ca ] Make it match its definition (size_t vs unsigned long). And declare it in a shared header to fix the -Wmissing-prototypes warning, as it is defined in the user code and called in the kernel code. Fixes: 5b301409e8bc ("UML: add support for KASAN under x86_64") Signed-off-by: Tiwei Bie Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

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