generated from ossf/project-template
-
Notifications
You must be signed in to change notification settings - Fork 122
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
Compiler flags notes/comments #330
Comments
Thanks so much! We really appreciate the feedback! |
|
Has this been addressed by the C/C++ Compiler Hardening options guide? @gkunz @thomasnyman @david-a-wheeler |
I believe not. I may have some time next week to send some PRs about some
of these.
…On Wed, 8 May 2024 at 20:37, CRob ***@***.***> wrote:
Has this been addressed by the C/C++ Compiler Hardening options guide?
@gkunz <https://github.com/gkunz> @thomasnyman
<https://github.com/thomasnyman> @david-a-wheeler
<https://github.com/david-a-wheeler>
—
Reply to this email directly, view it on GitHub
<#330 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACMLWCT2WVFSPECSAN5ZUKLZBJWGHAVCNFSM6AAAAABADE6BACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBRGE4TQNRYGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
This was referenced Aug 22, 2024
Trying to slowly work through these. I'm trying to split of suggestions for concrete additions to separate issues to allow them to be commented on and tracked separately, currently #588 and #589.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Forwarding this here from the #wg_best_practices_compilers OpenSSF slack channel, so we don't loose it. I am going to create separate issues or PRs from the poins below in the upcomming week[s].
Hey, Dominik Czarnota from Trail of Bits here and I've been working on similar internal guide in the past; I'd like to contribute to the compiler opts hardening guide in the future, but for now, I will send here my random notes about its contents.
We should recommend explicitly setting the "separate code" linker flag:
-Wl,-z,separate-code
which, e.g., makes so that the ELF header is not mapped with executable rights (https://bitlackeys.org/papers/secure_code_partitioning_2018.txt). This can be easily seen/compared against a binary compiled with-Wl,-z,no-separate-code
and checking outinfo proc mappings
(or Pwndbg'svmmap
) in GDB.I think the "When not to use?" for "3.14. Enable data execution prevention" regarding JIT apps makes not much sense? Most JIT apps would not care about
-z noexecstack
because they would not use stack region and would set or change memory permissions using mmap or mprotect anyway and-z noexecstack
mostly influences how the memory of the program is mapped initially.The description for 3.14 could also be more clear that if you compile a program with
-z noexecstack
but it requires executable code (e.g., when using nested functions, feature from GCC) the program will just crash when it will jump to the trampoline (since the generated code will put the trampoline on the stack and jump to it, and stack will be non-executable).(I have got an example code for that fwiw)
Fwiw regarding 3.14, in Linux, before version 5.8, if a program is run with executable stack then the kernel will set all other readable pages as executable and not just its stack memory. This is because of some
elf_read_implies_exec
sheniganis and changes within kernel code. (I can provide more details to it)The "4. Discouraged Compiler Options" could mention
-mmitigate-rop
which was there once but then was removed since it didn't provide much benefitRe: "Enabling
-fstack-protector-strong
is recommended as it provides the best balance between function coverage and performance". I recommended-fstack-protector-strong
+--param ssp-buffer-size=4
in the past (while =8 is the default) but yeah, would be nice to read more on that."
-D_FORTIFY_SOURCE=3
(requires -O1 or higher, may require prepending -U_FORTIFY_SOURCE)" - iirc the value =1 requires -O1 and =2 or =3 requires -O2, but I'd have to double check that. I'd also recommend checking if =3 works if your compiler does not support this value, since it is a fairly new addition.Regarding GOT, note that "bind now" options are only relevant for the given binary we compile: the libc, libstdc++ and other libs will still have writable function pointers in GOT/GOTPLT if they are not compiled with those options.
FWIW there is also a
LD_BIND_NOW
env var supported by ld.so, but from my tests now it seems it doesn't improve this for libc/libstdc++ at all.In 3.16.2 the "The x86_64 architecture supports mov instructions that address memory using offsets relative to the instruction pointer" could be rephrased. This feature/thing is called "RIP-relative addressing" and its not just about
mov
instructions as e.g.lea
(and likely some others) will also leverage that.There are some compiler flags that were there at some point/version in time but were removed, for example:
-Wlifetime
which was changed to two other flags (-Wdangling-gsl -Wreturn-stack-address
) (https://stackoverflow.com/questions/52662135/the-purpose-of-the-wlifetime-flag). Clang docs says the twodiagnostic is enabled by default
but idk if its enabled with-Wall -Wextra
or, e.g., only within thescan-build
tool.There's also
-ftrapv
that can be used to trap overflows, but I haven't played with it much and some people says its better to use sanitizers for that (https://news.ycombinator.com/item?id=24578534)We should probably also mention GCC's
-fanalyzer
flagThe text was updated successfully, but these errors were encountered: