You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we already do some page-alignment checks, but it'd be nice to check that TLS segment sizes are a multiple of the page size. This would avoid the issue @randomPoison hit with zlib.
The text was updated successfully, but these errors were encountered:
One problem here is that we don't actually raise the size of the TLS segment size to a multiple of 4096, but add 4096 to the size to ensure that the last page of the TLS region is not shared with the TLS region of the next shared object. Padding to a multiple of 4096 does not ensure this because we don't know the alignment at which the TLS region will start based on other shared objects that have already been laid out. Even if we did align to 4096, we could get false positives with such a check as the unpadded library's TLS segment could happen to be a multiple of 4096 bytes. But we could pad to the second next multiple of 4096 which would allow us to do this kind of (best-effort) check.
It might be easier to add some other, less confounded, signature with the pad-tls tool.
ok I guess if a binary that wouldn't be pkey_mprotected correctly can still have TLS segments with sizes that are multiples of a page then we should just add a signature like you're suggesting.
I think we already do some page-alignment checks, but it'd be nice to check that TLS segment sizes are a multiple of the page size. This would avoid the issue @randomPoison hit with zlib.
The text was updated successfully, but these errors were encountered: