netdev - Re: [PATCH v8 3/8] seccomp: add system call filtering using BPF

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]

Message-ID: <CABqD9haiko3xLUKFp_MZcd8G7Hsyif75ABk1HOVKNJ7=NZRRsA@mail.gmail.com>
Date:	Thu, 16 Feb 2012 22:26:20 -0600
From:	Will Drewry <wad@...omium.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Eric Paris <eparis@...hat.com>,
	Markus Gutschke <markus@...omium.org>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-doc@...r.kernel.org, kernel-hardening@...ts.openwall.com,
	netdev@...r.kernel.org, x86@...nel.org, arnd@...db.de,
	davem@...emloft.net, mingo@...hat.com, oleg@...hat.com,
	peterz@...radead.org, rdunlap@...otime.net, mcgrathr@...omium.org,
	tglx@...utronix.de, luto@....edu, serge.hallyn@...onical.com,
	djm@...drot.org, scarybeasts@...il.com, indan@....nu,
	pmoore@...hat.com, akpm@...ux-foundation.org, corbet@....net,
	eric.dumazet@...il.com, keescook@...omium.org
Subject: Re: [PATCH v8 3/8] seccomp: add system call filtering using BPF

On Thu, Feb 16, 2012 at 10:12 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 02/16/2012 07:53 PM, Will Drewry wrote:
>>
>> An earlier change Roland had prodded me toward was adding a
>> syscall_get_arch() call to asm/syscall.h which returned the
>> appropriate audit arch value for the current calling convention.  I
>> hate to suggest this, but should I go ahead and wire that up for x86
>> now, make it a dependency for HAVE_ARCH_SECCOMP_FILTER (and officially
>> part of asm/syscall.h) then let it trickle into existence?  Maybe
>> something like:
>>
>
> ... and we have been talking about making a regset and export it to
> ptrace and core dumps, too.

Would having an audit_arch returning function be useful for building
those cases too? Or would this just be nearly-duplicated code
everywhere?  (As is, ptrace usually takes shortcuts since it has the
arch-specific knowledge, so maybe it just wouldn't matter.)

>> static inline int syscall_get_arch(struct task_struct *task, struct
>> pt_regs *regs)
>> {
>> #ifdef CONFIG_IA32_EMULATION
>>   if (task_thread_info(task)->status & TS_COMPAT)
>>     return AUDIT_ARCH_I386;
>> #endif
>> #ifdef CONFIG_64BIT
>>   return AUDIT_ARCH_X86_64;
>> #else
>>   return AUDIT_ARCH_I386;
>> #endif
>> }
>>
>
> In this case it could be is_compat_task().

I wasn't sure if it was fine to add any syscall_* functions that
depended on the caller being current.

>> There would be no other callers, though, because everywhere AUDIT_ARCH
>> is used it is hardcoded as appropriate.  Then when x32 comes along, it
>> can figure out where it belongs using tif status and/or regs.
>
> For x32 you have the option of introducing a new value or relying on bit
> 30 in eax (and AUDIT_ARCH_X86_64).  The latter is more natural, probably.

Will that bit be visible as the syscall number or will it be stripped
out before passing the number around?  If it's visible, then it
doesn't seem like there'd need to be a new AUDIT_ARCH, but I suspect
someone like Eric will have an actually useful opinion.

thanks!
will
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html