https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.59.0 2022-01-06T22:15:18+00:00 2022-01-06T22:15:18+00:00 Matthias Krüger matthias.krueger@famsik.de 2022-01-06T22:15:18+00:00 urn:sha1:1591dcb659917de87254297073b078b9ade56612 RustWrapper: adapt to new AttributeMask API Upstream LLVM change 9290ccc3c1a1 migrated attribute removal to use AttributeMask instead of AttrBuilder, so we need to follow suit here. r? ``@nagisa`` cc ``@nikic`` 2022-01-05T18:51:59+00:00 Augie Fackler augie@google.com 2022-01-05T18:51:59+00:00 urn:sha1:34a6b6c4235972a715b03612905913d98ab899fd Avoids some extra conversions. Spotted by nikic during review. 2022-01-04T18:50:02+00:00 Augie Fackler augie@google.com 2022-01-04T18:41:36+00:00 urn:sha1:2803fbc44758a795d48a0c2d3a8ee06045dc9efb Upstream LLVM change 9290ccc3c1a1 migrated attribute removal to use AttributeMask instead of AttrBuilder, so we need to follow suit here. 2022-01-03T10:25:33+00:00 Krasimir Georgiev krasimir@google.com 2022-01-03T10:25:33+00:00 urn:sha1:4ce56b414ddc8ccc1fbb29cf99dd704e6c5845d9 No functional changes intended. The LLVM commit https://github.com/llvm/llvm-project/commit/ec501f15a8b8ace2b283732740d6d65d40d82e09 removed the signed version of `createExpression`. This adapts the Rust LLVM wrappers accordingly. 2021-12-30T05:15:51+00:00 Erik Desjardins erikdesjardins@users.noreply.github.com 2021-12-30T04:19:55+00:00 urn:sha1:e4463b2453f3b2665076e5daec23040976b8792e 2021-12-03T22:51:49+00:00 cynecx me@cynecx.net 2021-09-04T17:25:09+00:00 urn:sha1:91021de1f67de546b7ef41e03fc787f03ecf2239 2021-12-03T22:51:49+00:00 cynecx me@cynecx.net 2021-08-28T17:02:00+00:00 urn:sha1:491dd1f387e4f0b167e35560a97efc9949304640 2021-11-28T22:45:17+00:00 Matthias Krüger matthias.krueger@famsik.de 2021-11-28T22:45:17+00:00 urn:sha1:67762ffe35734c14b0aa1b90597dee164e73831a Emit LLVM optimization remarks when enabled with `-Cremark` The default diagnostic handler considers all remarks to be disabled by default unless configured otherwise through LLVM internal flags: `-pass-remarks`, `-pass-remarks-missed`, and `-pass-remarks-analysis`. This behaviour makes `-Cremark` ineffective on its own. Fix this by configuring a custom diagnostic handler that enables optimization remarks based on the value of `-Cremark` option. With `-Cremark=all` enabling all remarks. Fixes #90924. r? `@nikic` 2021-11-22T19:06:22+00:00 Benjamin A. Bjørnseth benjambj@protonmail.com 2021-04-06T19:37:49+00:00 urn:sha1:bb9dee95edef5a0da5f617cd94d3af8daef201c7 LLVM has built-in heuristics for adding stack canaries to functions. These heuristics can be selected with LLVM function attributes. This patch adds a rustc option `-Z stack-protector={none,basic,strong,all}` which controls the use of these attributes. This gives rustc the same stack smash protection support as clang offers through options `-fno-stack-protector`, `-fstack-protector`, `-fstack-protector-strong`, and `-fstack-protector-all`. The protection this can offer is demonstrated in test/ui/abi/stack-protector.rs. This fills a gap in the current list of rustc exploit mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html), originally discussed in #15179. Stack smash protection adds runtime overhead and is therefore still off by default, but now users have the option to trade performance for security as they see fit. An example use case is adding Rust code in an existing C/C++ code base compiled with stack smash protection. Without the ability to add stack smash protection to the Rust code, the code base artifacts could be exploitable in ways not possible if the code base remained pure C/C++. Stack smash protection support is present in LLVM for almost all the current tier 1/tier 2 targets: see test/assembly/stack-protector/stack-protector-target-support.rs. The one exception is nvptx64-nvidia-cuda. This patch follows clang's example, and adds a warning message printed if stack smash protection is used with this target (see test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3 targets has not been checked. Since the heuristics are applied at the LLVM level, the heuristics are expected to add stack smash protection to a fraction of functions comparable to C/C++. Some experiments demonstrating how Rust code is affected by the different heuristics can be found in test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is potential for better heuristics using Rust-specific safety information. For example it might be reasonable to skip stack smash protection in functions which transitively only use safe Rust code, or which uses only a subset of functions the user declares safe (such as anything under `std.*`). Such alternative heuristics could be added at a later point. LLVM also offers a "safestack" sanitizer as an alternative way to guard against stack smashing (see #26612). This could possibly also be included as a stack-protection heuristic. An alternative is to add it as a sanitizer (#39699). This is what clang does: safestack is exposed with option `-fsanitize=safe-stack`. The options are only supported by the LLVM backend, but as with other codegen options it is visible in the main codegen option help menu. The heuristic names "basic", "strong", and "all" are hopefully sufficiently generic to be usable in other backends as well. Reviewed-by: Nikita Popov <nikic@php.net> Extra commits during review: - [address-review] make the stack-protector option unstable - [address-review] reduce detail level of stack-protector option help text - [address-review] correct grammar in comment - [address-review] use compiler flag to avoid merging functions in test - [address-review] specify min LLVM version in fortanix stack-protector test Only for Fortanix test, since this target specifically requests the `--x86-experimental-lvi-inline-asm-hardening` flag. - [address-review] specify required LLVM components in stack-protector tests - move stack protector option enum closer to other similar option enums - rustc_interface/tests: sort debug option list in tracking hash test - add an explicit `none` stack-protector option Revert "set LLVM requirements for all stack protector support test revisions" This reverts commit a49b74f92a4e7d701d6f6cf63d207a8aff2e0f68. 2021-11-20T03:33:29+00:00 Josh Stone jistone@redhat.com 2021-11-20T03:33:29+00:00 urn:sha1:023cc968e1295994ed8039da43b0f2f4ea4e9390 `Module::getOrInsertGlobal` returns a `Constant*`, which is a super class of `GlobalVariable`, but if the given type doesn't match an existing declaration, it returns a bitcast of that global instead. This causes UB when we pass that to `LLVMGetVisibility` which unconditionally casts the opaque argument to a `GlobalValue*`. Instead, we can do our own get-or-insert without worrying whether existing types match exactly. It's not relevant when we're just trying to get/set the linkage and visibility, and if types are needed we can bitcast or error nicely from `rustc_codegen_llvm` instead.