Bug 417521
Summary: | bad getpid(): race from fork-like clone() to updating %gs:PID cache | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | John Reiser <jreiser> |
Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | 9 | CC: | drepper |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-07-29 06:29:01 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
John Reiser
2007-12-09 21:28:24 UTC
The suggested fix in the original report also has a race between the poisoning and the __NR_clone. If a signal handler in the parent calls getpid() in that interval, then the %gs:PID cache will be re-validated, leaving the child vulnerable to the original race. So if poisoning is used then it must be done with all signals blocked, and both the parent and child must restore the previous signal state after __NR_clone (and the child must re-cache %gs:PID before unblocking.) It would be safest if the pid cache were maintained by the same code that changes the pid: namely, the operating system kernel itself. Put the pid cache on a data page as part of the VDSO, and let the kernel maintain it. Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping VDSO is the same for all processes, if I understand it right. It can contain
changing data, e.g. current time, but this data should be the same for all
processes. It seems that PID can't be there.
Why does glibc cache PID anyway? The only reason can be some applications which
do getpid() thousands times per second.
> It would be safest if the pid cache were maintained by the same code that
changes the pid: namely, the operating system kernel itself.
It does maintain PID there. You access it with getpid() syscall. I distinctly
remember Linus saying that libc-level PID cache is, eh, let's say "not so
clever" (he was more direct) and "useful mostly for benchmark cheating". I
personally don't feel strongly either way, just pointing out that implementing
kernel-side cache is likely to be not welcomed by kernel guys.
If you call clone() you're on your own. There are far too many problems with clone to make attempt to fix work around one issue. |