Re: [PATCH v12 06/13] seccomp: add system call filtering using BPF
From: "H. Peter Anvin" <hpa@zytor.com>
Date: 2012-03-02 06:56:30
Also in:
lkml, netdev
On 03/01/2012 10:43 PM, Indan Zupancic wrote:
On Fri, March 2, 2012 06:52, H. Peter Anvin wrote:quoted
On 03/01/2012 09:45 PM, Indan Zupancic wrote:quoted
quoted
+ * @nr: the system call number + * @arch: indicates system call convention as an AUDIT_ARCH_* value + * as defined in <linux/audit.h>. + * @instruction_pointer: at the time of the system call.If the vDSO is used this will always be the same, so what good is this? I haven't gotten an answer to this yet.And if it isn't, or you're on an architecture which doesn't use the vdso as the launching point, it's not.True, but then what?
Ok, fail on my part - I misread the above to refer to @arch, not @instruction_pointer.
quoted
-- Pin is a great example.Is that http://www.pintool.org/? Can you explain how knowing the IP is useful for Pin? All I am asking for is just one use case for providing the IP. Is that asking for too much?
However, it still applies. For something like Pin, Pin may want to trap on all or a subset from the instrumented program, while the instrumentation code -- which lives in the same address space -- needs to execute those same instructions. Yes, it's useless for *security* (unless perhaps if you keep very strict tabs on the flow of control by using debug registers, dynamic translation or whatnot), but it can be highly useful for *instrumentation*, where you want to analyze the behavior of a non-malicious program. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.