Re: [PATCH 2/3] [RFC] seccomp: give BPF x32 bit when restoring x32 filter

[Andy Lutomirski]

On Jul 11, 2014 3:48 PM, "Kees Cook" <keescook@xxxxxxxxxxxx> wrote:
>
> On Fri, Jul 11, 2014 at 12:36 PM, Paul Moore <pmoore@xxxxxxxxxx> wrote:
> > Anyway, getting back to the idea I mentioned earlier ... as many of you may
> > know, Kees (added to the CC line) is working on some seccomp filter
> > improvements which will result in a new seccomp syscall.  Perhaps one way
> > forward is to preserve everything as it is currently with the prctl()
> > interface, but with the new seccomp() based interface we fixup x32 and use the
> > new AUDIT_ARCH_X32 token?  It might result in a bit of ugliness in some of the
> > kernel, but I don't think it would be too bad, and I think it would address
> > both our concerns.
>
> Adding AUDIT_ARCH_X32: yes please. (On that note, the comment "/* Both
> x32 and x86_64 are considered "64-bit". */" should be changed...)
>

I admit I'm not convinced that the current situation is really wrong.
The "audit arch" uniquely defines a mapping between the actual syscall
and nr and the regs.  The natural way to convert between seccomp_data
and the syscall entry and regs is completely correct.

For things like ARM OABI, the situation is different: OABI and EABI
really do work differently wrt the interpretation of the syscall regs.
This isn't the case for x32.

Of course, the audit code screws this up completely, but audit is
disabled for x32.  My upcoming seccomp patchset will clean it up a
little.  IMO there's no actual audit ABI to preserve for x32, because
that code has never been anything other than terminally fvcked.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/