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

Assembly: enable CET #96

Merged
merged 1 commit into from Jun 27, 2020
Merged

Assembly: enable CET #96

merged 1 commit into from Jun 27, 2020

Conversation

sneves
Copy link
Collaborator

@sneves sneves commented Jun 26, 2020

Addresses #95.

With our current dispatcher, both on C and Rust, having endbr64 at the top of the functions is rather pointless since these will never be at the end of an indirect call. But since this is a glorified nop, might as well.

@oconnor663
Copy link
Member

I have no idea what this means. Can I leave it to you to hit the merge button whenever you think it's ready? :)

@xnox
Copy link

xnox commented Jun 26, 2020

Looks good to me! The test C binary is marked as CET enabled.

Please merge.

@xnox
Copy link

xnox commented Jun 26, 2020

I have no idea what this means. Can I leave it to you to hit the merge button whenever you think it's ready? :)

I find this presentation the best explanation about the CET technology https://www.linuxplumbersconf.org/event/2/contributions/147/attachments/72/83/CET-LPC-2018.pdf

@xnox
Copy link

xnox commented Jun 27, 2020

Maybe @hjl-tools could review this too. This adds CET support to BLAKE3 asm.

@hjl-tools
Copy link

Since the assembly codes are in .S, you should do

#if defined(__ELF__) && defined(__CET__)
# include <cet.h>
#else
# define _CET_ENDBR
#endif

and use _CET_ENDBR everywhere ENDBR is needed. Since -fcf-protection needs binutils with CET support,
it should work.

@sneves
Copy link
Collaborator Author

sneves commented Jun 27, 2020

The reason I did not just include the cet.h header is that it appears to be GCC-specific; building with Clang would fail, even though it supports -fcf-protection=full.

@hjl-tools
Copy link

The reason I did not just include the cet.h header is that it appears to be GCC-specific; building with Clang would fail, even though it supports -fcf-protection=full.

LLVM doesn't working CET support before LLVM 11 which also includes <cet.h>:

https://bugs.llvm.org/show_bug.cgi?id=45484

Most of CET fixes have been backported to LLVM 10.x, except for <cet.h>. You can do

#if defined(__ELF__) && defined(__CET__) && __has_include(<cet.h>)
# include <cet.h>
#else
...
#endif

@sneves
Copy link
Collaborator Author

sneves commented Jun 27, 2020

Most of CET fixes have been backported to LLVM 10.x, except for <cet.h>. You can do

#if defined(__ELF__) && defined(__CET__) && __has_include(<cet.h>)
# include <cet.h>
#else
...
#endif

Goes in as suggested.

@sneves sneves merged commit f200567 into master Jun 27, 2020
@xnox
Copy link

xnox commented Jun 27, 2020

Thank you @hjl-tools for your input! Much appreciated!

kevingoh pushed a commit to ITS-AT-dev/BLAKE3 that referenced this pull request Oct 23, 2023
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.

None yet

4 participants