archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <>
To: "Amanieu d'Antras" <>
Cc: Ryan Houdek <>,
	Catalin Marinas <>,
	 Will Deacon <>,
	Mark Rutland <>,
	 Steven Price <>,
	David Laight <>,
	 Mark Brown <>,
	Linux ARM <>,
	 Linux Kernel Mailing List <>
Subject: Re: [RESEND PATCH v4 8/8] arm64: Allow 64-bit tasks to invoke compat syscalls
Date: Tue, 18 May 2021 15:02:07 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, May 18, 2021 at 11:06 AM Amanieu d'Antras <> 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 <>
> Co-developed-by: Ryan Houdek <>
> Signed-off-by: Ryan Houdek <>

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
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?


linux-arm-kernel mailing list

  reply	other threads:[~2021-05-18 13:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18  9:06 [RESEND PATCH v4 0/8] arm64: Allow 64-bit tasks to invoke compat syscalls Amanieu d'Antras
2021-05-18  9:06 ` [RESEND PATCH v4 1/8] mm: Add arch_get_mmap_base_topdown macro Amanieu d'Antras
2021-05-18  9:06 ` [RESEND PATCH v4 2/8] hugetlbfs: Use arch_get_mmap_* macros Amanieu d'Antras
2021-05-18  9:06 ` [RESEND PATCH v4 3/8] mm: Support mmap_compat_base with the generic layout Amanieu d'Antras
2021-05-18  9:06 ` [RESEND PATCH v4 4/8] arm64: Separate in_compat_syscall from is_compat_task Amanieu d'Antras
2021-05-18  9:06 ` [RESEND PATCH v4 5/8] arm64: mm: Use HAVE_ARCH_COMPAT_MMAP_BASES Amanieu d'Antras
2021-05-18  9:06 ` [RESEND PATCH v4 6/8] arm64: Add a compat syscall flag to thread_info Amanieu d'Antras
2021-05-18  9:06 ` [RESEND PATCH v4 7/8] arm64: Forbid calling compat sigreturn from 64-bit tasks Amanieu d'Antras
2021-05-18  9:06 ` [RESEND PATCH v4 8/8] arm64: Allow 64-bit tasks to invoke compat syscalls Amanieu d'Antras
2021-05-18 13:02   ` Arnd Bergmann [this message]
2021-05-18 20:26     ` David Laight
2021-05-18 22:41       ` Ryan Houdek
2021-05-18 23:51     ` Amanieu d'Antras
2021-05-19 15:30       ` Steven Price
2021-05-19 16:14         ` Amanieu d'Antras
2021-05-21  8:51           ` Steven Price
2021-05-21 19:18             ` Amanieu d'Antras
2021-05-24 11:20               ` Steven Price
2021-05-24 12:38                 ` David Laight
2021-05-18 23:52     ` Ryan Houdek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).