Add kernel-address sanitizer support for freestanding targets

[repnop]

This PR adds support for KASan (kernel address sanitizer) instrumentation in freestanding targets. I included the minimal set of x86_64-unknown-none, riscv64{imac, gc}-unknown-none-elf, and aarch64-unknown-none but there's likely other targets it can be added to. (linux_kernel_base.rs?) KASan uses the address sanitizer attributes but has the CompileKernel parameter set to true in the pass creation.

[rust-highfive]

r? @cuviper

(rust-highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

⚠️ Warning ⚠️

• These commits modify compiler targets. (See the Target Tier Policy.)

[Andy-Python-Programmer]

Amazing! 🎉

[cuviper]

Are there any tests we can add for this? Perhaps add to the sanitizer tests in src/test/codegen/?

How about some documentation in src/doc/unstable-book/src/compiler-flags/sanitizer.md?

Should this be added to Session::emit_lifetime_markers?

[cuviper]

but there's likely other targets it can be added to. (linux_kernel_base.rs?)

That sounds reasonable -- is there any reason not to add it there?

[repnop]

Are there any tests we can add for this? Perhaps add to the sanitizer tests in src/test/codegen/?

it uses the same instrumentation as Address Sanitizer so I think it should be pretty simple to integrate with those, I'll take a look!

How about some documentation in src/doc/unstable-book/src/compiler-flags/sanitizer.md?

didn't even think of that! 😅 good catch

Should this be added to Session::emit_lifetime_markers?

hmm, I'm not familiar with that area, but I'll see what I can find out!

but there's likely other targets it can be added to. (linux_kernel_base.rs?)

That sounds reasonable -- is there any reason not to add it there?

I thought so too, but I can't say I'm 100% confident if it should be. @alex you added the original x86_64-linux-kernel target, do you know if there'd be any issues with enabling KASan for it? my thought would be that since it needs explicit kernel support, it would probably only make sense if the kernel its running on has KASan enabled?

as for other targets, I was hoping to get some feedback from someone more familiar with the set of targets that would actually support this -- I'm mainly unsure of the various bare-metal ARM targets, but I'll also see if I can dig up what clang supports the flag on and use that as a reference 👍

[bors]

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

[pnkfelix]

based on the previous comment from @repnop, I assume this is waiting on @repnop to integrate the review feedback provided by @cuviper

@rustbot label: -S-waiting-on-review S-waiting-on-author

[repnop]

@cuviper I believe all of the changes you requested are now done. I split out the tests where appropriate since the targets with the other sanitizers won't support this. I ran both of them locally with ./x.py test --force-rerun src/test/ui/sanitize/cfg-kasan.rs src/test/codegen/sanitizer-kasan-emits-instrumentation.rs --target=riscv64imac-unknown-none-elf --host=x86_64-unknown-linux-gnu and got a pass for each, so I think things are looking good there. I did find out that I had to modify the cfg setting code because KASAN is really just a different ASAN compilation method, so I figure the attributes should be the same for both.

As for the x86_64-unknown-none-linuxkernel target that I had mentioned previously, I dug around and I cannot find a single project in the wild except for one in a google search for that target that hasn't been updated in 2 years, the Rust for Linux uses a custom target.json for their builds with a different LLVM target, and as far as I can tell, its nigh identical to the x86_64-unknown-none target, so I'm going to ignore it now as I don't think its likely to exist for long unless there's a very good reason for it to.

[repnop]

@rustbot label -S-waiting-on-author +S-waiting-on-review

[bors]

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

[wesleywiser]

Hey @cuviper, it looks like this PR is ready for another round of review. Thanks! 🙂

[wesleywiser]

@repnop would you mind rebasing and resolving the merge conflicts? That will help shorten the review cycle.

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[bors]

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

[repnop]

@rustbot label -S-waiting-on-author +S-waiting-on-review

[cuviper]

Just a couple typos for riscv min-llvm-version.

[bors]

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

[cuviper]

@bors r+

(bah, bors doesn't see reviews...)

[cuviper]

@bors r+

[bors]

📌 Commit 1971438 has been approved by cuviper

It is now in the queue for this repository.

[bors]

⌛ Testing commit 1971438 with merge fabfd1f...

[bors]

☀️ Test successful - checks-actions
Approved by: cuviper
Pushing fabfd1f to master...

[rust-timer]

Finished benchmarking commit (fabfd1f): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.1%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.4%	[-3.4%, -3.4%]	2
All ❌✅ (primary)	0.1%	[0.1%, 0.1%]	1

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	5.2%	[4.3%, 5.9%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0