[systemd-devel] [PATCH] nspawn: allow 32-bit chroots from 64-bit hosts

[Lennart Poettering]

On Tue, 18.02.14 13:45, H. Peter Anvin (hpa at zytor.com) wrote:

> 
> On 02/18/2014 11:52 AM, Dave Reisner wrote:
> > On Tue, Feb 18, 2014 at 02:44:14PM -0500, Dave Reisner wrote:
> >> Arch Linux uses nspawn as a container for building packages and needs
> >> to be able to start a 32bit chroot from a 64bit host. 24fb11120756
> >> disrupted this feature when seccomp handling was added.
> >> ---
> >> Lennart suggested this approach, and it works nicely.
> > 
> > I suppose it's also possible to run an x32 chroot from an x86_64 host,
> > so we might want to allow that. Alternatively, it seems we can just
> > change the default action to allow (instead of kill) when a bad
> > architecture is encountered. I don't know if there's side effects with
> > that change that we'd want to avoid.
> > 
> 
> And if you're on a 64-bit kernel with a 32-bit userspace (either i386 or
> x32), you can launch a 64-bit chroot if you want to.  As such #ifdef
> __x86_64__ seems wrong.

Hmm, if we think about that, how would that even work? I mean, you
probably want to fix the personality in that case, right? 

The personality API appears to have two rules:

a) On a system with a 32bit kernel PER_LINUX translates to the 32bit
   personality, and PER_LINUX32 is kinda pointless (did I get this right?)

b) On a system with a 64bit kernel PER_LINUX translates to the 64bit
   personality, and PER_LINUX32 to the 32bit personality that is also
   supported.

Now, let's say we are on a 64bit kernel and a 32bit userspace. And now
want to invoke a 64bit chroot. How would we fix the personality? I mean,
from that context rule a) would apply, hence there is no way to
"upgrade" the personality to 64bit, is there? Or does
personality(PER_LINUX) do two completely different things if I am
calling it from a 32bit userspace on a 32bit kernel and a 32bit
userspace on a 64bit kernel? 

Lennart

-- 
Lennart Poettering, Red Hat