Thread (39 messages) 39 messages, 9 authors, 2012-03-05

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help