Segmentation fault due to a wrongly mapped page after NRE by bootstraping the runtime with rust under linux

[Wartori54]

Description

On GNU/Linux, when using a simple rust script to launch a .NET application by loading the hostfxr library from a .NET 8/9 stock runtime a segmentation fault occurs shortly after the managed application tries to access a null object. It fails in ExecuteHandlerOnCustomStack, after the sigsegv_handler successfully gets called, while trying to read from a mapped page with no read, write or execute permissions set.
Strangely enough this behaviour does not appear when using a C++ script instead, doing the exact same loading process of course.

Reproduction Steps

The following zip file contains the reproduction setup for this issue (nativehostingtest.zip):

• Download a .NET runtime from the official sources, .NET 8.0.15 runtime for x64 for Linux was used for testing (I have reproduced this issue with the .NET 9.0.4 runtime as well).
• Extract it in the runtime directory, make sure the contents are directly there, the dotnet executable from the runtime should end up in nativehostingtest/runtime/dotnet for reference.
• Go in the dotnet_app directory and build the C# project in debug mode, this in necessary since the paths for the files are hard-coded for reliability reasons.
• Go in the rusthost directory and build the source with cargo build, run the binary in target/debug/rusthost.
• Go in the cpphost directory, and build the source with {g++/clang++} -o nativehost nativehost.cpp, and run the binary.

Expected behavior

Both scripts (C++ and rust) nicely exit after a NRE happens in managed code, with an stacktrace and an Aborted exit code.

Actual behavior

Under rust, the managed app will print to console, and exit with a Segmentation Fault shortly after.

Under C++, the managed binary does print to console and it nicely exits with an stack trace and an Aborted exit code.

Regression?

This also does not seem to occur at all under .NET 7.0.20 or earlier.

Known Workarounds

None.

As pointed in here the following, combined with the removal of rust's sig_handler, is enough to fix the issue:

let mut altstack: stack_t = mem::zeroed();
altstack.ss_flags = SS_DISABLE;
sigaltstack(&altstack, ptr::null_mut());

Configuration

Tested with .NET runtime 8.0.15 and 9.0.4, under GNU/Linux from EndeavourOS.
x64 processor (i5-1235U), kernel: 6.14.4-arch1-2 x86_64.

This issue seemed to not occur in a Debian-based system and another EndeavourOS system. Further details from those systems are unfortunately unknown to me currently.

Other information

Rust does register a SIGSEGV handler in its runtime, the provided sample does remove such handler to make sure it is not interfering, keeping it does not alter the issue's behaviour.

Here's a core dump of the crash too: coredump.tar.gz.

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[mangod9]

cc @janvorli. Would be interesting to check the behavior on 10 since we have switched to a new Exception handling infra.

[jkotas]

Rust does register a SIGSEGV handler in its runtime, the provided sample does remove such handler to make sure it is not interfering, keeping it does not alter the issue's behaviour.

The rust allocates and registers altstack: https://github.com/rust-lang/rust/blob/fd9fad6dbcc1bae3cba2a8634339ffa620a49f28/library/std/src/sys/pal/unix/stack_overflow.rs#L185-L205 . You are not undoing this. I expect that the crash will go away if you undo the altstack set by rust as well.

The problem is that the Rust altstack is not big enough to execute the .NET signal handler.

.NET signal handler allocates very large CONTEXT structure on the stack:

runtime/src/coreclr/pal/src/arch/amd64/signalhandlerhelper.cpp

Lines 63 to 77 in bd3ff5d

	CONTEXT context2;
	RtlCaptureContext(&context2);
	// We don't care about the other registers state since the stack unwinding restores
	// them for the target frame directly from the signal context.
	context2.Rsp = (size_t)sp;
	context2.Rbx = (size_t)faultSp;
	context2.Rbp = (size_t)fp;
	context2.Rip = (size_t)signal_handler_worker;
	context2.Rdi = code;
	context2.Rsi = (size_t)siginfo;
	context2.Rdx = (size_t)context;
	context2.Rcx = (size_t)returnPoint;
	RtlRestoreContext(&context2, NULL);

. We have run into problems with this before. Perhaps we should consider a different implementation strategy that does not require large CONTEXT structures allocated on the stack.

[jkotas]

runtime/src/coreclr/pal/src/arch/amd64/signalhandlerhelper.cpp

Lines 63 to 77 in bd3ff5d

	CONTEXT context2;
	RtlCaptureContext(&context2);
	// We don't care about the other registers state since the stack unwinding restores
	// them for the target frame directly from the signal context.
	context2.Rsp = (size_t)sp;
	context2.Rbx = (size_t)faultSp;
	context2.Rbp = (size_t)fp;
	context2.Rip = (size_t)signal_handler_worker;
	context2.Rdi = code;
	context2.Rsi = (size_t)siginfo;
	context2.Rdx = (size_t)context;
	context2.Rcx = (size_t)returnPoint;
	RtlRestoreContext(&context2, NULL);

The altstack size allocated by Rust is influenced by AT_MINSIGSTKSZ parameter retuned by the Linux kernel: https://github.com/rust-lang/rust/blob/fd9fad6dbcc1bae3cba2a8634339ffa620a49f28/library/std/src/sys/pal/unix/stack_overflow.rs#L269 . My guess is that this value differs between the systems you have tried this on and that's why it works fine on some and not others.

[Wartori54]

I can confirm that removing the altstack before invoking the runtime does fix the issue, thanks!
Rust's sigstack_size evaluates to 8192 on my machine, for reference. I will check the values of the other machines where this issue failed to reproduce when I get the chance.
I'll also add this fix to workarounds for now.

And from an outsider's perspective, maybe the runtime should check the current altstack size when it checks if one is already in place, I don't if there would be other issues with this but it seems like a solid fix for now.
Thanks again!