linux-kernel - Re: arch/ && tracehook_report_syscall

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: <20090427182919.B923DFC3BF@magilla.sf.frob.com>
Date:	Mon, 27 Apr 2009 11:29:19 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Christoph Hellwig <hch@....de>
Subject: Re: arch/ && tracehook_report_syscall_xxx()

> We have a lot of code like arch/alpha/kernel/ptrace.c:syscall_trace()
> in arch/ and I can't see how to convert them to use tracehooks.
> 
> The first problem, we don't know which hook should be called, there is
> no entry/exit argument.

These arch maintainers just need to update their code.  Christoph has
started poking arch folks individually about getting up to speed.

IMHO, it is better anyway to use separate entry/exit calls.  For that
change, it is often easy to see how to do it correctly in the assembly code
without really knowing the arch at all.  (There are separate assembly paths
leading to the calls for entry vs exit cases already, just change the
symbol names.  Adding an argument would require a bit of a clue about
assembly on the arch.)

> Still, I think it is better to change this code right now, and call
> ptrace_report_syscall() directly.

I disagree.  Let the arch code get with the modern style.  
It is just a minute's hack for the arch maintainer.

> But, the second problem, there is no "struct pt_regs *".

They can use task_pt_regs(), it gets the same pointer.  It's passed in as
an argument because usually the arch really does have it handy right there
in a register so it's cheaper than recalculating.  (All the non-ancient
arch code uses it there for audit_syscall_{entry,exit} calls too.)

> However. I can't imagine how ptrace_report_syscall(regs) can actually
> use "regs". Perhaps we can remove this argument?

ptrace_report_syscall doesn't need it, it could be removed.  But that is
not apropos to the arch code, which should use tracehook_* properly.

> Hmm... and I can't understand how to change
> arch/mn10300/kernel/ptrace.c:do_syscall_trace(), it does something
> strange with TIF_SINGLESTEP. (maintainers cc'ed).

We can leave those details to the arch maintainers.  That case looks to me
like old hacks for step-over-syscall behavior, which made the opposite
choice (between |0x80 or not for stepping) from what x86 made.  Probably
they just want to match the new "norms" and not try to do anything
different for single-step in syscall tracing.

Thanks,
Roland
--
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/