rebase prior to commit

update seses flag

rebase

Update commit message to add info about SESES change too

Going to merge this today. I updated based on the comments.

Fix redundant LFENCE problem with SESES

Add inline comment about lvi hardening falling back to seses

@sconstab @craig.topper - Ping for review

@sconstab @craig.topper - Ping for review

Hi pranavk, Any reason this didn't get upstreamed? I was just looking for something like this in the docs and came across your patch here.

Fix accidentally deleted clang command line ref

@sconstab @craig.topper @mattdr -- This is ready for another round of review.

seses implies lvi-cfi

Update Clang Command Ref with automated tool

Add comment to clarify

Thanks for the ping, Scott. I'll update this so I can get it submitted soon.

I created a patch for the suggested change. Perhaps we should continue the conversation there? https://reviews.llvm.org/D82037

Thanks for the explanation!

In D80964#2097227, @craig.topper wrote:

It may also be worth noting that this new unoptimized pass is equivalent to the behavior of the mitigation implemented for gcc through binutils. Given that I wonder if it makes sense to use this pass at O1 or O2 and save the mostly costly analysis for O3.

In D80964#2097211, @sconstab wrote:

From a security perspective, I think that this could become problematic. It would mean that at -O0 I would get more security than I would at -O[1-3]. IMO optimization levels should not work like that.

Also to be a bit clearer, I don't think it's necessary to unify the approaches. It seems like deleting the new approach and dropping in SESES would be sufficient. Let me know if that's not the case.

Could you explain how not adding the MBB entry block is different from removing extra MBB later? Curious on the details about the differences here since the change makes sense functionally and I don't see any issues, but I can't understand why adding the extra MBB entry block at the point we create the machine function and then deleting extra blocks results in something different than the automatically created entry block. Is it some attributes or configuration in the basic block or something?

ClangFormat diagnostic definition

In D79743#2044676, @jyu2 wrote:

This looks good to me. Could you also add a test to use this new DiagGroup (-Wno-slh-asm-goto)?

Thanks.

Jennifer

Add test; Update command for existing test

@spatel - I updated the documentation here to use the command mehdi suggested (that you said was good in a follow up comment). The rest of it look good too?

@jyu2 and @mattdr - updated to address your comments.

Update to emit the warning in the parser

Do you mean runtime crash? If so, I think error should be emit, so that programmer can remove use of "asm goto" and recompile.

Change the dry-run command to mehdi's suggestion

Good idea. Done.

Add running tests to the workflow

In D79743#2034792, @jyu2 wrote:

Two questions:
1> What happen under SLH, will asm goto gets removed, or a runtime problem?
2> Should we emit error or warning in the Parser instead?

Update to fix failing test

Change langopt type + SpeculativeLoadHardeningEnabled -> SpeculativeLoadHardening

@craig.topper @george.burgess.iv Friendly ping on this documentation.

Rebasing

I'm also happy to close this if you want to fix the regexes in a patch instead since I agree that would be better.

In D78968#2007501, @RKSimon wrote:

If this is a problem we should be doing more than just adding a comment in the script.

Possible things to consider:
1 - add support for matching dso_preemptable / dso_local - pretty trivial to add the relevant regex(s)
2 - detect any specifiers and warn that it might not be necessary

Add FIXME and bug link

[utils] Update comment to be more specific based on maskray's comment

In D78968#2006646, @MaskRay wrote:

Added some users of update_llc_test_checks.py.

link attributes is not clear. Do you mean dso_local or dso_preemptable? The problem you described seems like a general stale test problem. Missing dso_local may be a problem but I don't know whether that is common. Maybe there are more common problems that are worth mentioning.