Date:   Tue, 18 May 2021 15:02:07 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     "Amanieu d'Antras" <amanieu@...il.com>
Cc:     Ryan Houdek <Houdek.Ryan@...-emu.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Steven Price <steven.price@....com>,
        David Laight <David.Laight@...lab.com>,
        Mark Brown <broonie@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH v4 8/8] arm64: Allow 64-bit tasks to invoke compat syscalls

On Tue, May 18, 2021 at 11:06 AM Amanieu d'Antras <amanieu@...il.com> wrote:
>
> Setting bit 31 in x8 when performing a syscall will do the following:
> - The remainder of x8 is treated as a compat syscall number and is used
>   to index the compat syscall table.
> - in_compat_syscall will return true for the duration of the syscall.
> - VM allocations performed by the syscall will be located in the lower
>   4G of the address space.
> - Interrupted syscalls are properly restarted as compat syscalls.
> - Seccomp will treats the syscall as having AUDIT_ARCH_ARM instead of
>   AUDIT_ARCH_AARCH64. This affects the arch value seen by seccomp
>   filters and reported by SIGSYS.
> - PTRACE_GET_SYSCALL_INFO also treats the syscall as having
>   AUDIT_ARCH_ARM. Recent versions of strace will correctly report the
>   system call name and parameters when an AArch64 task mixes 32-bit and
>   64-bit syscalls.
>
> Previously, setting bit 31 of the syscall number would always cause the
> sygscall to return ENOSYS. This allows user programs to reliably detect
> kernel support for compat syscall by trying a simple syscall such as
> getpid.
>
> The AArch32-private compat syscalls (__ARM_NR_compat_*) are not exposed
> through this interface. These syscalls do not make sense in the context
> of an AArch64 task.
>
> Signed-off-by: Amanieu d'Antras <amanieu@...il.com>
> Co-developed-by: Ryan Houdek <Houdek.Ryan@...-emu.org>
> Signed-off-by: Ryan Houdek <Houdek.Ryan@...-emu.org>

I'm still undecided about this approach. It is an easy way to expose the 32-bit
ABIs, it mostly copies what x86-64 already does with 32-bit syscalls and
it doesn't expose a lot of attack surface that isn't already exposed to normal
32-bit tasks running compat mode.

On the other hand, exposing the entire aarch32 syscall set seems both
too broad and not broad enough: Half of the system calls behave the
exact same way in native and compat mode, so they wouldn't need to
be exposed like this, a lot of others are trivially emulated in user space
by calling the native versions. The syscalls that are actually hard to do
such as ioctl() or the signal handling will work for aarch32 emulation, but
they are still insufficient to correctly emulate other 32-bit architectures
that have a slightly different ABI. This means the interface is a fairly good
fit for Tango, but much less so for FEX.

It's also worth pointing out that this approach has a few things in common
with Yury's ilp32 tree at https://github.com/norov/linux/tree/ilp32-5.2
Unlike the x86 x32 mode, that port however does not allow calling compat
syscalls from normal 64-bit tasks but rather keys the syscall entry point
off the executable format., which wouldn't work here. It also uses the
asm-generic system call numbers instead of the arm32 syscall numbers.

I assume you have already considered or tried the alternative approach of
only adding a minimal set of syscalls that are needed for the emulation.
Having a way to limit the address space for mmap() and similar
system calls sounds like a generally useful addition, and having an
extended variant of ioctl() that lets you pick the target ABI (arm32, x86-32,
...) on supported drivers would probably be better for FEX. Can you
explain the tradeoffs that led you towards duplicating the syscall
entry points instead?

         Arnd

Powered by blists - more mailing lists