linux-kernel - Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Nov 2013 15:20:44 -0600
From:	Will Drewry <wad@...omium.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Eric Paris <eparis@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	Kees Cook <keescook@...omium.org>,
	Richard Weinberger <richard@....at>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	libseccomp-discuss@...ts.sourceforge.net,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls

On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
>> On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
>> > 1. Set a different audit arch for OABI syscalls (e.g.
>> > AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
>> > that x86_64 treats int 80.
>>
>> As the audit maintainer, I like #1.  It might break ABI, but the ABI is
>> flat wrong now and not maintainable...
>
> If you read the whole thread, you will see that this corner case is just
> not worth the effort to support.  Audit may as well be disabled by
> kernel config if any OABI support is enabled.

This might be the best move for seccomp too (as Kees suggested).  I'd
love to have audit arch visibility, but it's not clear that it's worth
any sort of larger changes ...

... like adding a task_thread_info.compat flag that bubbles up to
syscall_get_arch(), or if we assume consumers of syscall_get_nr() are
broken today (I haven't checked), then it would be possible to at
least re-add the 0x900000 bits, if compat, before handing back the
system call number but leave the audit arch pieces alone.
--
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/