From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2AA3C4707A for ; Fri, 21 May 2021 19:21:10 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1EE87613D0 for ; Fri, 21 May 2021 19:21:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1EE87613D0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=IWebIGjRIQ63ulPdvGbmq6pN3ScaXMDtw4YtGwE0hd8=; b=NnFDzeVcSVuAi6ehrqtSF58GWL tjQZLD2otP3OYmCuBHUjFjImJoQdPyIraTN1P1eVQNqoYJxdZ+jX/TGgXj+yC+N5S9odrKyTcQ+tN vI1FwSJUBmSSZ6peR6RzxBMVOdbpL24TBC7ZtTEcyPS9LO5qPHaHZIDuB/SnMBEJ9LYl3H1HzeAKl +zh4Ce4R3IKnnHGC28ohsrYHBtlDe4NWoU399ejS/OPQT8H46topKdRfreVNdQJkOyz5vjgXZUrzN zFUwvcr7MtlAlDH4GWgF3er7uDZ5xVDO7i2aOE/5rzQOlHbW73p2ViKZoXA63l18a/qtukb3eP2Cd 7zoVa9+A==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lkAfz-000pwK-GW; Fri, 21 May 2021 19:19:15 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lkAfs-000pv3-Tl for linux-arm-kernel@desiato.infradead.org; Fri, 21 May 2021 19:19:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=A0bOSvQvIFoNvuO08SOXCaee1LAs7SSvjM47STchOkk=; b=NAnOFyOylzxej4XzDog4s1zL8h iqLZpB1VHecFEcqiw3mgCTqUhl9S9uJxD9neUoPX77nX5NyiS7LGj193BzJ9w2CA6QdPkZDrGK+Jv tbmxj4U9lJDf4GVBhL4I6ik8Oosbl2s7X+Fvb8JwSzDkG7UtFqFxhUq+uuGokqmAWhCuDpdNFm9A4 n+4Yq/EgvfTlXtjH32gq0DJYL8g0o/wTDBNGZ6msu0wqTEMm8RByvenP1FEZhHyHaCTwxrmzzC+KS WSrY13KhyXxigpFkWcK8wIujy5KaSA1TiQuuTpe93TdEdgKG4P9MTHpw7sC1cNr8sHWQoCDg+FL/f p2BRdADw==; Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lkAfp-00HNMw-O5 for linux-arm-kernel@lists.infradead.org; Fri, 21 May 2021 19:19:07 +0000 Received: by mail-ed1-x534.google.com with SMTP id df21so24507357edb.3 for ; Fri, 21 May 2021 12:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A0bOSvQvIFoNvuO08SOXCaee1LAs7SSvjM47STchOkk=; b=WAEzSBCnxT/1BObN8G+M1p7trniZRWUzovbAuER9lI+APkD3WYl8njHOV/oXKOxw3v 0lB64Ddw4sJEzRgVDXDMlb7dD2kb6SYtLv3aE6gWzYJKDQD8vlzOHQ3oR+kq8M20bMYe 1DFpsArMo4hjTgYaR2rqa0Z2WZ5z/uOhNsqa+XtZGW7n9hEHOKZhC3uizie/oWSSE+fX 9RjZAXPcYoRDHHd7shIiGCqGsicxzGh0pHIcxPLfBGxRCX+PDTJyn3oOWnKdia77gdyC oIocvnVDfp0VxvUZo0sQJ+EMkvXt5A1cYaZzKYpDoNXrncDGlTznW9IQ1uLB4yiUjnGF hKxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A0bOSvQvIFoNvuO08SOXCaee1LAs7SSvjM47STchOkk=; b=edZ+FG6u7DRuZaPxf8y63J3csQDD2BTxn2ms3/oKmfWuD6/YiRhM6rE+VUErfCZOf4 h73E4eodtESwPDmE+lPufrJp8t+1ZhibHr/HZmuHXTVD7eu7DMOYikHvPuiS8u7PkbRQ WpnwDhB5p5qftNmnLEapZP9pgdYKU5U0MTv5D7Eog4AzqidBTU6v97FES8hYbX/MyYMq D3hLd5/TC7e2rs4AYqsqd01oBB/h7t4erShb6sRNoX+Zuxo0JnC3u2br1ZSuTjxENGRG D6a3/C3d4Bqv1j/yzYUElS3BOqyDVpUYU0QZCalLRjOZJnUcHqsm27lZ98pmfQCK9QmH xKOg== X-Gm-Message-State: AOAM533kXKN/nU9UW9xqDP8CMR+/krYADBVR5O5tgyPKZ3NZDI3eYw3y 9BGzBpby7/90IaA1MSYmLl/OSgUdHg7K5uAhjOA= X-Google-Smtp-Source: ABdhPJxy/tsOlhxVkaev+BLzhjxfSBrGKeHQy2re7EosrmSkiZQ/auNR0gOHbYIynQVu4ilnreNrudnMgRqMkD8Z2S8= X-Received: by 2002:aa7:d893:: with SMTP id u19mr13027947edq.258.1621624742282; Fri, 21 May 2021 12:19:02 -0700 (PDT) MIME-Version: 1.0 References: <20210518090658.9519-1-amanieu@gmail.com> <20210518090658.9519-9-amanieu@gmail.com> <14982d7d-bee1-6c25-8b18-123c29959f52@arm.com> <1c2bd27a-1c96-f154-ed18-f33630b109b1@arm.com> In-Reply-To: <1c2bd27a-1c96-f154-ed18-f33630b109b1@arm.com> From: "Amanieu d'Antras" Date: Fri, 21 May 2021 20:18:25 +0100 Message-ID: Subject: Re: [RESEND PATCH v4 8/8] arm64: Allow 64-bit tasks to invoke compat syscalls To: Steven Price Cc: Arnd Bergmann , Ryan Houdek , Catalin Marinas , Will Deacon , Mark Rutland , David Laight , Mark Brown , Linux ARM , Linux Kernel Mailing List X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210521_121905_826567_732EE9BD X-CRM114-Status: GOOD ( 36.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, May 21, 2021 at 9:51 AM Steven Price wrote: > >> 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). Spawning another process is just an example. Fundamentally, Tango is not intended or designed to be a sandbox around the 32-bit code. For example, many of the newer ioctls use u64 instead of a pointer type to avoid the need for a compat_ioctl handler. This means that such ioctls could be abused to read/write any address in the process address space, including the code that is performing the usermode seccomp emulation. > 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). The specific example I had in mind here is Android which installs a global seccomp filter on the zygote process from which app processes are forked from. This filter is designed for mixed arm32/arm64 systems and therefore has syscall whitelists for both AArch32 and AArch64. This filter allows 32-bit processes to spawn 64-bit processes and vice-versa: for example, many 32-bit apps will invoke another 32-bit executable via system() which uses a 64-bit /system/bin/sh. > >> 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. I feel that exposing all compat syscalls to 64-bit processes is better than the alternative of only exposing a subset of them. Of the top of my head I can think of quite a few compat syscalls that cannot be fully emulated in userspace and would need to be exposed in the kernel: - mmap/mremap/shmat/io_setup: anything that allocates VM space needs to return a pointer in the low 4GB. - ioctl: too many variants to reasonably maintain a separate compat layer in userspace. - getdents/lseek: ext4 uses 32-bit directory offsets for 32-bit processes. - get_robust_list/set_robust_list: different in-memory ABI for 32/64-bit processes. - open: don't force O_LARGEFILE for 32-bit processes. - io_uring_create: different in-memory ABI for 32/64-bit processes. - (and possibly many others) Also consider the churn involved when adding a new syscall which behaves differently in compat processes: rather than just using in_compat_syscall() or wiring up a COMPAT_SYSCALL_DEFINE, a compat variant of this syscall would also need to be added to the 64-bit syscall table to support translation layers like Tango and FEX. > 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. This might work for simple filters that only look at the syscall number, but becomes much harder when the filter also inspects the syscall arguments. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel