WinApi SYSTEM_INFO `dwPageSize` always returning 0

[V0ldek]

This is a rather weird issue I reported first in the page_size crate. When running Miri with any of the Tier 1 Windows targets the crate reports page size 0, which is a fatal error for my use, where I want to allocate aligned to the page boundary.

This is witnessed most easily by the GitHub Action run. My code panics when the page size is not a power of two, so in this case it crashes with:

thread 'main' panicked at 'detected page size 0 that is not a power of two, this is unsupported', src/alignment.rs:111:21

The page size query works perfectly well for Unix targets.

Replication

This can be confirmed by referencing page_size and asking for it like this:

fn main() {
    println!("Page size: {}", page_size::get());
}

and running Miri:

cargo +nightly miri run --target x86_64-pc-windows-gnu

resulting in:

> Page size: 0

Whereas running it without Miri gives the correct result (on my PC it's 4KB):

cargo run

> Page size: 4096

If it matters, the host OS seems to not affect this, the issue is the same running the command both from Unix and Windows.

[RalfJung]

Thanks for the report!

Miri's Windows support is a big hack, barely enough to get our own test suite to pass. Windows is effectively at best a Tier 2 target in Miri. (Not that we have a formal target policy.)

Basically, I don't have a lot of time to spend on Windows support in Miri myself. But help with the Windows support would certainly be appreciated. :D

This is probably caused by some code in this file, though I do not know which function is responsible. Maybe GetSystemInfo?

[V0ldek]

That would certainly be this code:

miri/src/shims/windows/foreign_items.rs

Lines 112 to 126 in b96610b

	// Querying system information
	"GetSystemInfo" => {
	let [system_info] =
	this.check_shim(abi, Abi::System { unwind: false }, link_name, args)?;
	let system_info = this.deref_operand(system_info)?;
	// Initialize with `0`.
	this.write_bytes_ptr(
	system_info.ptr,
	iter::repeat(0u8).take(system_info.layout.size.bytes() as usize),
	)?;
	// Set number of processors.
	let dword_size = Size::from_bytes(4);
	let num_cpus = this.mplace_field(&system_info, 6)?;
	this.write_scalar(Scalar::from_int(NUM_CPUS, dword_size), &num_cpus.into())?;
	}

If I read it correctly, it fills the entire SYSTEM_INFO structure with zeroes and then sets the CPU count to the actual value.

[RalfJung]

Yes, that's exactly what it does. We call num_cpus in our test suite so I got that to pass.^^

Looks like we should add the page_size crate as well, then. (But somewhere in this file, not mixed up with the subcrate test.)

[V0ldek]

Hah, but the page_size crate just calls the WinApi SYSTEM_INFO 😅

https://github.com/Elzair/page_size_rs/blob/290f3da944d0f1c86612172ec84958a9dbf910ac/src/lib.rs#L162-L170

use winapi::um::sysinfoapi::{SYSTEM_INFO, LPSYSTEM_INFO};
use winapi::um::sysinfoapi::GetSystemInfo;

#[inline]
pub fn get() -> usize {
    unsafe {
        let mut info: SYSTEM_INFO = mem::zeroed();
        GetSystemInfo(&mut info as LPSYSTEM_INFO);

        info.dwPageSize as usize
    }
}

[RalfJung]

Okay, this should be easy to fix then. :)
If someone wants to work on this, let me know and I can provide more details if needed.

[V0ldek]

I don't see why that'd make it easy, doesn't that mean we couldn't use page_size for this?

• page_size calls WinApi GetSystemInfo, which with Miri resolves to the code you linked before
• Miri would call page_size to get the response
• page_size calls WinApi GetSystemInfo, which with Miri resolves to the same code as before...

[bjorn3]

Miri would call page_size as native dependency rather than as interpeted code which means that GetSystemInfo ends up as native system call rather than in the miri shim.

[V0ldek]

@bjorn3

Okay, I wasn't entirely sure how Miri works then 😅

I'd happily work on this then, it'd allow me to test my crate on more platforms with Miri. I've never seen this code though, so I'd need details on what would be required of the PR @RalfJung

[V0ldek]

@RalfJung

Actually, I can ask more focused questions.

1. How would I test this change when implemented?
2. Looking at the code for num_cpus I've stumbled upon this:

miri/src/machine.rs

Lines 34 to 38 in b96610b

	// Some global facts about the emulated machine.
	pub const PAGE_SIZE: u64 = 4 * 1024; // FIXME: adjust to target architecture
	pub const STACK_ADDR: u64 = 32 * PAGE_SIZE; // not really about the "stack", but where we start assigning integer addresses to allocations
	pub const STACK_SIZE: u64 = 16 * PAGE_SIZE; // whatever
	pub const NUM_CPUS: u64 = 1;

I see that these constants are also used in posix shim to set some variables. Should we also do justice to this FIXME and switch this to the actual underlying page size?

[RalfJung]

I don't see why that'd make it easy, doesn't that mean we couldn't use page_size for this?

Sorry, what I meant is call page_size in a test inside Miri to ensure that we are implementing whatever APIs it needs on the platforms we support.

Miri would call page_size as native dependency rather than as interpeted code which means that GetSystemInfo ends up as native system call rather than in the miri shim.

Actually I was thinking Miri would just hard-code 4096 as the pagesize, as it does on Unix.

Should we also do justice to this FIXME and switch this to the actual underlying page size?

Right, we may want to do that, but then we should do it on all platforms.
However, I am also not 100% convinced it is the right thing to do -- this would be leaking some "host" information into the target, which is not right. Miri is supposed to emulate an arbitrary target, not something host-specific -- at least without -Zmiri-disable-isolation.

So for now I think it should just also use PAGE_SIZE on windows. Basically you would adjust this code to also fill out the page size field. Then if you want, open a separate issue for no longer hard-coding the page size, but making it user-configurable somehow.

[V0ldek]

Got it. I need guidance on how to test it, though, where would I put the page_size dep and test?

I guess the test would land in tests/run-pass, but I don't know how to add an external crate dependency to those tests.