Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp347540pxb; Fri, 15 Jan 2021 14:58:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJz7s5GsN9d+F19N5goNdaqB7YtivA+mYtqrFhnteiBVMjrXUVHJUQjWEbdM1PI24/XrY2Dh X-Received: by 2002:a17:907:7255:: with SMTP id ds21mr10291900ejc.258.1610751524164; Fri, 15 Jan 2021 14:58:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610751524; cv=none; d=google.com; s=arc-20160816; b=MTaE88Yc+pHur7W/cdb3SB9Iz6a4fHAT/fT4W4TxVRxdj4l9QvrJn5SKsmvYbs7NB7 mabcicIR8sQF/gfGIV5moUyz3Uj6L1djAdHr58qoaDPiT1kYbC1OHm22o6fpWb67mYSc mimQsF44foY/gCMKs/5BEvhCaECvApZlWOwIR81osLkbDBlqiGKyrtrJJGInb/P046Ye cU6hRgORzhZr7GVJJr9gIobxXVCSAVoaZDiXrOCwImm85KSiY7y7oiZVZQWZLwqaso4E ush8UZY7jaHrK6ZVMl50KSTl5yMOXk5n0yIUvI+3ScHqM7GhQLVHjb1drMie1xb2gYTr 3VSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=k2dl7zMebiVIbAaI+K+iGgw1YqmWI2lwUujqPQFNDLc=; b=ix2AC90JmWsgjMgERy61KRVkzysNLkxXWxaESD6gSQhDEWMg4DSYVybyiO7nA6H0Um 6xETTtyvxTrZSCCoVHzTZFmRj49ntM+I+3Ci9HimXk3DcmMEpf/PuF4c0cc1pxk2dFMp yZuceOsCoI6spjp9evZzNxxE9ag0TYtLI9WcwU8f4n/ahOCABibdMyYpo7WYpFlyUDCY I7FKTWNZiye0199XlKlQHzOOcmqImswBEm6FEHRhq/momjT4+AfF1VY6bYjRp1NwFOBm 4hxF/EIH5c9kvFOFhnBnhW7V+4S6Uia5LazcE2Zb44DhsCD5DvFds5gu0WwKnE9bToFU pQUw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lr3si4744786ejb.388.2021.01.15.14.58.20; Fri, 15 Jan 2021 14:58:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727197AbhAOW5O (ORCPT + 99 others); Fri, 15 Jan 2021 17:57:14 -0500 Received: from brightrain.aerifal.cx ([216.12.86.13]:47904 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726661AbhAOW5O (ORCPT ); Fri, 15 Jan 2021 17:57:14 -0500 Date: Fri, 15 Jan 2021 17:23:25 -0500 From: Rich Felker To: Arnd Bergmann Cc: David Laight , "sonicadvance1@gmail.com" , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Yoshinori Sato , "David S. Miller" , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "x86@kernel.org" , "H. Peter Anvin" , Chris Zankel , Max Filippov , Alexander Viro , Arnd Bergmann , Andrew Morton , Aleksa Sarai , Xiaoming Ni , David Rientjes , Willem de Bruijn , Christian Brauner , Miklos Szeredi , Minchan Kim , "Eric W. Biederman" , Stephen Rothwell , Vincenzo Frascino , Vlastimil Babka , Oleg Nesterov , YueHaibing , Suren Baghdasaryan , Nicholas Piggin , Brian Gerst , Dominik Brodowski , Jan Kara , Arnaldo Carvalho de Melo , "linux-alpha@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-ia64@vger.kernel.org" , "linux-m68k@lists.linux-m68k.org" , "linux-mips@vger.kernel.org" , "linux-parisc@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-s390@vger.kernel.org" , "linux-sh@vger.kernel.org" , "sparclinux@vger.kernel.org" , "linux-xtensa@linux-xtensa.org" , "linux-fsdevel@vger.kernel.org" , "linux-api@vger.kernel.org" , "linux-arch@vger.kernel.org" Subject: Re: [PATCH] Adds a new ioctl32 syscall for backwards compatibility layers Message-ID: <20210115222325.GJ23432@brightrain.aerifal.cx> References: <20210106064807.253112-1-Sonicadvance1@gmail.com> <20210115070326.294332-1-Sonicadvance1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 15, 2021 at 11:17:09PM +0100, Arnd Bergmann wrote: > On Fri, Jan 15, 2021 at 9:01 PM David Laight wrote: > > > > From: sonicadvance1@gmail.com > > > Sent: 15 January 2021 07:03 > > > Problem presented: > > > A backwards compatibility layer that allows running x86-64 and x86 > > > processes inside of an AArch64 process. > > > - CPU is emulated > > > - Syscall interface is mostly passthrough > > > - Some syscalls require patching or emulation depending on behaviour > > > - Not viable from the emulator design to use an AArch32 host process > > > > > > > You are going to need to add all the x86 compatibility code into > > your arm64 kernel. > > This is likely to be different from the 32bit arm compatibility > > because 64bit items are only aligned on 32bit boundaries. > > The x86 x32 compatibility will be more like the 32bit arm 'compat' > > code - I'm pretty sure arm32 64bit aligned 64bit data. > > All other architectures that have both 32-bit and 64-bit variants > use the same alignment for all types, except for x86. > > There are additional differences though, especially if one > were to try to generalize the interface to all architectures. > A subset of the issues includes > > - x32 has 64-bit types in places of some types that are > 32 bit everywhere else (time_t, ino_t, off_t, clock_t, ...) > > - m68k aligns struct members to at most 16 bits > > - uid_t/gid_t/ino_t/dev_t/... are > > > You'll then need to remember how the process entered the kernel > > to work out which compatibility code to invoke. > > This is what x86 does. > > It allows a single process to do all three types of system call. > > > > Trying to 'patch up' structures outside the kernel, or in the > > syscall interface code will always cause grief somewhere. > > The only sane place is in the code that uses the structures. > > Which, for ioctls, means inside the driver that parses them. > > He's already doing the system call emulation for all the system > calls other than ioctl in user space though. In my experience, > there are actually fairly few ioctl commands that are different > between architectures -- most of them have no misaligned > or architecture-defined struct members at all. > > Once you have conversion functions to deal with the 32/64-bit > interface differences and architecture specifics of sockets, > sysvipc, signals, stat, and input_event, handling the > x86-32 specific ioctl commands is comparably easy. Indeed, all of this should just be done in userspace. Note (as you of course know, but others on CC probably don't) that we did this in musl libc for the sake of being able to run a time64 userspace on a pre-time64 kernel, with translation from the new time64 ioctl structures to the versions needed by the old ioctls and back using a fairly simple table: https://git.musl-libc.org/cgit/musl/tree/src/misc/ioctl.c?id=v1.2.2 I imagine there's a fair bit more to be done for 32-/64-bit mismatch in size/long/pointer types and different alignments, but the problem is almost certainly tractable, and much easier than what they already have to be doing for syscalls. Rich