On Tue, 18.02.14 13:45, H. Peter Anvin ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
