* Esben Nielsen <[email protected]> wrote:
> > > > this is racy - we cannot know whether the PID wrapped around.
> > > >
> > > What about adding more bits to check on? The PID to lookup the task_t
> > > and then some extra bits to uniquely identify the actual task.
> >
> > which would just be a fancy name for a wider PID space, and would thus
> > still not protect against PID reuse :-)
> >
>
> Can it really be correct there is no way to uniquely identify a thread
> in the uptime of the system? It could be done with BigIntegers :-)
well, that's how PIDs work. I'd have no problem with 64-bit PIDs/TIDs in
theory, but besides a _massive_ ABI break (which makes the whole thing a
non-starter), users would probably resist 'ps' output like:
917239487098712349 tty8 Ss+ 0:00 -bash
1844674407370955161 tty9 Ss+ 0:00 -bash
1356415698798712343 tty10 Ss+ 0:00 -bash
:-| Another problem is that futexes are fundamentally 32-bit, so there's
no space in them for 64-bit TIDs ...
> > i'm not sure i follow - what list is this and how would it be
> > maintained?
>
> At the FUTEX_WAIT operation add the waiter to a list of waiters on the
> owner's task_t. At FUTEX_WAKE remove the waiter. At task exit wake up
> the waiters.
well, but even in this case the kernel has no idea (currently) about the
owner - it is the waiters that have kernel state in this case. So extra
code would have to be added to look up the TID, make sure the lookup is
secure: check that the task looked up is really mapping that vma, and to
queue waiters to the owner. Quite clumsy ... and this is still only the
easy case, when the kernel is involved in the futex use.
> > > I admit your solution is a good one. The only drawback - besides being
> > > untraditional - is that memory corruption can leave futexes locked at
> > > exit.
> >
> > so? Memory corruption can overwrite the futex value anyway, and can thus
> > cause the wrong owner to be identified - causing a locked futex. This
> > patch does not protect against bad effects of memory corruption -
> > there's really no way to keep userspace from breaking itself.
> >
>
> At least you could wake up those who are already blocked in the
> kernel...
which would be of little use if the wrong TID is in the futex. There's
really no protection against userspace breaking itself.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
