On Sun, Feb 4, 2018 at 8:01 PM, Tycho Andersen <ty...@tycho.ws> wrote:
> Hi Andy,
> On Sun, Feb 04, 2018 at 05:36:33PM +0000, Andy Lutomirski wrote:
>> > The actual implementation of this is fairly small, although getting the
>> > synchronization right was/is slightly complex. Also worth noting that there
>> > is one race still present:
>> >
>> >   1. a task does a SECCOMP_RET_USER_NOTIF
>> >   2. the userspace handler reads this notification
>> >   3. the task dies
>> >   4. a new task with the same pid starts
>> >   5. this new task does a SECCOMP_RET_USER_NOTIF, gets the same cookie id
>> >      that the previous one did
>> >   6. the userspace handler writes a response
>> I'm slightly confused.  I thought the id was never reused for a given
>> struct seccomp_filter.  (Also, shouldn't the id be u64, not u32?)
> Well, what happens when u32/64 overflows? Eventually it will wrap.

I think we can safely assume that u64 won't overflow.  Even if we
processed one user return notification on a given seccomp_filter every
nanosecond (which would be insanely fast), that's 584 years.

>> On very quick reading, I have a question.  What happens if a process
>> has two seccomp_filters attached, one of them returns
>> SECCOMP_RET_USER_NOTIF, and the *other* one has a listener?
> Good question, in seccomp_run_filters(), the first (lowest, last
> applied) filter who returns SECCOMP_RET_USER_NOTIF is the one that
> gets the notification and the other receives nothing.
> I don't really have any reason to prefer this behavior, it's just what
> happened without much thought.

Hmm.  This won't nest right.  Maybe we should just disallow a
user-notification-using filter from being applied if there is already
one in the stack.  Then, if anyone cares about making these things
nest right, they can fix it.

Reply via email to