On Thu, Sep 16, 2021 at 5:13 PM Will Deacon <will@xxxxxxxxxx> wrote:
> On Thu, Sep 16, 2021 at 04:46:15PM +0200, Arnd Bergmann wrote:
> > On Thu, Sep 16, 2021 at 3:18 PM Will Deacon <will@xxxxxxxxxx> wrote:
> > In the first case, having the kernel make the decision based on CPU
> > feature flags would be easier. In the second case, I would expect this
> > to be a per-process setting similar to prctl, capability or seccomp.
> > This would make it possible to do it for separately per container
> > and avoid ambiguity about what happens to already-running 32-bit
> > tasks.
>
> I'm not sure I follow the per-process aspect of your suggestion -- we want
> to prevent 32-bit tasks from existing at all. If it wasn't for GKI, we'd
> just disable CONFIG_COMPAT altogether, but while there is a need for 32-bit
> support on some devices then we're not able to do that.
>
> Does that make more sense now?
That sounds rather specific to your use case, but others may have similar
requirements that are better served with a per-container or per-process
flag. If your init process sets the process specific flag to prevent compat
mode and non-root tasks are unable to set it back, the effect for you
should be the same, but others may also be able to use the feature.
Another option would be to make the binfmt helper a device specific
module, in that case you wouldn't need to use a runtime feature at all,
you just prevent the module from getting loaded. ;-)
On a somewhat related note, a topic that has come up in the past
is to make the syscall ABI user selectable across all architectures, and
allow e.g. an arm64 task to call normal syscalls using the arm32
compat calling conventions, in order to simplify user space ISA emulation.
This could even be done in a way to allow using foreign architecture
syscall semantics for things like fex that emulates x86 on arm.
If this gets added, having the conditional in the binfmt loader is
a bit pointless.
Arnd
