Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[tests] Regression test for EGL-glibc TLS conflict #5

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

amtep
Copy link

@amtep amtep commented Aug 28, 2014

bionic and glibc have different layouts for TLS space.
Since libEGL used a bionic slot directly (in inlined code),
libhybris's hooks didn't translate it properly and libEGL ended
up overwriting some unrelated thread-local values in glibc.

The problem only showed up when linking with libGLESv2 (which
pulls in libEGL), not when linking with libEGL directly. That's
why the test was added to test_glesv2.c

@thp
Copy link
Contributor

thp commented Aug 29, 2014

Good, although this doesn't detect overwrites with zero, right? What about initializing the array with a hardcoded random set of values, or generate random values into it at runtime, and then copy the whole array to a local variable and then compare both arrays? This would detect overwrites with zero, but obviously will fail to detect overwrites with whatever random value was written to it (probability of 1 / 256).

Other than that, LGTM.

@amtep
Copy link
Author

amtep commented Aug 29, 2014

Yes, I hadn't thought of anything writing zeroes.
There are some technical issues with making it nonzero... the bug that inspired this test was something that happened during library init, so before main().
The slots could be initialized at declaration, though not with random values. That would put the array in .tdata section instead of .tbss but I think they are allocated to the TLS the same way.

bionic and glibc have different layouts for TLS space.
Since libEGL used a bionic slot directly (in inlined code),
libhybris's hooks didn't translate it properly and libEGL ended
up overwriting some unrelated thread-local values in glibc.

The problem only showed up when linking with libGLESv2 (which
pulls in libEGL), not when linking with libEGL directly. That's
why the test was added to test_glesv2.c
@amtep
Copy link
Author

amtep commented Sep 5, 2014

I modified it so that the array is initialized with non-zero values.
It still detects the bug.

@thp
Copy link
Contributor

thp commented Sep 5, 2014

LGTM.

@Thaodan
Copy link
Contributor

Thaodan commented Dec 1, 2020

Close?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants