linux-stable.git/arch/um, 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

um: fix os_idle_sleep() to not hang

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

Changing os_idle_sleep() to use pause() (I accidentally described
it as an empty select() in the commit log because I had changed it
from that to pause() in a later revision) exposed a race condition
in the idle code. The following can happen:

 timer_settime(0, 0, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=0, tv_nsec=624017}}, NULL) = 0
 ...
 
 pause()

and we now hang forever. This was previously possible as well, but
it could never cause UML to hang for more than a second since we
could only sleep for that much, so at most you'd notice a "hiccup"
in the UML. Obviously, any sort of external interrupt also "saves"
it and interrupts pause().

Fix this by properly handling the race, rather than papering over
it again:

 - first, block SIGALRM, and obtain the old signal set
 - check the timer
 - suspend, waiting for any signal out of the old set, if, and only
   if, the timer will fire in the future
 - restore the old signal mask

This ensures race-free operation: as it's blocked, the signal won't
be delivered while we're looking at the timer even if it were to be
triggered right _after_ we've returned from timer_gettime() with a
non-zero value (telling us the timer will trigger). Thus, despite
getting to sigsuspend() because timer_gettime() told us we're still
waiting, we'll not hang because sigsuspend() will return immediately
due to the pending signal.

Fixes: 49da38a3ef33 ("um: Simplify os_idle_sleep() and sleep longer")
Signed-off-by: Johannes Berg 
Acked-By: Anton Ivanov 
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: virtio: free vu_dev only with the contained struct device

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

Since struct device is refcounted, we shouldn't free the vu_dev
immediately when it's removed from the platform device, but only
when the references actually all go away. Move the freeing to
the release to accomplish that.

Fixes: 5d38f324993f ("um: drivers: Add virtio vhost-user driver")
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: return error from ioremap()

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

Back a few years ago, ioremap() was added to UML so that we'd
not break the build for everything all the time. However, for
some reason, v1 of the patch got applied, rather than the v2
that returned NULL, which was discussed here:

https://lore.kernel.org/lkml/1495726955-27497-1-git-send-email-logang@deltatee.com/

Fix that now.

Signed-off-by: Johannes Berg 
Acked-by: Arnd Bergmann 
Signed-off-by: Richard Weinberger