add codegen option for using LLVM stack smash protection #84197

bbjornse · 2021-04-14T20:02:09Z

LLVM has built-in heuristics for adding stack canaries to functions. These
heuristics can be selected with LLVM function attributes. This PR adds a codegen
option -C stack-protector={basic,strong,all} which controls the use of these
attributes. This gives rustc the same stack smash protection support as clang
offers through options -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 PR 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.

rust-highfive · 2021-04-14T20:02:12Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @petrochenkov (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

petrochenkov · 2021-04-14T21:36:29Z

r? @nikic

bors · 2021-04-29T17:42:56Z

☔ The latest upstream changes (presumably #84233) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2021-05-02T14:04:37Z

☔ The latest upstream changes (presumably #84802) made this pull request unmergeable. Please resolve the merge conflicts.

nikic

Looks pretty reasonable to me. Main feedback is that this should start as an unstable -Z option. @nagisa Is an MCP needed to add an unstable option?

compiler/rustc_codegen_llvm/src/lib.rs

compiler/rustc_session/src/options.rs

src/test/assembly/stack-protector/stack-protector-heuristics-effect.rs

src/test/assembly/stack-protector/stack-protector-target-support.rs

src/test/ui/stack-protector/warn-stack-protector-unsupported.rs

nikic · 2021-05-03T20:14:16Z

compiler/rustc_target/src/spec/mod.rs

@@ -899,6 +899,54 @@ supported_targets! {
    ("aarch64_be-unknown-linux-gnu_ilp32", aarch64_be_unknown_linux_gnu_ilp32),
 }

+/// Controls use of stack canaries.
+#[derive(Clone, Copy, Debug, PartialEq, Hash, Eq)]
+pub enum StackProtector {


I don't think this is the right place to put this, as it's not actually used by target definitions. I'm not sure what the right place would be though...

I looked through the set of dependencies of rustc_session to if I could address this comment, but none of the other crates seem more appropriate. The actual user is rustc_codegen_llvm, but this crate depends on rustc_session and not the other way around. One alternative could perhaps be to set move the definition within rustc_session itself, rationale being that the option is "owned" by the option parser?

I've left the location alone for now though, rather than finding a completely new option location, as the other options defined there are at least somewhat similar. I did move it closer to the others, though, rather than being separated from them by the long supported_targets! list.

nagisa · 2021-05-03T23:05:19Z

MCP isn't necessary for adding an unstable option, no. During the stabilization a final comment period vote will occur instead.

compiler/rustc_session/src/config.rs

nikic

Looks good to me. Would you mind squashing all the commits together before this gets merged?

klensy · 2021-05-30T11:52:13Z

Default stack protector option is no stack protector, but there no such option as -fno-stack-protector?

bors · 2021-05-31T02:15:53Z

☔ The latest upstream changes (presumably #85559) made this pull request unmergeable. Please resolve the merge conflicts.

bbjornse · 2021-05-31T19:03:37Z

Default stack protector option is no stack protector, but there no such option as -fno-stack-protector?

Right, there is no stack protection unless requested. This is also the case with gcc and clang, I believe, so -fno-stack-protector is the same as passing no option.

klensy · 2021-05-31T19:08:09Z

Right, there is no stack protection unless requested. This is also the case with gcc and clang, I believe, so -fno-stack-protector is the same as passing no option.

I mean, that if that option mimic clang's one (that have -fno-stack-protector), we should have explicit variant as well? Something like -Cstack-protector=no

bbjornse · 2021-05-31T19:58:31Z

I mean, that if that option mimic clang's one (that have -fno-stack-protector), we should have explicit variant as well? Something like -Cstack-protector=no

I see. My ambition was to replicate the functionality clang and gcc provides, more than the set of options itself, and for this the current set of alternatives suffice.

It is possible to add an explicit none alternative as you suggest. Is this desirable? I would personally lean against adding code which accomplishes the same as having no code. Arguments I see in favour of such an option is that some users might prefer being explicit about their choice of avoiding stack protection overhead.

nagisa · 2021-05-31T21:04:10Z

I think the concern is more about the consistency with the other options which tend to have a way to enable the default behaviour and the ability to override the options set by other tooling (possibly in the future).

bors · 2021-06-01T15:08:57Z

☔ The latest upstream changes (presumably #85886) made this pull request unmergeable. Please resolve the merge conflicts.

bbjornse · 2021-06-04T19:28:35Z

I think I see your point @klensy and @nagisa: although the usefulness of an explicit none option is hypothetical, there is value in ruling out hypothetical problems. The presence of such an option may also be expected by users.

I added this capability in the most recent commit. (The patch is larger than strictly necessary as the none option could have been represented with Option::None, but I think one enum variant for each option makes more sense.)

bors · 2021-06-05T03:53:04Z

☔ The latest upstream changes (presumably #84234) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2021-11-18T20:29:50Z

☔ The latest upstream changes (presumably #90382) made this pull request unmergeable. Please resolve the merge conflicts.

nikic · 2021-11-21T21:43:31Z

I feel like option 3 ends up testing LLVM implementation details too much -- the only thing that really matters to us here is that the attributes get passed through to LLVM properly and it acts based on them in some way, but I don't think it's important to test LLVM's precise behavior on all platforms. LLVM should have their own tests for that. Especially if it needs new compiletest infrastructure, I think this is more hassle than it's worth. I'd skip darwin for this test.

The stack protector heuristics used by LLVM don't really make sense for rust in any case -- e.g. this one is supposed to exclude non-char arrays in structs, but because rust wraps everything in structs it also ends up applying to non-struct arrays.

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 rust-lang#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 rust-lang#26612). This could possibly also be included as a stack-protection heuristic. An alternative is to add it as a sanitizer (rust-lang#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 <[email protected]> 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.

bbjornse · 2021-11-22T20:07:08Z

I agree that this test is highly detailed, to the point where it may increase rather than reduce maintenance cost (more often updating the test to reflect a new truth than fixing a true error). The point of view justifying such a test would be that rustc bears the responsibility that its options work as advertised even if some work is carried out by a third-party codegen library. For different stack smash protection heuristics, this means ensuring that the heuristics work as documented in the help text.

That said, I have few qualms testing this only on Linux. Reading the LLVM source, it doesn't look like there are other exceptions, and it seems reasonable to assume that any exceptions added in the future would not prompt action even if this was detected by a rustc test (apart, perhaps from updating the help text). Not to mention that clang doesn't seem to describe this exception to heuristic behaviour in its help text either. I would say it's more important to enable the end-to-end test on more targets, since codegen is more likely to have target-specific breakage with more detrimental effect.

Most recent push reverts the "option 3"-commit, and instead adds ignore-macos to the failing test. I did not update the help text as the test still covers this somewhat elaborately, with one exception shoved under the rug.

nikic · 2021-11-22T20:11:51Z

@bors r+ rollup=never Next try!

bors · 2021-11-22T20:11:53Z

📌 Commit bb9dee9 has been approved by nikic

bors · 2021-11-23T06:08:41Z

⌛ Testing commit bb9dee9 with merge 7c4be43...

bors · 2021-11-23T09:10:44Z

☀️ Test successful - checks-actions
Approved by: nikic
Pushing 7c4be43 to master...

rust-timer · 2021-11-23T10:40:56Z

Finished benchmarking commit (7c4be43): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

SparrowLii · 2023-03-09T10:39:37Z

This is still an unstable option. Are there any unresolved issues?

nikic · 2023-03-09T10:54:37Z

I think a problem with stabilizing this would be that LLVM's heuristics for placing stack protectors are not appropriate for rustc. -Z stack-protector=all is well-defined, but the other two aren't.

SparrowLii · 2023-03-09T12:37:35Z

Thanks for the explanation! Yea, rustc already has many security mechanisms, and the llvm's stack protection heuristics may not be suitable for it.

But there are many scenarios where Rust and other languages (such as C/C++) call each other. In this case, Rust's function stack could be broken by functions from other language. In this case, stack protection is still required. I think `stack-protector=all' is enough for these situations.

Can we separate stack-protector=all from the other options and stabilize it?

SparrowLii · 2023-03-09T13:04:48Z

Or we can add a rustc compilation option to add stack-protector attributes only to those rust functions that call external functions

mrcnski · 2023-05-15T18:14:35Z

Can we separate stack-protector=all from the other options and stabilize it?

This seems reasonable, if the only issue is with the heuristics.

@bbjornse

I propose stabilizing `-Cstack-protector` as `-Zstack-protector`. This PR adds a new `-Cstack-protector` flag, leaving the unstable `-Z` flag as is to ease the transition period. The `-Z` flag will be removed in the future. No RFC/MCP, this flag was added in rust-lang#84197 and was not deemed large enough to require additional process. The tracking issue for this feature is rust-lang#114903. The `-Cstack-protector=strong` mode uses the same underlying heuristics as Clang's `-fstack-protector-strong`. These heuristics weren't designed for Rust, and may be over-conservative in some cases - for example, if Rust stores a field's data in an alloca using an LLVM array type, LLVM regard the alloca as meaning that the function has a C array, and enable stack overflow canaries even if the function accesses the alloca in a safe way. Some people thought we should wait on stabilization until there are better heuristics, but I didn't hear about any concrete case where this unduly harms performance, and I think that when a need comes, we can improve the heuristics in LLVM after stabilization. The heuristics do seem to not be under-conservative, so this should not be a security risk. The `-Cstack-protector=basic` mode (`-fstack-protector`) uses heuristics that are specifically designed to catch old-C-style string manipulation. This is not a good fit to Rust, which does not perform much unsafe C-style string manipulation. As far as I can tell, nobody has been asking for it, and few people are using it even in today's C - modern distros (e.g. [Debian]) tend to use `-fstack-protector-strong`. Therefore, `-Cstack-protector=basic` has been **removed**. If anyone is interested in it, they are welcome to add it back as an unstable option. [Debian]: https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_STACKPROTECTOR_.28gcc.2Fg.2B-.2B-_-fstack-protector-strong.29 Most implementation was done in <rust-lang#84197>. The command-line attribute enables the relevant LLVM attribute on all functions in <https://github.com/rust-lang/rust/blob/68baa87ba6f03f8b6af2a368690161f1601e4040/compiler/rustc_codegen_llvm/src/attributes.rs#L267-L276>. Each target can indicate that it does not support stack canaries - currently, the GPU platforms `nvptx64-nvidia-cuda` and `amdgcn-amd-amdhsa`. On these platforms, use of `-Cstack-protector` causes an error. The feature has tests that make sure that the LLVM heuristic gives reasonable results for several functions, by checking for `__security_check_cookie` (on Windows) or `__stack_chk_fail` (on Linux). See <https://github.com/rust-lang/rust/tree/68baa87ba6f03f8b6af2a368690161f1601e4040/tests/assembly-llvm/stack-protector> No call-for-testing has been conducted, but the feature seems to be in use. No reported bugs seem to exist. - @bbjornse was the original implementor at rust-lang#84197 - @mrcnski documented it at rust-lang#111722 - @wesleywiser added tests for Windows at rust-lang#116037 - @davidtwco worked on the feature at rust-lang#121742 - @nikic provided support from the LLVM side (on Zulip on <https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Proposal.20for.20Adapt.20Stack.20Protector.20for.20Ru.E2.80.A6.20compiler-team.23841> and elsewhere), thanks @nikic! No FIXMEs related to this feature. This feature cannot cause undefined behavior. No changes to reference/spec, docs added to the codegen docs as part of the stabilization PR. No. None. No support needed for rustdoc, clippy, rust-analyzer, rustfmt or rustup. Cargo could expose this as an option in build profiles but I would expect the decision as to what version should be used would be made for the entire crate graph at build time rather than by individual package authors. `-C stack-protector` is propagated to C compilers using cc-rs via rust-lang/cc-rs#1550

I propose stabilizing `-Cstack-protector` as `-Zstack-protector`. This PR adds a new `-Cstack-protector` flag, leaving the unstable `-Z` flag as is to ease the transition period. The `-Z` flag will be removed in the future. No RFC/MCP, this flag was added in 84197 and was not deemed large enough to require additional process. The tracking issue for this feature is 114903. The `-Cstack-protector=strong` mode uses the same underlying heuristics as Clang's `-fstack-protector-strong`. These heuristics weren't designed for Rust, and may be over-conservative in some cases - for example, if Rust stores a field's data in an alloca using an LLVM array type, LLVM regard the alloca as meaning that the function has a C array, and enable stack overflow canaries even if the function accesses the alloca in a safe way. Some people thought we should wait on stabilization until there are better heuristics, but I didn't hear about any concrete case where this unduly harms performance, and I think that when a need comes, we can improve the heuristics in LLVM after stabilization. The heuristics do seem to not be under-conservative, so this should not be a security risk. The `-Cstack-protector=basic` mode (`-fstack-protector`) uses heuristics that are specifically designed to catch old-C-style string manipulation. This is not a good fit to Rust, which does not perform much unsafe C-style string manipulation. As far as I can tell, nobody has been asking for it, and few people are using it even in today's C - modern distros (e.g. [Debian]) tend to use `-fstack-protector-strong`. Therefore, `-Cstack-protector=basic` has been **removed**. If anyone is interested in it, they are welcome to add it back as an unstable option. [Debian]: https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_STACKPROTECTOR_.28gcc.2Fg.2B-.2B-_-fstack-protector-strong.29 Most implementation was done in <rust-lang#84197>. The command-line attribute enables the relevant LLVM attribute on all functions in <https://github.com/rust-lang/rust/blob/68baa87ba6f03f8b6af2a368690161f1601e4040/compiler/rustc_codegen_llvm/src/attributes.rs#L267-L276>. Each target can indicate that it does not support stack canaries - currently, the GPU platforms `nvptx64-nvidia-cuda` and `amdgcn-amd-amdhsa`. On these platforms, use of `-Cstack-protector` causes an error. The feature has tests that make sure that the LLVM heuristic gives reasonable results for several functions, by checking for `__security_check_cookie` (on Windows) or `__stack_chk_fail` (on Linux). See <https://github.com/rust-lang/rust/tree/68baa87ba6f03f8b6af2a368690161f1601e4040/tests/assembly-llvm/stack-protector> No call-for-testing has been conducted, but the feature seems to be in use. No reported bugs seem to exist. - bbjornse was the original implementor at 84197 - mrcnski documented it at 111722 - wesleywiser added tests for Windows at 116037 - davidtwco worked on the feature at 121742 - nikic provided support from the LLVM side (on Zulip on <https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Proposal.20for.20Adapt.20Stack.20Protector.20for.20Ru.E2.80.A6.20compiler-team.23841> and elsewhere), thanks nikic! No FIXMEs related to this feature. This feature cannot cause undefined behavior. No changes to reference/spec, docs added to the codegen docs as part of the stabilization PR. No. None. No support needed for rustdoc, clippy, rust-analyzer, rustfmt or rustup. Cargo could expose this as an option in build profiles but I would expect the decision as to what version should be used would be made for the entire crate graph at build time rather than by individual package authors. `-C stack-protector` is propagated to C compilers using cc-rs via rust-lang/cc-rs issue 1550

rust-highfive assigned petrochenkov Apr 14, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 14, 2021

This comment has been minimized.

Sign in to view

rust-highfive assigned nikic and unassigned petrochenkov Apr 14, 2021

bbjornse force-pushed the stack-protector branch from 82bb7e3 to 088a014 Compare April 30, 2021 18:18

nikic reviewed May 3, 2021

View reviewed changes

bbjornse force-pushed the stack-protector branch from 088a014 to 0d4850f Compare May 15, 2021 18:38

bbjornse force-pushed the stack-protector branch from 0d4850f to d978b5f Compare May 29, 2021 19:02

klensy reviewed May 29, 2021

View reviewed changes

compiler/rustc_session/src/config.rs Outdated Show resolved Hide resolved

nikic approved these changes May 30, 2021

View reviewed changes

bbjornse force-pushed the stack-protector branch from 641f893 to 5f167f1 Compare May 30, 2021 18:38

bbjornse force-pushed the stack-protector branch from 5f167f1 to 1338da9 Compare May 31, 2021 18:55

This comment has been minimized.

Sign in to view

bbjornse force-pushed the stack-protector branch from 1338da9 to ea15203 Compare June 1, 2021 19:50

bbjornse force-pushed the stack-protector branch from 8524848 to 680cc90 Compare June 5, 2021 20:18

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 15, 2021

bbjornse force-pushed the stack-protector branch from d5500a4 to bb9dee9 Compare November 22, 2021 19:08

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 22, 2021

bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 23, 2021

bors merged commit 7c4be43 into rust-lang:master Nov 23, 2021

rustbot added this to the 1.58.0 milestone Nov 23, 2021

themaxdavitt mentioned this pull request Jan 18, 2022

Document stack smashing protection #93052

Closed

rcvalle mentioned this pull request Aug 16, 2023

Tracking Issue for stabilizing stack smashing protection (i.e., -Z stack-protector) #114903

Open

davidtwco mentioned this pull request Feb 28, 2024

sess: stabilize -C stack-protector=all #121742

Closed

carlos-al mentioned this pull request Jun 9, 2024

Add windows-kernel flag zyantific/zydis-rs#39

Closed

arielb1 mentioned this pull request Sep 9, 2025

Stabilize stack-protector #146369

Open

add codegen option for using LLVM stack smash protection #84197

add codegen option for using LLVM stack smash protection #84197

Uh oh!

Conversation

bbjornse commented Apr 14, 2021

Uh oh!

rust-highfive commented Apr 14, 2021

Uh oh!

This comment has been minimized.

petrochenkov commented Apr 14, 2021

Uh oh!

bors commented Apr 29, 2021

Uh oh!

bors commented May 2, 2021

Uh oh!

nikic left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nikic May 3, 2021

Choose a reason for hiding this comment

Uh oh!

bbjornse May 15, 2021

Choose a reason for hiding this comment

Uh oh!

nagisa commented May 3, 2021

Uh oh!

Uh oh!

nikic left a comment

Choose a reason for hiding this comment

Uh oh!

klensy commented May 30, 2021

Uh oh!

bors commented May 31, 2021

Uh oh!

bbjornse commented May 31, 2021

Uh oh!

klensy commented May 31, 2021

Uh oh!

bbjornse commented May 31, 2021

Uh oh!

nagisa commented May 31, 2021

Uh oh!

This comment has been minimized.

bors commented Jun 1, 2021

Uh oh!

bbjornse commented Jun 4, 2021

Uh oh!

bors commented Jun 5, 2021

Uh oh!

bors commented Nov 18, 2021

Uh oh!

nikic commented Nov 21, 2021

Uh oh!

bbjornse commented Nov 22, 2021

Uh oh!

nikic commented Nov 22, 2021

Uh oh!

bors commented Nov 22, 2021

Uh oh!

bors commented Nov 23, 2021

Uh oh!

bors commented Nov 23, 2021

Uh oh!

rust-timer commented Nov 23, 2021

Uh oh!

SparrowLii commented Mar 9, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nikic commented Mar 9, 2023

Uh oh!

SparrowLii commented Mar 9, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SparrowLii commented Mar 9, 2023

SparrowLii commented Mar 9, 2023 •

edited

Loading

SparrowLii commented Mar 9, 2023 •

edited

Loading