um: an arm64 subarch for User Mode Linux
Hi,
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.
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.
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.
Thanks,
Oleksii
Richard Weinberger
maintainer----- Ursprüngliche Mail -----
Quoted 11 lines
Von: [email protected]
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. :-)
Quoted 6 lines
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 toNT_ARM_SYSTEM_CALLat
aPTRACE_SYSCALLstop. That fails under a seccomp filter, though: arm64
Quoted 8 lines
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.
Quoted 30 lines
Modules reuse
arch/arm64/kernel/module.candmodule-plts.cinstead of a second copy, the wayarch/x86/umdoes. That does mean pulling two files out
ofarch/arm64.Two changes are performance only. The stub handoff skips
FUTEX_WAKEwhen nobody is parked and spins againstCNTVCT_EL0before 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 usKnown 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-bitstub_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.
Quoted 4 lines
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