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

GRSecurity/PaX compatibility #3653

Merged
merged 1 commit into from
Oct 4, 2012
Merged

GRSecurity/PaX compatibility #3653

merged 1 commit into from
Oct 4, 2012

Conversation

shizmob
Copy link
Contributor

@shizmob shizmob commented Oct 4, 2012

This patch adds GRSecurity compatibility to the Rust build process, fixing issues #1708 and #3641.

It adds an extra flag to ./configure called --enable-pax-marks, which will lead to the application of the PaX MPROTECT disable flag on all retrieved and compiled rustc binaries. This requires the paxctl binary to be installed.
Additionally, the configure process has been altered to attempt to automatically detect a running GRSecurity kernel and set aforementioned option as a result, unless --disable-pax-marks has been explicitly passed as a ./configure flag.

# Warn if we couldn't read /proc.
if [ -z "$GRSEC_DETECTED" -a ! -r /proc/sys/kernel ]
then
warn "could not read /proc/sys/kernel: GRSecurity detection might be incorrect"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not entirely clear on this: Will this warning be printed even on systems without grsec if /proc/sys/kernel is unreadable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, because if you can't read /proc/sys/kernel, you also can't determine if /proc/sys/kernel/grsecurity exists.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes me wonder if trying to enable PaX by default is really a good idea. Do other projects actually try to do this? (I've never seen such warnings when building various software on non-grsec kernels, hence me asking.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, perhaps the warning may be a bit superfluous; most projects don't need special measures, because they don't do silly things -- LLVM does however. Other opinions on whether to show warnings?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, we can remove this warning, as, contrary to what I believed, under GRSecurity you actually can access /proc/sys/kernel just fine as non-root non-CONFIG_GRKERNSEC_PROC_GID user.

@alexrp
Copy link

alexrp commented Oct 4, 2012

It may be worth doing some OS detection magic so the code doesn't try to find grsec on e.g. Windows, OS X, and FreeBSD.

@shizmob
Copy link
Contributor Author

shizmob commented Oct 4, 2012

Removed warnings, it will now just show the detection status.

…add GRSecurity autodetection code to configure.
@shizmob
Copy link
Contributor Author

shizmob commented Oct 4, 2012

Rebased everything into one commit for clarity.

@graydon graydon merged this pull request into rust-lang:master Oct 4, 2012
@graydon
Copy link
Contributor

graydon commented Oct 4, 2012

Thanks!

bors pushed a commit to rust-lang-ci/rust that referenced this pull request May 15, 2021
RalfJung pushed a commit to RalfJung/rust that referenced this pull request Jun 9, 2024
Fix futex with large timeout ICE

Fixes rust-lang#3647.

This PR changed the type of ``nanoseconds`` from ``u64`` to ``u128``. In ``duration_since``, nanoseconds is manually converted to second by dividing it with 1e9. But overflow is still possible.
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