Messages in this thread | | | Date | Thu, 19 Oct 2023 12:52:25 +0200 | From | Andrea della Porta <> | Subject | Re: [PATCH 0/4] arm64: Make Aarch32 compatibility enablement optional at boot |
| |
On 14:44 Wed 18 Oct , Arnd Bergmann wrote: > On Wed, Oct 18, 2023, at 14:27, Will Deacon wrote: > > Hi, > > > > On Wed, Oct 18, 2023 at 01:13:18PM +0200, Andrea della Porta wrote: > >> Aarch32 compatibility mode is enabled at compile time through > >> CONFIG_COMPAT Kconfig option. This patchset lets 32-bit support > >> (for both processes and syscalls) be enabled at boot time using > >> a kernel parameter. Also, it provides a mean for distributions > >> to set their own default without sacrificing compatibility support, > >> that is users can override default behaviour through the kernel > >> parameter. > > > > I proposed something similar in the past: > > > > https://lkml.kernel.org/linux-fsdevel/20210916131816.8841-1-will@kernel.org/ > > > > bu the conclusion there (see the reply from Kees) was that it was better > > to either use existing seccomp mechanisms or add something to control > > which binfmts can be loaded. > > Right, I was going to reply along the same lines here: x86 is > a bit of a special case that needs this, but I believe all the > other architectures already guard the compat syscall execution > on test_thread_flag(TIF_32BIT) that is only set by the compat > binfmt loader.
Are you referring to the fact that x86 can switch at will between 32- and 64- bit code?
Regarding the TIF_32BIT flag, thanks for the head-up. I still believe though that this mechanism can somehow break down in the future, since prohibiting 32 bit executable loading *and* blocking 32 bit compat syscall are two separate path of execution, held together by the architecture prohibiting to switch to A32 instructions by design. Breaking the first rule and embedding wisely crafted A32 instruction in an executable is easy, while the difficult part is finding some 'reentrancy' to be able to do the execution state switch, as pinted out in https://lore.kernel.org/lkml/ZTD0DAes-J-YQ2eu@apocalypse/. I agree it's highly speculative and not something to be concerned right now, it's just a head up, should the need arise in the future.
> Doing the reverse is something that has however come up in the > past several times and that could be interesting: In order to > run userspace emulation (qemu-user, fex, ...) we may want to > allow calling syscalls and ioctls for foreign ABIs in a native > task, and at that point having a mechanism to control this > capability globally or per task would be useful as well. > > The compat mode (arm32 on arm64) is the easiest case here, but the > same thing could be done for emulating the very subtle architecture > differences (x86-64 on arm64, arm64 on x86_64, arm32 on x86-compat, > or any of the above on riscv or loongarch). > > Arnd
Really interesting, Since it's more related to emulation needs (my patch has another focus due to the fact that A64 can execute A32 natively), I'll take a look at this separately.
Andrea
| |