linux-stable.git/arch/um/kernel, branch linux-5.11.y

um: defer killing userspace on page table update failures

2021-03-04T11:15:39+00:00

commit a7d48886cacf8b426e0079bca9639d2657cf2d38 upstream.

In some cases we can get to fix_range_common() with mmap_sem held,
and in others we get there without it being held. For example, we
get there with it held from sys_mprotect(), and without it held
from fork_handler().

Avoid any issues in this and simply defer killing the task until
it runs the next time. Do it on the mm so that another task that
shares the same mm can't continue running afterwards.

Cc: stable@vger.kernel.org
Fixes: 468f65976a8d ("um: Fix hung task in fix_range_common()")
Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

um: mm: check more comprehensively for stub changes

2021-03-04T11:15:39+00:00

commit 47da29763ec9a153b9b685bff9db659e4e09e494 upstream.

If userspace tries to change the stub, we need to kill it,
because otherwise it can escape the virtual machine. In a
few cases the stub checks weren't good, e.g. if userspace
just tries to

	mmap(0x100000 - 0x1000, 0x3000, ...)

it could succeed to get a new private/anonymous mapping
replacing the stubs. Fix this by checking everywhere, and
checking for _overlap_, not just direct changes.

Cc: stable@vger.kernel.org
Fixes: 3963333fe676 ("uml: cover stubs with a VMA")
Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

um: time: fix initialization in time-travel mode

2021-01-26T21:11:38+00:00

In time-travel mode, since my previous patch, the start time was
initialized too late, so that the system would read it before we
set it, thus always starting system time at 0 (1970-01-01). This
happens because timekeeping_init() reads the time and is called
before time_init().

Unfortunately, I didn't see this before because I was testing it
only with the RTC patch applied (and enabled), and then the time
is read again by the RTC a little - after time_init() this time.

Fix this by just doing the initialization whenever necessary.

Fixes: 2701c1bd91dd ("um: time: Fix read_persistent_clock64() in time-travel")
Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger

Revert "um: support some of ARCH_HAS_SET_MEMORY"

2021-01-26T21:11:38+00:00

This reverts commit 963285b0b47a ("um: support some of
ARCH_HAS_SET_MEMORY"), as it turns out that it's not only not
working (due to um never using the protection bits in the
page tables) but also corrupts the page tables if used on a
non-vmalloc page, since um never allocates proper page tables
for the 'physmem' in the first place.

Fixing all this will take more effort, so for now revert it.

Reported-by: Benjamin Berg 
Fixes: 963285b0b47a ("um: support some of ARCH_HAS_SET_MEMORY")
Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger

Revert "um: allocate a guard page to helper threads"

2021-01-26T21:11:38+00:00

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 
Fixes: ef4459a6da09 ("um: allocate a guard page to helper threads")
Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger

um: kmsg_dumper: always dump when not tty console

2021-01-26T21:11:37+00:00

With the addition of the ttynull console driver, the chance that a
console driver was already registerd did increase. Refine the logic when
to dump the kernel message buffer: always dump the buffer, when the UML
stdio console driver is not active and the preferred console.

Signed-off-by: Thomas Meyer 
Signed-off-by: Richard Weinberger

um: stdio_console: Make preferred console

2021-01-26T21:11:37+00:00

The addition of the "ttynull" console driver did break the ordering of the
UML stdio console driver.
The UML stdio console driver is added in late_initcall (7), whereby the
ttynull driver is added in device_initcall (6), which always does make the
ttynull driver the default console.

Fix it by explicitly adding the UML stdio console as the preferred console,
in case no 'console=' command line option was specified.

Signed-off-by: Thomas Meyer 
Signed-off-by: Richard Weinberger

um: Fix build w/o CONFIG_PM_SLEEP

2020-12-14T20:15:32+00:00

uml_pm_wake() is unconditionally called from the SIGUSR1 wakeup
handler since that's in the userspace portion of UML, and thus
a bit tricky to ifdef out. Since pm_system_wakeup() can always
be called (but may be an empty inline), also simply always have
uml_pm_wake() to fix the build.

Reported-by: Randy Dunlap 
Acked-by: Randy Dunlap  # build-tested
Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger

um: time-travel: Correct time event IRQ delivery

2020-12-13T21:42:06+00:00

Lockdep (on 5.10-rc) points out that we're delivering IRQs while IRQs
are not even enabled, which clearly shouldn't happen. Defer the time
event IRQ delivery until they actually are enabled.

Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger

um: irq/sigio: Support suspend/resume handling of workaround IRQs

2020-12-13T21:42:01+00:00

If the sigio workaround needed to be applied to a file descriptor,
set_irq_wake() wouldn't work for it since it would get polled by
the thread instead of causing SIGIO, and thus could never really
cause a wakeup, since the thread notification FD wasn't marked as
being able to wake up the system.

Fix this by marking the thread's notification FD explicitly as a
wake source FD, i.e. not suppressing SIGIO for it in suspend. In
order to not cause spurious wakeups, we then need to remove all
FDs that shouldn't wake up the system from the polling thread. In
order to do this, add unlocked versions of ignore_sigio_fd() and
add_sigio_fd() (nothing else is happening in suspend, so this is
fine), and also modify ignore_sigio_fd() to return -ENOENT if the
FD wasn't originally in there. This doesn't matter because nothing
else currently checks the return value, but the irq code needs to
know which ones to restore the workaround for.

All told, this lets us use a timerfd for the RTC clock in the next
patch, which doesn't send SIGIO.

Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger