linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Steven Price <steven.price@arm.com>
To: Amanieu d'Antras <amanieu@gmail.com>
Cc: Arnd Bergmann <arnd@kernel.org>,
	Ryan Houdek <Houdek.Ryan@fex-emu.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	David Laight <David.Laight@aculab.com>,
	Mark Brown <broonie@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND PATCH v4 8/8] arm64: Allow 64-bit tasks to invoke compat syscalls
Date: Fri, 21 May 2021 09:51:01 +0100	[thread overview]
Message-ID: <1c2bd27a-1c96-f154-ed18-f33630b109b1@arm.com> (raw)
In-Reply-To: <CA+y5pbRwgpctUOBzzscT9XMN9LM2qraPNg6K6onFcpQaaFDYkQ@mail.gmail.com>

On 19/05/2021 17:14, Amanieu d'Antras wrote:
> On Wed, May 19, 2021 at 4:30 PM Steven Price <steven.price@arm.com> wrote:
>> Perhaps I'm missing something, but surely some syscalls that would be
>> native on 32 bit will have to be translated by Tango to 64 bit syscalls
>> to do the right thing? E.g. from the previous patch compat sigreturn
>> isn't available.
> 
> That's correct.
> 
> Tango handles syscalls in 3 different ways:
> - ~20 syscalls are completely emulated in userspace or through 64-bit
> syscalls. E.g. sigaction, sigreturn, clone, exit.
> - Another ~50 syscalls have various forms of pre/post-processing, but
> are otherwise passed on to the kernel compat syscall handler. E.g.
> open, mmap, ptrace.
> - The remaining syscalls are passed on to the kernel compat syscall
> handler directly.
> 
> The first group of ~20 syscalls will effectively bypass the
> user-specified seccomp filter: any 64-bit syscalls used to emulate
> them will be whitelisted. I consider this an acceptable limitation to
> Tango's seccomp support since I see no viable way of supporting
> seccomp filtering for these syscalls.

I agree it's difficult - the only 'solution' I can see is like I said to
emulate the BPF code in user space.

>> In those cases to correctly emulate seccomp, isn't Tango is going to
>> have to implement the seccomp filter in user space?
> 
> I have not implemented user-mode seccomp emulation because it can
> trivially be bypassed by spawning a 64-bit child process which runs
> outside Tango. Even when spawning another translated process, the
> user-mode filter will not be preserved across an execve.

Clearly if you have user-mode seccomp emulation then you'd hook execve
and either install the real BPF filter (if spawning a 64 bit child
outside Tango) or ensure that the user-mode emulation is passed on to
the child (if running within Tango).

You already have a potential 'issue' here of a 64 bit process setting up
a seccomp filter and then execve()ing a 32 bit (Tango'd) process. The
set of syscalls needed for the system which supports AArch32 natively is
going to be different from the syscalls needed for Tango. (Fundamentally
this is a major limitation with the whole seccomp syscall filtering
approach).

>> I guess the question comes down to how big a hole is
>> syscall_in_tango_whitelist() - if Tango only requires a small set of
>> syscalls then there is still some security benefit, but otherwise this
>> doesn't seem like a particularly big benefit considering you're already
>> going to need the BPF infrastructure in user space.
> 
> Currently Tango only whitelists ~50 syscalls, which is small enough to
> provide security benefits and definitely better than not supporting
> seccomp at all.

Agreed, and I don't want to imply that this approach is necessarily
wrong. But given that the approach of getting the kernel to do the
compat syscall filtering is not perfect, I'm not sure in itself it's a
great justification for needing the kernel to support all the compat
syscalls.

One other thought: I suspect in practise there aren't actually many
variations in the BPF programs used with seccomp. It may well be quite
possible to convert the 32-bit syscall filtering programs to filter the
equivalent 64-bit syscalls that Tango would use. Sadly this would be
fragile if a program used a BPF program which didn't follow the "normal"
pattern.

Steve

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-21  8:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18  9:06 [RESEND PATCH v4 0/8] " 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
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 [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=1c2bd27a-1c96-f154-ed18-f33630b109b1@arm.com \
    --to=steven.price@arm.com \
    --cc=David.Laight@aculab.com \
    --cc=Houdek.Ryan@fex-emu.org \
    --cc=amanieu@gmail.com \
    --cc=arnd@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=will@kernel.org \
    --subject='Re: [RESEND PATCH v4 8/8] arm64: Allow 64-bit tasks to invoke compat syscalls' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).