On Thu, Feb 16, 2012 at 10:12 PM, H. Peter Anvin [off-list ref] wrote:

On 02/16/2012 07:53 PM, Will Drewry wrote:

quoted

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.)

quoted

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.

quoted

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