Re: [RFC] um: an arm64 subarch for User Mode Linux

[Richard Weinberger <richard@nod.at>]

----- Ursprüngliche Mail -----
> Von: contact@zalexdev.com
> I have ARCH=um SUBARCH=arm64 working -- 33 patches on uml/next. Before
> sending that many to the list I would like to know if it is wanted, and
> in
> what shape.
> 
>   https://github.com/zalexdev/linux-um-arm64   (branch um-arm64)
> 
> Boots Alpine and Debian at 4K and 16K pages, SECCOMP and ptrace
> userspace,
> loadable modules.

Nice. :-)
 
> The part I want an opinion on is syscall interception on hosts without
> PTRACE_SYSEMU, since 5.3 is a recent floor for arm64 and phones ship
> 4.19.
> There the guest syscall is cancelled by writing -1 to NT_ARM_SYSTEM_CALL
> at
> a PTRACE_SYSCALL stop. That fails under a seccomp filter, though: arm64
> reports the ptrace stop before running seccomp, so the filter sees the
> -1
> and an Android app sandbox kills the tracee. So the third path
> substitutes
> getppid(2) for the guest's call -- the call still does not run, but a
> syscall does execute on the guest's behalf. Is that acceptable? nosysemu
> and nocancel select the fallbacks on any host, so they are testable
> without a 4.19 machine.

Well, it's reasonable to require a non-ancient host kernel.

> Modules reuse arch/arm64/kernel/module.c and module-plts.c instead of a
> second copy, the way arch/x86/um does. That does mean pulling two files
> out
> of arch/arm64.
> 
> Two changes are performance only. The stub handoff skips FUTEX_WAKE when
> nobody is parked and spins against CNTVCT_EL0 before parking; anonymous
> faults are batched onto the handoff that was happening anyway.
> Snapdragon
> 870, SECCOMP mode, medians of 7 interleaved rounds:
> 
>   syscall  9.841 -> 1.987 us
>   openat  20.223 -> 4.501 us
>   fault   24.592 -> 11.076 us
> 
> Known problems: no 32-bit compat, UP only, and "BUG: Bad rss-counter
> state
> ... type:MM_FILEPAGES val:1" once per exiting process under Debian but
> not
> under Alpine on the same kernel. I have not found that one and would not
> expect it merged as is.
> 
> About a third of the patches are not arm64 -- generic um/ fixes and two
> x86
> ones, including a missing 32-bit stub_seccomp_save_state -- but they sit
> on
> top of the subarch commit and do not apply alone. I can rebase them into
> a
> separate series first if that is more useful.
> 
> I cannot commit to maintaining this long-term. Happy to respin or split
> it
> however you want; say the word and I will send the series with
> git send-email.

Patches are welcome, but don't expect others to do the hard work.

Thanks,
//richard