|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4 |
|
| #
6cee5393 |
| 24-Oct-2022 |
Rong Xu <xur@google.com> |
[Clang] Change AnonStructIds in MangleContext to per-function based
Clang is generating different mangled names for the same lambda
function in slightly changed builds (like with non-related
source/
[Clang] Change AnonStructIds in MangleContext to per-function based
Clang is generating different mangled names for the same lambda
function in slightly changed builds (like with non-related
source/Macro change). This is due to the fact that clang uses a
cross-translation-unit sequential string "$_<n>" in lambda's
mangled name. Here, "n" is the AnonStructIds field in MangleContext.
Different mangled names for a unchanged function is undesirable:
it makes perf comparison harder, and can cause some unnecessary
profile mismatch in SampleFDO.
This patch makes mangled name for lambda functions more stable
by changing AnonStructIds to a per-function based seq number if the
DeclContext is a function.
Differential Revision: https://reviews.llvm.org/D136397
show more ...
|
|
Revision tags: llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
d2792e7d |
| 14-Jul-2022 |
Nick Desaulniers <ndesaulniers@google.com> |
[clang][test] fix typo in fn attr
While testing backports of
https://reviews.llvm.org/D129572#inline-1245936
commit 2240d72f15f3 ("[X86] initial -mfunction-return=thunk-extern support")
I noticed th
[clang][test] fix typo in fn attr
While testing backports of
https://reviews.llvm.org/D129572#inline-1245936
commit 2240d72f15f3 ("[X86] initial -mfunction-return=thunk-extern support")
I noticed that one of my unit tests mistyped a function attribute. The
unit test was intended to test fn attr merging behavior, but with the
typo it was not. Small fixup.
Reviewed By: aaron.ballman, erichkeane
Differential Revision: https://reviews.llvm.org/D129691
show more ...
|
| #
2240d72f |
| 12-Jul-2022 |
Nick Desaulniers <ndesaulniers@google.com> |
[X86] initial -mfunction-return=thunk-extern support
Adds support for:
* `-mfunction-return=<value>` command line flag, and
* `__attribute__((function_return("<value>")))` function attribute
Where
[X86] initial -mfunction-return=thunk-extern support
Adds support for:
* `-mfunction-return=<value>` command line flag, and
* `__attribute__((function_return("<value>")))` function attribute
Where the supported <value>s are:
* keep (disable)
* thunk-extern (enable)
thunk-extern enables clang to change ret instructions into jmps to an
external symbol named __x86_return_thunk, implemented as a new
MachineFunctionPass named "x86-return-thunks", keyed off the new IR
attribute fn_ret_thunk_extern.
The symbol __x86_return_thunk is expected to be provided by the runtime
the compiled code is linked against and is not defined by the compiler.
Enabling this option alone doesn't provide mitigations without
corresponding definitions of __x86_return_thunk!
This new MachineFunctionPass is very similar to "x86-lvi-ret".
The <value>s "thunk" and "thunk-inline" are currently unsupported. It's
not clear yet that they are necessary: whether the thunk pattern they
would emit is beneficial or used anywhere.
Should the <value>s "thunk" and "thunk-inline" become necessary,
x86-return-thunks could probably be merged into x86-retpoline-thunks
which has pre-existing machinery for emitting thunks (which could be
used to implement the <value> "thunk").
Has been found to build+boot with corresponding Linux
kernel patches. This helps the Linux kernel mitigate RETBLEED.
* CVE-2022-23816
* CVE-2022-28693
* CVE-2022-29901
See also:
* "RETBLEED: Arbitrary Speculative Code Execution with Return
Instructions."
* AMD SECURITY NOTICE AMD-SN-1037: AMD CPU Branch Type Confusion
* TECHNICAL GUIDANCE FOR MITIGATING BRANCH TYPE CONFUSION REVISION 1.0
2022-07-12
* Return Stack Buffer Underflow / Return Stack Buffer Underflow /
CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702
SystemZ may eventually want to support "thunk-extern" and "thunk"; both
options are used by the Linux kernel's CONFIG_EXPOLINE.
This functionality has been available in GCC since the 8.1 release, and
was backported to the 7.3 release.
Many thanks for folks that provided discrete review off list due to the
embargoed nature of this hardware vulnerability. Many Bothans died to
bring us this information.
Link: https://www.youtube.com/watch?v=IF6HbCKQHK8
Link: https://github.com/llvm/llvm-project/issues/54404
Link: https://gcc.gnu.org/legacy-ml/gcc-patches/2018-01/msg01197.html
Link: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html
Link: https://arstechnica.com/information-technology/2022/07/intel-and-amd-cpus-vulnerable-to-a-new-speculative-execution-attack/?comments=1
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce114c866860aa9eae3f50974efc68241186ba60
Link: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00702.html
Link: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00707.html
Reviewed By: aaron.ballman, craig.topper
Differential Revision: https://reviews.llvm.org/D129572
show more ...
|