[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWx0T28jdC-pW5xTPhRYJsbp+byeF5CAwZh0gXdd09RNQ@mail.gmail.com>
Date: Fri, 8 Nov 2013 08:39:29 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Paul Moore <pmoore@...hat.com>
Cc: libseccomp-discuss@...ts.sourceforge.net,
Eric Paris <eparis@...hat.com>,
James Hogan <james.hogan@...tec.com>,
Will Drewry <wad@...omium.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Russell King <linux@....linux.org.uk>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [libseccomp-discuss] [PATCH v2] seccomp: not compatible with ARM OABI
On Fri, Nov 8, 2013 at 8:29 AM, Paul Moore <pmoore@...hat.com> wrote:
> On Thursday, November 07, 2013 11:05:26 AM Andy Lutomirski wrote:
>> On Thu, Nov 7, 2013 at 10:56 AM, Eric Paris <eparis@...hat.com> wrote:
>>
>> > Isn't x32 similarly screwy? Does it work because the syscall numbers
>> > are different?
>>
>> Yes (from reading the code -- I haven't actually tried it).
>
> I've got a x32 VM that I boot occasionally to test seccomp/libseccomp. For
> the purposes of seccomp it looks exactly like x86_64, including sharing the
> same AUDIT_ARCH_X86_64 value, the only difference being the syscall number
> offset ... Assuming you're using kernel 3.9 or later. Previous kernels had a
> bug which stripped the x32 syscall offset so it was impossible to distinguish
> from x86_64 and x32 with seccomp. See the following commit for the details:
Ooh -- where did you get this? (I imagine I could debootstrap such a
beast and then just chroot / nspawn / schroot in, but if there are
readily available images, that would be great. Fedora doesn't seem to
have much x32 support.)
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists