On Wed, Dec 4, 2024 at 5:53 PM Johannes Berg wrote:
> On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
> >
> > +static int os_x86_arch_prctl(int pid, int option, unsigned long *arg2)
> > +{
> > + if (host_has_fsgsbase) {
> > + switch (option) {
> > + case ARCH_SE
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 vsyscall.
> > >
> > > Those mappings are readon
Hi Hajime,
kernel test robot noticed the following build warnings:
[auto build test WARNING on bed2cc482600296fe04edbc38005ba2851449c10]
url:
https://github.com/intel-lab-lkp/linux/commits/Hajime-Tazaki/fs-binfmt_elf_efpic-add-architecture-hook-elf_arch_finalize_exec/20241203-163016
base:
On Wed, Dec 4, 2024 at 6:04 AM Benjamin Berg wrote:
>
> Hi,
>
> On Mon, 2024-11-25 at 20:20 +, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Seal vdso, vvar, sigpage, uprobes and vsyscall.
> >
> > Those mappings are readonly or executable only, sealing can protect
> > them from ever ch
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
>
> +static int os_x86_arch_prctl(int pid, int option, unsigned long *arg2)
> +{
> + if (host_has_fsgsbase) {
> + switch (option) {
> + case ARCH_SET_FS:
> + wrfsbase(*arg2);
> +
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
>
> +++ b/arch/um/kernel/process.c
> @@ -117,13 +117,17 @@ void new_thread_handler(void)
>* callback returns only if the kernel thread execs a process
>*/
> fn(arg);
> +#ifndef CONFIG_MMU
> + arch_switch_to(current);
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
>
> +#ifndef CONFIG_MMU
> +extern int um_zpoline_enabled;
> +#endif
That doesn't make sense, there's no good reason these two mechanisms
need to be mutually exclusive.
I think you should leave out zpoline initially, get all the other stuff
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
> This commit adds a mechanism to hook syscalls for unmodified userspace
> programs used under UML in !MMU mode. The mechanism, called zpoline,
>
I think you should just leave this out of the first version entirely.
johannes
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
> This commit introduces an entry point of syscall interface for !MMU
> mode. It uses an entry function, __kernel_vsyscall, a kernel-wide global
> symbol accessible from any locations.
>
> Although it isn't in the scope of this commit, it can
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
>
> +++ b/arch/um/include/asm/futex.h
> @@ -8,7 +8,11 @@
>
>
> int arch_futex_atomic_op_inuser(int op, u32 oparg, int *oval, u32 __user
> *uaddr);
> +#ifdef CONFIG_MMU
> int futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
>
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
>
> arch/um/include/asm/Kbuild | 1 +
>
> arch/x86/um/asm/module.h | 24
>
These changes could be a separate cleanup?
johannes
On Tue, 2024-12-03 at 13:22 +0900, Hajime Tazaki wrote:
> This is a series of patches of nommu arch addition to UML.
Please next time you resend this, don't hide it in the old thread :)
johannes
Hi,
On Mon, 2024-11-25 at 20:20 +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing or unmapped during the life time of the process.
> For complete
13 matches
Mail list logo