userspace
process. This should be safe and SECCOMP requires the IRQ in case the
process does not come up properly.
Signed-off-by: Benjamin Berg
Signed-off-by: Benjamin Berg
---
v2:
- Fix whitespace issue
v1:
- Permit IRQs during startup to enable detection there
RFCv2:
- Use "struct list_head
This detects seccomp support, sets the global using_seccomp variable and
initilizes the exec registers.
Signed-off-by: Benjamin Berg
Signed-off-by: Benjamin Berg
---
arch/um/include/shared/skas/skas.h | 5 +
arch/um/os-Linux/registers.c | 4 +-
arch/um/os-Linux/skas/process.c
, but I do
not know why this difference exists. And, passing NULL can even result
in a crash.
Signed-off-by: Benjamin Berg
---
arch/um/os-Linux/skas/process.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux
From: Benjamin Berg
Instead of always sharing the FDs with the userspace process, only hand
over the FDs needed for mmap when required. The idea is that userspace
might be able to force the stub into executing an mmap syscall, however,
it will not be able to manipulate the control flow
: Benjamin Berg
Signed-off-by: Benjamin Berg
---
RFCv2:
- Proper FP register handling
---
arch/x86/um/os-Linux/mcontext.c | 220 ++-
arch/x86/um/ptrace.c | 76 ++---
arch/x86/um/shared/sysdep/mcontext.h | 9 ++
3 files changed, 285 insertions
syscall.
Co-authored-by: Johannes Berg
Signed-off-by: Benjamin Berg
Signed-off-by: Benjamin Berg
---
v1:
- Cleanup futex EINTR/EAGAIN handling
RFCv2:
- Add include guards into new architecture specific header file
---
arch/um/include/shared/common-offsets.h | 2 +
arch/um/include/shared/skas
This adds the kernel side of the seccomp based process handling.
Co-authored-by: Johannes Berg
Signed-off-by: Benjamin Berg
Signed-off-by: Benjamin Berg
---
v1:
- Fix FUTEX_WAIT EINTR handling
- Don't send fatal_sigsegv when waiting during child startup
---
arch/um/include/shared/c
From: Benjamin Berg
Hi all,
another version of the SECCOMP patchset. I think that this should now be
good enough for general consumption. Compared to the last RFC version
there is an important bugfix that caused a SIGSEGV loop and various
other small bugfixes and cleanups.
The patchset adds a
Add the UML_SECCOMP configuration options.
Signed-off-by: Benjamin Berg
---
v1:
- Move to the end
RFCv2:
- Remove "default n"
---
arch/um/Kconfig | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/um/Kconfig b/arch/um/Kconfig
index 79509c7f39de..f9ed39709
From: Benjamin Berg
Segfaults can occur at times where the mmap lock cannot be taken. If
that happens the segfault handler may not be able to take the mmap lock.
Fix the code to use the same approach as most other architectures.
Unfortunately, this requires copying code from mm/memory.c and
From: Benjamin Berg
We send a SIGALRM to userspace processes to interrupt them. Really,
doing so is only needed if they are actually executing at the time (to
ensure we return to kernelspace). Unfortunately, we do not have that
information readily available. We can however be sure that this is
t is crashing
instead of failing gracefully and retrying.
In segv_handler, can you try moving that into a separate "else if"
block just above the "current->mm == NULL" check?
Something like the patch I copied below.
Benjamin
diff --git a/arch/um/kernel/trap.c b/arch
ons that can be used to create
> > > > pthread-based helpers. Helper threads created in this way will ensure
> > > > thread safety for errno while sharing the same memory space.
> > >
> > > Using pthreads seemed odd, but Benjamin argues that it's the only way
From: Benjamin Berg
sched_yield by a userspace may not actually cause scheduling in
time-travel mode as no time has passed. In the case seen it appears to
be a badly implemented userspace spinlock in ASAN. Unfortunately, with
time-travel it causes an extreme slowdown or even deadlock depending
Hi,
On Fri, 2025-03-07 at 16:04 +0900, Hajime Tazaki wrote:
> thanks for the update; was waiting for this.
>
> On Tue, 25 Feb 2025 03:18:25 +0900,
> Benjamin Berg wrote:
> >
> > This adds the kernel side of the seccomp based process handling.
> >
> > Co-au
On Wed, 2025-02-26 at 14:08 +0100, Ingo Molnar wrote:
>
> * Benjamin Berg wrote:
>
> > From: Benjamin Berg
> >
> > The init_task instance of struct task_struct is statically allocated and
> > may not contain the full FP state for userspace. As such, limit
: Benjamin Berg
Signed-off-by: Benjamin Berg
---
RFCv2:
- Proper FP register handling
---
arch/x86/um/os-Linux/mcontext.c | 220 ++-
arch/x86/um/ptrace.c | 76 ++---
arch/x86/um/shared/sysdep/mcontext.h | 9 ++
3 files changed, 285 insertions
syscall.
Co-authored-by: Johannes Berg
Signed-off-by: Benjamin Berg
Signed-off-by: Benjamin Berg
---
v1:
- Cleanup futex EINTR/EAGAIN handling
RFCv2:
- Add include guards into new architecture specific header file
---
arch/um/include/shared/common-offsets.h | 2 +
arch/um/include/shared/skas
Add the UML_SECCOMP configuration options.
Signed-off-by: Benjamin Berg
---
v1:
- Move to the end
RFCv2:
- Remove "default n"
---
arch/um/Kconfig | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/um/Kconfig b/arch/um/Kconfig
index 18051b1cfce0..11ed44225
userspace
process. This should be safe and SECCOMP requires the IRQ in case the
process does not come up properly.
Signed-off-by: Benjamin Berg
Signed-off-by: Benjamin Berg
---
v1:
- Permit IRQs during startup to enable detection there
RFCv2:
- Use "struct list_head" for the list by placi
This adds the kernel side of the seccomp based process handling.
Co-authored-by: Johannes Berg
Signed-off-by: Benjamin Berg
Signed-off-by: Benjamin Berg
---
v1:
- Fix FUTEX_WAIT EINTR handling
- Don't send fatal_sigsegv when waiting during child startup
---
arch/um/include/shared/c
From: Benjamin Berg
Instead of always sharing the FDs with the userspace process, only hand
over the FDs needed for mmap when required. The idea is that userspace
might be able to force the stub into executing an mmap syscall, however,
it will not be able to manipulate the control flow
perfectly fine for ptrace.
Signed-off-by: Benjamin Berg
---
arch/x86/um/os-Linux/mcontext.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/um/os-Linux/mcontext.c b/arch/x86/um/os-Linux/mcontext.c
index e80ab7d28117..1b0d95328b2c 100644
--- a/arch/x86/um/os-Linux
This detects seccomp support, sets the global using_seccomp variable and
initilizes the exec registers.
Signed-off-by: Benjamin Berg
Signed-off-by: Benjamin Berg
---
arch/um/include/shared/skas/skas.h | 5 +
arch/um/os-Linux/registers.c | 4 +-
arch/um/os-Linux/skas/process.c
, but I do
not know why this difference exists. And, passing NULL can even result
in a crash.
Signed-off-by: Benjamin Berg
---
arch/um/os-Linux/skas/process.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux
From: Benjamin Berg
Hi all,
another version of the SECCOMP patchset. I think that this should now be
good enough for general consumption. Compared to the last RFC version
there is an important bugfix that caused a SIGSEGV loop and various
other small bugfixes and cleanups.
The patchset adds a
From: Benjamin Berg
Some file systems (e.g. ext4) may reuse inode numbers once the inode is
not in use anymore. Usually hostfs will keep an FD open for each inode,
but this is not always the case. In the case of sockets, this cannot
even be done properly.
As such, the following sequence of
mp;&label extension, but at least in one
attempt I made the && caused the compiler to not load -EFAULT
into the register in case of jumping to the &&label from the
fault handler. So leave it like this for now.
Co-developed-by: Benjamin Berg
Signed-off-by: Johannes Berg
Signed
From: Benjamin Berg
Hi,
using mincore() to check whether a page is owned by UML is not correct
as it returns whether the page is resident in memory and not whether
something has been mapped at the address. This means that UML could get
spurious failures in *_nofault functions like
From: Benjamin Berg
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
On Mon, 2025-01-20 at 07:07 +0100, Thomas Meyer wrote:
>
>
> Am 20. Januar 2025 00:25:35 MEZ schrieb Glenn Washburn
> :
> > Hi Benjamin,
> >
> > After applying the close_range patch, I'm now getting a failure at
> > runtime where the last line prin
Hi,
On Wed, 2025-01-15 at 09:25 +0900, Hajime Tazaki wrote:
> On Wed, 15 Jan 2025 03:53:36 +0900,
> Benjamin Berg wrote:
> >
> > On Tue, 2025-01-14 at 20:30 +0900, Hajime Tazaki wrote:
> > > This patchset is another spin of nommu mode addition to UML. It doesn
/thread switches and also signal
emission/sigreturn. I am attaching the test program that I used to
verify the correct behaviour when dealing with the recent changes to FP
register handling in UML.
Benjamin
>
> -- Hajime
>
> v6:
> - rebase to the latest uml/next tree
> - mor
From: Benjamin Berg
The stub execution uses the somewhat new close_range and execveat
syscalls. Of these two, the execveat call is essential, but the
close_range call is more about stub process hygiene rather than safety
(and its result is ignored).
Replace both calls with a raw syscall as
Hi,
On Sun, 2025-01-12 at 14:07 -0600, Glenn Washburn wrote:
> On Fri, 10 Jan 2025 17:13:05 +0100
> Benjamin Berg wrote:
>
> > From: Benjamin Berg
> >
> > The stub execution uses the somewhat new close_range and execveat
> > syscalls. Of these two, the ex
From: Benjamin Berg
The stub execution uses the somewhat new close_range and execveat
syscalls. Of these two, the execveat call is essential, but the
close_range call is more about stub process hygiene rather than safety
(and its result is ignored).
Replace both calls with a raw syscall as
Hi,
On Wed, 2025-01-08 at 12:13 +0100, Geert Uytterhoeven wrote:
> Hi Benjamin,
>
> On Wed, Jan 8, 2025 at 11:58 AM Benjamin Berg
> wrote:
> > On Wed, 2025-01-08 at 02:24 -0600, Glenn Washburn wrote:
> > > I'm wanting to build a UML kernel on Debian bullseye,
ferently, we could just replace the call with:
#ifndef CLOSE_RANGE_CLOEXEC
#define CLOSE_RANGE_CLOEXEC(1U << 2)
#endif
syscall(__NR_close_range, 0, ~0U, CLOSE_RANGE_CLOEXEC);
I am not sure whether we would want to do this in the upstream code.
Benjamin
From: Benjamin Berg
The stack needs to be properly aligned so 16 byte memory accesses on the
stack are correct. This was broken when introducing the dynamic math
register sizing as the rounding was not moved appropriately.
Fixes: 3f17fed21491 ("um: switch to regset API and depend on X
From: Benjamin Berg
The kernel realtime and the current RTC time may have a (small) offset.
Should the kernel time be slightly in the future, then the timeout is
zero. This is problematic in time-travel mode, as a zero timeout can be
correctly configured and time never advances.
Replace the
From: Benjamin Berg
Since commit 0eb5085c3874 ("arch: remove ARCH_TASK_STRUCT_ON_STACK")
there is no option that would allow placing task_struct on the stack.
Remove the unused linker script entry.
Signed-off-by: Benjamin Berg
---
include/asm-generic/vmlinux.lds.h | 1 -
1 file
From: Benjamin Berg
The init_task instance of struct task_struct is statically allocated and
does not contain the dynamic area for the userspace FP registers. As
such, limit the copy to the valid area of init_task and fill the rest
with zero.
Note that the FP state is only needed for userspace
From: Benjamin Berg
The init_task instance of struct task_struct is statically allocated and
may not contain the full FP state for userspace. As such, limit the copy
to the valid area of init_task and fill the rest with zero.
Note that the FP state is only needed for userspace, and as such it
From: Benjamin Berg
On the x86 and um architectures struct task_struct is dynamically
sized depending on the size required to store the floating point
registers. After adding this feature to UML it sometimes triggered
KASAN errors as the memcpy in arch_dup_task_struct read past
init_task.
In my
Hi,
On Sat, 2024-12-14 at 00:08 +0100, Benjamin Berg wrote:
> outch. It is doing a memcpy of init_task. Now, struct task_struct is
> variably sized, but init_struct is statically allocated, which could
> explain why the memcpy is not permitted to read the larger memory (for
> the
;)
may be part of a correct fix here.
Benjamin
On Fri, 2024-12-13 at 12:00 -0800, Brian Norris wrote:
> Hi Benjamin,
>
> On Wed, Oct 23, 2024 at 11:41:20AM +0200, Benjamin Berg wrote:
> > From: Benjamin Berg
> >
> > The PTRACE_GETREGSET API has now existed since Linux 2.6
Hi,
On Wed, 2024-12-04 at 09:43 -0800, Jeff Xu wrote:
> On Wed, Dec 4, 2024 at 6:04 AM Benjamin Berg
> wrote:
> > On Mon, 2024-11-25 at 20:20 +, jef...@chromium.org wrote:
> > > From: Jeff Xu
> > >
> > > Seal vdso, vvar, sigpage, uprobes and vs
mory has to be unmapped as it is managed by the
UML kernel.
This unmapping will not work if the vdso/vvar mappings are sealed.
Maybe nobody who enables the feature cares about UML. But wanted to
raise it as a potential issue in case you are not aware yet.
Benjamin
[1] Hmm, we should mseal() those s
From: Benjamin Berg
It was reported that qemu may not enable the XSTATE CPU extension, which
is a requirement after commit 3f17fed21491 ("um: switch to regset API
and depend on XSTATE"). Add a fallback to use FXSAVE (FP registers on
x86_64 and XFP on i386) which is just a shorter vers
On Tue, 2024-12-03 at 07:56 -0800, SeongJae Park wrote:
> On Tue, 03 Dec 2024 07:01:09 SeongJae Park wrote:
>
> > On Tue, 03 Dec 2024 09:40:34 +0100 Benjamin Berg
> > wrote:
> >
> > > Hi,
> > >
> > > that probably means the size detection
Hi,
that probably means the size detection for the FPU state (i.e.
PTRACE_GETREGSET for NT_X86_XSTATE is incorrect on a 32bit host in some
way.
Is there anything special about the qemu setup or it is just a default
qemu-x86?
Benjamin
On Mon, 2024-12-02 at 23:02 -0800, SeongJae Park wrote
rom user, store the task registers from the
mcontext. At some point (here or earlier) ensure that the
"current->thread.switch_buf" is set up so that we can return to
userspace by restoring the task registers.
- To schedule, piggy back on 1. or add special
Hi,
On Mon, 2024-11-11 at 15:27 +0900, Hajime Tazaki wrote:
> On !MMU mode, the address of vdso is accessible from userspace. This
> commit implements the entry point by pointing a block of page address.
>
> This commit also add memory permission configuration of vdso page to be
> executable.
>
d be changing FS to the original FS (not the
> + * one set by the guest libc). This original FS is stored
> + * in host_fs.
> + */
> +long long host_fs = -1;
Right, the libc already uses it for its own thread-local storage. That
is a bit annoying, as UML doesn't need threading
From: Benjamin Berg
This selects the THREAD_INFO_IN_TASK option for UM and changes the way
that the current task is discovered. This is trivial though, as UML
already tracks the current task in cpu_tasks[] and this can be used to
retrieve it.
Also remove the signal handler code that copies the
From: Benjamin Berg
This selects the THREAD_INFO_IN_TASK option for UM and changes the way
that the current task is discovered. This is trivial though, as UML
already tracks the current task in cpu_tasks[] and this can be used to
retrieve it.
Also remove the signal handler code that copies the
bably need to pass
it differently for older kernels.
Benjamin
On Wed, 2024-11-06 at 17:22 +0530, Ritesh Raj Sarraf wrote:
> Hello Benjamin,
>
> On Thu, 2024-10-31 at 11:07 +0100, Benjamin Berg wrote:
> > Hi,
> >
> > Newer kernels have become more picky about that wi
Hi,
On Mon, 2024-11-04 at 17:08 +0900, Hajime Tazaki wrote:
> this is a great clean up I think.
> I've also applied my tentative nommu patch and works fine with minor
> modifications.
>
> On Mon, 04 Nov 2024 00:05:34 +0900,
> Benjamin Berg wrote:
>
> > diff --git
From: Benjamin Berg
When the VHOST_USER_PROTOCOL_F_MQ protocol feature flag is set, we can
query the maximum number of virtual queues. Do so when supported and
extend the check to verify that we are not trying to allocate more
queues.
Signed-off-by: Benjamin Berg
---
arch/um/drivers
From: Benjamin Berg
If the device does not support slave requests, then the IRQ will not yet
be allocated. So initialize the IRQ to UM_IRQ_ALLOC so that it will be
allocated if none has been assigned yet and store it slightly later when
we know that it will not be immediately unregistered again
From: Benjamin Berg
With these changes, both virtio-fs and virtio-snd seem to work fine. The
feature to query the number of vqs is not really needed, but I already
had the code.
You can for example boot a machine that has both by executing something
like the following:
$ virtiofsd --sandbox
From: Benjamin Berg
It appears that the different vhost device implementations use different
sizes of the virtual queues. Add device specific limitations (for now,
only for sound), to ensure that we do not get disconnected unexpectedly.
Signed-off-by: Benjamin Berg
---
arch/um/drivers
From: Benjamin Berg
The rust based userspace vhost devices are very strict and will not
accept the message if it is longer than required. So, only include the
data for the first memory region.
Signed-off-by: Benjamin Berg
---
arch/um/drivers/virtio_uml.c | 2 +-
1 file changed, 1 insertion
From: Benjamin Berg
There is no point in either dumping the KASAN shadow memory or doing
copy-on-write after a fork on these memory regions.
This considerably speeds up coredump generation.
---
arch/um/os-Linux/mem.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/um/os
From: Benjamin Berg
Since commit a95b37e20db9 ("kbuild: get out of
") we can safely include these files in userspace code.
Doing so simplifies matters as options do not need to be exported via
asm-offsets.h anymore.
Signed-off-by: Benjamin Berg
---
arch/u
From: Benjamin Berg
The show_stack function had some code to detect double faults. However,
the logic is wrong and it would e.g. trigger if a WARNING happened
inside an IRQ.
Remove it without trying to add a new logic. The current behaviour,
which will just fault repeatedly until the IRQ stack
From: Benjamin Berg
The show_stack function had some code to detect double faults. However,
the logic is wrong and it would e.g. trigger if a WARNING happened
inside an IRQ.
Remove it without trying to add a new logic. The current behaviour,
which will just fault repeatedly until the IRQ stack
From: Benjamin Berg
There is no point in either dumping the KASAN shadow memory or doing
copy-on-write after a fork on these memory regions.
This considerably speeds up coredump generation.
Signed-off-by: Benjamin Berg
---
arch/um/os-Linux/mem.c | 12
1 file changed, 12
From: Benjamin Berg
There is no need to sync the stub code to "disk" for the other process
to see the correct memory. Drop the fsync there and remove the helper
function.
---
arch/um/include/shared/os.h | 1 -
arch/um/kernel/physmem.c| 1 -
arch/um/os-Linux/file.c | 6 -
From: Benjamin Berg
There is no need to sync the stub code to "disk" for the other process
to see the correct memory. Drop the fsync there and remove the helper
function.
Signed-off-by: Benjamin Berg
---
arch/um/include/shared/os.h | 1 -
arch/um/kernel/physmem.c| 1 -
arch/u
From: Benjamin Berg
This selects the THREAD_INFO_IN_TASK option for UM and changes the way
that the current task is discovered. This is trivial though, as UML
already tracks the current task in cpu_tasks[] and this can be used to
retrieve it.
Also remove the signal handler code that copies the
From: Benjamin Berg
Since commit a95b37e20db9 ("kbuild: get out of
") we can safely include these files in userspace code.
Doing so simplifies matters as options do not need to be exported via
asm-offsets.h anymore.
Signed-off-by: Benjamin Berg
---
arch/u
From: Benjamin Berg
Just remove the first entry as there is a second later on.
Signed-off-by: Benjamin Berg
---
arch/um/include/shared/common-offsets.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/um/include/shared/common-offsets.h
b/arch/um/include/shared/common-offsets.h
index
From: Benjamin Berg
Just remove the first entry as there is a second later on.
---
arch/um/include/shared/common-offsets.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/um/include/shared/common-offsets.h
b/arch/um/include/shared/common-offsets.h
index 1d00fc6b6e92..73f3a4792ed8
_regs(container_of(regs, struct pt_regs,
> regs));
> + panic("Segfault without recovery target");
> + }
> + mc_set_rip(mc, current->thread.segv_continue);
> + current->thread.segv_
From: Benjamin Berg
sparse reports that various places were missing the __user tag in casts.
In addition, one location was using 0 instead of NULL.
Signed-off-by: Benjamin Berg
---
arch/x86/um/signal.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86
From: Benjamin Berg
Some variables were not tagged with __user and another was not marked as
static even though it should be.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202410280655.golefwdg-...@intel.com/
Closes:
https://lore.kernel.org/oe-kbuild-all
to make it compatible with
the new mount APIs.
Benjamin
On Wed, 2024-10-30 at 13:43 +0530, Ritesh Raj Sarraf wrote:
> Hello,
>
>
> Recently I updated the UML package to Linux 6.11 in Debian. Upon it,
> it
> reports the below regression wherein UML cannot mount file systems
Hello Hajime,
On Sun, 2024-10-27 at 18:10 +0900, Hajime Tazaki wrote:
> thank you for your time looking at this.
>
> On Sat, 26 Oct 2024 19:19:08 +0900,
> Benjamin Berg wrote:
>
> > > - a crash on userspace programs crashes a UML kernel, not signaling
> > &
Hi,
On Thu, 2024-10-10 at 14:12 +0200, Johannes Berg wrote:
> > +++ b/arch/um/os-Linux/skas/process.c
> > @@ -1,9 +1,11 @@
> > // SPDX-License-Identifier: GPL-2.0
> > /*
> > + * Copyright (C) 2021 Benjamin Berg
> > * Copyright (C) 2015 Thomas Meyer (th
Hi,
On Thu, 2024-10-24 at 21:52 +0800, Tiwei Bie wrote:
> On 2024/10/23 22:08, Benjamin Berg wrote:
> [...]
>
>
> It looks the memcpy could trigger a crash when UML_SECCOMP is
> enabled:
>
> [...]
>
> It can be fixed with changes like below on my machine:
>
e host mcontex, which is what is needed in the
SIGSYS handler when using SECCOMP. The filter itself should be simple
as it just needs to catch all syscalls within valid userspace
executable memory[2] ranges.
Benjamin
[1] Maybe not surprising, as I have been working on a SECCOMP based UML
that does no
From: Benjamin Berg
Instead of always sharing the FDs with the userspace process, only hand
over the FDs needed for mmap when required. The idea is that userspace
might be able to force the stub into executing an mmap syscall, however,
it will not be able to manipulate the control flow
This adds the kernel side of the seccomp based process handling.
Co-authored-by: Johannes Berg
Signed-off-by: Benjamin Berg
Signed-off-by: Benjamin Berg
---
arch/um/include/shared/common-offsets.h| 2 +
arch/um/include/shared/os.h| 2 +-
arch/um/include/shared/skas
This detects seccomp support, sets the global using_seccomp variable and
initilizes the exec registers. For now, the implementation simply falls
through to the ptrace startup code, meaning that it is unused.
Signed-off-by: Benjamin Berg
Signed-off-by: Benjamin Berg
---
arch/um/include/shared
the IRQ handler, find the affected MM
and set its PID to -1 as well as the futex variable to FUTEX_IN_KERN.
This, together with futex returning -EINTR after the signal is
sufficient to implement a race-free detection of a child dying.
Signed-off-by: Benjamin Berg
Signed-off-by: Benjamin Berg
, but I do
not know why this difference exists. And, passing NULL can even result
in a crash.
Signed-off-by: Benjamin Berg
---
arch/um/os-Linux/skas/process.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux
This adds the stub side for the new seccomp process management code. In
this case we do register save/restore through the signal handler
mcontext. For the FS_BASE/GS_BASE register we need special handling.
Co-authored-by: Johannes Berg
Signed-off-by: Benjamin Berg
Signed-off-by: Benjamin Berg
perfectly fine for ptrace.
Signed-off-by: Benjamin Berg
---
arch/x86/um/os-Linux/mcontext.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/um/os-Linux/mcontext.c b/arch/x86/um/os-Linux/mcontext.c
index e80ab7d28117..1b0d95328b2c 100644
--- a/arch/x86/um/os-Linux
From: Benjamin Berg
Hi all,
here is an updated version of the SECCOMP patchset. The main improvement
to the previous RFC version is that now FP registers will work correctly
on 32 bit. I hope it is in a relatively good state overall, but I expect
we will not merge this into 6.13.
The patchset
: Benjamin Berg
Signed-off-by: Benjamin Berg
---
RFCv2:
- Proper FP register handling
---
arch/x86/um/os-Linux/mcontext.c | 220 ++-
arch/x86/um/ptrace.c | 76 ++---
arch/x86/um/shared/sysdep/mcontext.h | 10 ++
3 files changed, 286 insertions
Add the UML_SECCOMP configuration options. The next commits will add the
support itself in smaller chunks.
Only x86_64 will be supported for now.
Signed-off-by: Benjamin Berg
---
RFCv2:
- Remove "default n"
---
arch/um/Kconfig | 19 +++
1 file changed, 19 insertion
From: Benjamin Berg
The PTRACE_GETREGSET API has now existed since Linux 2.6.33. The XSAVE
CPU feature should also be sufficiently common to be able to rely on it.
With this, define our internal FP state to be the hosts XSAVE data. Add
discovery for the hosts XSAVE size and place the FP
From: Benjamin Berg
The PTRACE_GETREGSET API has now existed since Linux 2.6.33. The XSAVE
CPU feature should also be sufficiently common to be able to rely on it.
With this, define our internal FP state to be the hosts XSAVE data. Add
discovery for the hosts XSAVE size and place the FP
From: Benjamin Berg
The PTRACE_GETREGSET API has now existed since Linux 2.6.33. The XSAVE
CPU feature should also be sufficiently common to be able to rely on it.
With this, define our internal FP state to be the hosts XSAVE data. Add
discovery for the hosts XSAVE size and place the FP
Hi,
I just noticed that this is not completely correct. readlink() does not
append a NULL byte, so you'll probably want to make the buffer one byte
longer and either initialize it or set buf[ret] = '\0' (after the
truncation check).
Benjamin
On Thu, 2024-10-10 at 16:14 +0200
way all of these pretty much sound reasonable. We don't need much
> to happen in the stub here, simpler is better.
Yeah, and I guess c) really is sufficient by itself.
Benjamin
Hi,
On Thu, 2024-10-17 at 15:17 +0800, David Gow wrote:
> On Thu, 19 Sept 2024 at 20:45, Benjamin Berg
> wrote:
> >
> > [SNIP]
>
> It turns out that this breaks the KUnit user alloc helpers on x86_64,
> at least on my machine.
>
> This can be reproduced with:
Hi Nathan,
On Tue, 2024-10-15 at 19:34 -0700, Nathan Chancellor wrote:
> On Thu, Sep 19, 2024 at 02:45:03PM +0200, Benjamin Berg wrote:
> ...
> > diff --git a/arch/um/kernel/skas/Makefile
> > b/arch/um/kernel/skas/Makefile
> > index 6f86d53e3d69..fbb61968055f 100644
>
t might make it more clear how everything ties together.
Anyway, the change looks good to me.
Benjamin
Reviewed-by: Benjamin Berg
> Signed-off-by: Tiwei Bie
> ---
> arch/um/include/asm/pgtable.h | 40 ---
> arch/um/include/shared/os.h | 2 -
>
1 - 100 of 379 matches
Mail list logo
