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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 8B1C6C433B4 for ; Tue, 18 May 2021 22:42:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5489961209 for ; Tue, 18 May 2021 22:42:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352802AbhERWnS (ORCPT ); Tue, 18 May 2021 18:43:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230251AbhERWnR (ORCPT ); Tue, 18 May 2021 18:43:17 -0400 Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FAE8C061573 for ; Tue, 18 May 2021 15:41:58 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id l70so8060545pga.1 for ; Tue, 18 May 2021 15:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fex-emu.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z2Cd9m3HAXD4prG1F8AREQq6eZbmY8vxuoKsL7ZDrzQ=; b=lSvV8sTJaZH2x6iOJSR92xMpFIbq6D4PWZYs/201uhvARUhw8w37oXAjgs+TW6u876 RFW9SeBCuMdlqdCipkbD2mhk0fCKgvb8kddr8nuikkVj+maUO0hW1ti19pQ+tPD0P8uE Roxsz3gkT7v36M5Bc+Bz/ilm1I5ni7Iq6DnTD/nyOsAIWLlo0enFyIoYBrP5IuMFX+LL wklJYbEYZSzQ8KhGc8ZFtpuE81Z/Sn8/QF9xuI84qZctQnEClH7Wk5lHeyUIhtpyRA/F MPO/qzZykVhN46Qk7M5AoXvSW20YxcsD7tA7fXOw5EertA4HxEZbbq6JwGCESgDRN5oN Eg6w== 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=z2Cd9m3HAXD4prG1F8AREQq6eZbmY8vxuoKsL7ZDrzQ=; b=FJeay0NJu0RrysENleioSz9k0oCjyHzztB+5JtFGocW46UQ6y1MiAyboXl9JarE8br OtA0hjjnztan+IFzm3NJvsJ3o5gQojiAQWZmHCzXqlFDlfa2mEHtjHCTX+2xFM/yvERQ 2uPqJ4RMYZiZoDBWvgdigCA0qjAFECSskuoEHStmyXIcr2uZjttGzHBY5cKf7ftDc5L/ eJ3hweJfJfqZwu9/uJYUIMp57z3rRPnkUr53ZGrt6ABEcHCrtcCwRuTwhA+jPUx1FxsT fTS9vvjr9OAxyqiI4SpSa5YnOjuIqzoTe7AefDV3nErrvwajMZp0otap/7nls5QQEfju J7wQ== X-Gm-Message-State: AOAM530wrQDGHiGijR+2afu+zT7oCDYEaojo86vW0/3KZ31+4qd+x+IR kWhjExlVtNfdtUMnpIHD2NtgEi6S1ffntOFjv2CPrOnxergXJw== X-Google-Smtp-Source: ABdhPJymr0dVfOGB6otFby+f7jaFDsq9G0xea2z0kCF4Oh90SYmcOez74I4GRA7vUL2MHhdh1+Or6EC0I+KNkkJ5S98= X-Received: by 2002:a63:571d:: with SMTP id l29mr7472503pgb.179.1621377717611; Tue, 18 May 2021 15:41:57 -0700 (PDT) MIME-Version: 1.0 References: <20210518090658.9519-1-amanieu@gmail.com> <20210518090658.9519-9-amanieu@gmail.com> <3cb1d369e5e8431284e527e3e74fa6f2@AcuMS.aculab.com> In-Reply-To: <3cb1d369e5e8431284e527e3e74fa6f2@AcuMS.aculab.com> From: Ryan Houdek Date: Tue, 18 May 2021 15:41:47 -0700 Message-ID: Subject: Re: [RESEND PATCH v4 8/8] arm64: Allow 64-bit tasks to invoke compat syscalls To: David Laight Cc: Arnd Bergmann , "Amanieu d'Antras" , Catalin Marinas , Will Deacon , Mark Rutland , Steven Price , Mark Brown , Linux ARM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 18, 2021 at 1:26 PM David Laight wrote: > > From: Arnd Bergmann > > Sent: 18 May 2021 14:02 > ... > > > > 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. > > To my mind because the kernel already contains the emulation code > there isn't much point trying to replicate it in userspace. > > OTOH I think they are trying to emulate x86 system calls not arm ones. > So the structure layouts don't always match. > However it is probably a lot nearer than the 64bit arm. Take care not to conflate the Tango and FEX project needs here. Tango is doing aarch32->aarch64 translation. So they are translating aarch32 syscalls. FEX is doing {x86, x86-64}->aarch64 translation. The simplicity of the interface helps Tango more than FEX in this regard. Since FEX likely still needs userspace fixups to *some* structures. > > Whether including some of the 'x32' code in an arm kernel will > help is another matter - it might be a useful source of differences. > > Am I also right in thinking that this isn't actually needed as part > of a 'generic' ARM kernel? Just ones for some specific platforms? This isn't correct from FEX's viewpoint. FEX isn't a product that will be shipping on any specific platform; The user is expected to just install FEX on their ARMv8.0+ device of choice. After they install FEX then they will freely be able to install *any* x86/x86-64 software and run it. The primary target is running full fledged games from the user's Steam library, but it can be anything the user desires. For context we have users running FEX on Lenovo c630, Apple M1, HardKernel SBCs, and recently some randomly picked Android devices. I can't speak on Tango's behalf here since I don't know their user ecosystem. > > David > > (Oh - I'm not involved in the project and will probably never use it.) > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) 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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 B6752C433B4 for ; Tue, 18 May 2021 22:43:41 +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 391FD60E09 for ; Tue, 18 May 2021 22:43:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 391FD60E09 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fex-emu.org 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=wE009uPYIxV7EnTkeBG5ptnalZG8D7Clrbxux4BhFDM=; b=W7g8ugk87teEup7udhg64GUAO pLPUMPTxxU5WpLIaeBPaGf4z3tKncaARupfdWDCCs4zxiAFggAcWaOXrr3DiOfOJgr4Ri0TIc4mwX +pE17JEKyfUE3LcaBwxcwFM6BurxWQb4m9uluR8idUOl52uCSwn1aLWivbCTGfojMl9ITgiyP4CsY CQhU1DxQHDPcCUnyNGC+FPE6f6pXO8yp8mPl0eTRDuTQG3jiPUHR/Q5IRWjCFTNGrNomN0Rmlzn2g 8+N7u3LY9RSUd1FvOWVGWpt9PMdZYHscAXFq0qfosjflb0J2J/GXlXvj7zFZKB/I+QSwqv4S1/QfD h/82+CCPA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lj8Pf-0025f2-05; Tue, 18 May 2021 22:42:07 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lj8Pa-0025eA-7L for linux-arm-kernel@desiato.infradead.org; Tue, 18 May 2021 22:42:03 +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=z2Cd9m3HAXD4prG1F8AREQq6eZbmY8vxuoKsL7ZDrzQ=; b=emNwBxHO2xyQB6Qeg/aM/FaYhR m3SUEyacvHeaZfPbZxBieT8e6fdXe4OR0yZX/DaE098cMSsba3jIeyhE1MgBHK59eFLRH0YUB7WR7 xGy1LDd47MgjXo5hU0tDC5RycNUZx0kEG0JGUFl9o3mJP+P3RBFtB1a+Bt+N9xoZ0MxgXk9kTprLh 4Dqza3wpXkRqjsjkd5zDILEafmLDvPR/IQLMrImCmW5ok9ppN343/88tnoYF/v6qseIYXFJEnEmaO z+91VfLbkgzHIETWGlTNMo9gqz9M9F7WKzmZLovBYYaLAvgNwwSzpbHP1zx528nOB+xTvZeP2dnHF Oy47M2ww==; Received: from mail-pg1-x533.google.com ([2607:f8b0:4864:20::533]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lj8PX-00F0VT-GZ for linux-arm-kernel@lists.infradead.org; Tue, 18 May 2021 22:42:00 +0000 Received: by mail-pg1-x533.google.com with SMTP id q15so8032335pgg.12 for ; Tue, 18 May 2021 15:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fex-emu.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z2Cd9m3HAXD4prG1F8AREQq6eZbmY8vxuoKsL7ZDrzQ=; b=lSvV8sTJaZH2x6iOJSR92xMpFIbq6D4PWZYs/201uhvARUhw8w37oXAjgs+TW6u876 RFW9SeBCuMdlqdCipkbD2mhk0fCKgvb8kddr8nuikkVj+maUO0hW1ti19pQ+tPD0P8uE Roxsz3gkT7v36M5Bc+Bz/ilm1I5ni7Iq6DnTD/nyOsAIWLlo0enFyIoYBrP5IuMFX+LL wklJYbEYZSzQ8KhGc8ZFtpuE81Z/Sn8/QF9xuI84qZctQnEClH7Wk5lHeyUIhtpyRA/F MPO/qzZykVhN46Qk7M5AoXvSW20YxcsD7tA7fXOw5EertA4HxEZbbq6JwGCESgDRN5oN Eg6w== 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=z2Cd9m3HAXD4prG1F8AREQq6eZbmY8vxuoKsL7ZDrzQ=; b=THAO4i6zQQRjlKGLFGL0Ne+BAimTAFf5D6O+nklHOo8AKiF4pHewRQQj6AQX5tsqfZ 0tIEtf7Aioqx2FPlQebuKPEFnn/p+vsrK/DE8wD2B1pMIqXggyg7BGmajPVEMDHAfQNo qb9kfKGWsyYoWVT4X0sWPVUvqAvJ+8U177bSaCj4gWdFUTDNPjmqL86Fbqw3Qpi/qW/B GenYq1SUkxUK3M7QEeQ1cfDND+bQdGw7F93zFs3mjc6UevXldYh8WCIkYoP7O5ckSPdL RnjUA6rDZlmpk0EI1hrxve5E2DNtAMEk1NbO0eHC/u4Wya3HNHeThNfuK7MpVVg5TX+q DOPg== X-Gm-Message-State: AOAM533sBi+OtcGlUSkHcBz06/IANtyjCjKrZshb96+WV2ksVjCYWb7b vGQilWnIgcQiZjWcP0DDVYCUQTC1pHKlyJDE0FqhfA== X-Google-Smtp-Source: ABdhPJymr0dVfOGB6otFby+f7jaFDsq9G0xea2z0kCF4Oh90SYmcOez74I4GRA7vUL2MHhdh1+Or6EC0I+KNkkJ5S98= X-Received: by 2002:a63:571d:: with SMTP id l29mr7472503pgb.179.1621377717611; Tue, 18 May 2021 15:41:57 -0700 (PDT) MIME-Version: 1.0 References: <20210518090658.9519-1-amanieu@gmail.com> <20210518090658.9519-9-amanieu@gmail.com> <3cb1d369e5e8431284e527e3e74fa6f2@AcuMS.aculab.com> In-Reply-To: <3cb1d369e5e8431284e527e3e74fa6f2@AcuMS.aculab.com> From: Ryan Houdek Date: Tue, 18 May 2021 15:41:47 -0700 Message-ID: Subject: Re: [RESEND PATCH v4 8/8] arm64: Allow 64-bit tasks to invoke compat syscalls To: David Laight Cc: Arnd Bergmann , "Amanieu d'Antras" , Catalin Marinas , Will Deacon , Mark Rutland , Steven Price , Mark Brown , Linux ARM , Linux Kernel Mailing List X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210518_154159_576236_056E91CB X-CRM114-Status: GOOD ( 35.13 ) 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 Tue, May 18, 2021 at 1:26 PM David Laight wrote: > > From: Arnd Bergmann > > Sent: 18 May 2021 14:02 > ... > > > > 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. > > To my mind because the kernel already contains the emulation code > there isn't much point trying to replicate it in userspace. > > OTOH I think they are trying to emulate x86 system calls not arm ones. > So the structure layouts don't always match. > However it is probably a lot nearer than the 64bit arm. Take care not to conflate the Tango and FEX project needs here. Tango is doing aarch32->aarch64 translation. So they are translating aarch32 syscalls. FEX is doing {x86, x86-64}->aarch64 translation. The simplicity of the interface helps Tango more than FEX in this regard. Since FEX likely still needs userspace fixups to *some* structures. > > Whether including some of the 'x32' code in an arm kernel will > help is another matter - it might be a useful source of differences. > > Am I also right in thinking that this isn't actually needed as part > of a 'generic' ARM kernel? Just ones for some specific platforms? This isn't correct from FEX's viewpoint. FEX isn't a product that will be shipping on any specific platform; The user is expected to just install FEX on their ARMv8.0+ device of choice. After they install FEX then they will freely be able to install *any* x86/x86-64 software and run it. The primary target is running full fledged games from the user's Steam library, but it can be anything the user desires. For context we have users running FEX on Lenovo c630, Apple M1, HardKernel SBCs, and recently some randomly picked Android devices. I can't speak on Tango's behalf here since I don't know their user ecosystem. > > David > > (Oh - I'm not involved in the project and will probably never use it.) > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel