Re: [PATCH v12 06/13] seccomp: add system call filtering using BPF

["Indan Zupancic" <indan@nul.nu>]

On Fri, March 2, 2012 06:52, H. Peter Anvin wrote:
> On 03/01/2012 09:45 PM, Indan Zupancic wrote:
>>
>>> + * @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?

> You seem to be unable to look outside
> your own particular use cases, but it is very likely that the same
> oddball cases which do mixed-mode programming are ones for which this
> kind of filtering facility would be extremely useful

The filtering code has no way of reading the instruction, so it can't
know if it's a good or bad one. And the mode is passed via 'arch' already,
which is the proper way of checking this.

To properly protect the ptrace user against unexpected modes it's better
to provide a way to the filter to know the task mode instead of trying
to figure it out from IP.

I'm not saying having the IP is never useful, I actually use it in my
ptrace code (and have to add IP checks to handle those odd mixed mode
cases). I just don't see how it can be used by a BPF filter.

> -- 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?

Because the only one I can think of creates a false sense of security:

"Oh, the IP comes from a trusted code area, so it must be fine."

And the problem with that is that the IP doesn't say anything about the
call path, only where the last instruction was. Address randomization
helps a little bit, but it's not a guarantee.

Greetings,

Indan