Add a shim for uname systemcall #4784

Thomasdezeeuw · 2025-12-22T17:45:14Z

This system call is used to get information about the OS that is run. A10 for example uses this to determine what Linux version is being run and uses it to skip tests that are not supported by older Linux versions, see https://github.com/Thomasdezeeuw/a10/blob/87d04713a3ff5f9d60e1473a72939a1e1bcdaf13/tests/util/mod.rs#L44-L62.

When Miri runs in isolation mode this returns some dummy data based on a recent Linux version. Since the data should only be informative I think it makes sense to return something and allow the program to continue rather than stopping it.

rustbot · 2025-12-22T17:45:17Z

Thank you for contributing to Miri! A reviewer will take a look at your PR, typically within a week or two.
Please remember to not force-push to the PR branch except when you need to rebase due to a conflict or when the reviewer asks you for it.

RalfJung · 2025-12-22T17:47:55Z

Thanks for the PR!

Please extend the PR description, explaining the motivation for why adding this syscall is helpful and why it makes sense to return some hard-coded "dummy" data.

Thomasdezeeuw · 2025-12-22T17:48:28Z

This is my first contribution to Miri, so I probably did something not quite right. If so, please let me know.

I tried to follow the conventions I found in the code as the contribution guide didn't provide a lot of guidance around adding support for new system calls.

Seems like most the BSD family (FreeBSD, OpenBSD, NetBSD, macOS) doesn't have this fields, only Linux.

x86_64 uses i8, aarch64 seems to use u8.

Thomasdezeeuw · 2025-12-22T18:01:35Z

Updated the pr description.

I think I also solved most issues found by the CI, but the Windows one I'm not sure of. In src/shims/unix/env.rs I would expect the code to be unix only, but it seems to be included on Windows as well, which then complains about missing the libc crate. @RalfJung any recommendations on what the best approach would be?

saethlin · 2025-12-23T21:00:25Z

In general, it is wrong to implement shims in Miri by just calling the shimmed function in the shim, which is what you are trying to do. Miri is a cross-interpreter, so it needs to be able to run Linux code on Windows. src/shims/unix is shims used when the --target is unix-like, not when the OS running the interpreter is. I'm using a lot of words because this took me time to get used to and what you tried to do here is a very common mistake when first implementing a shim.

Ideally, you implement a shim by calling a portable function in the standard library. If that is not available, you might be able to use cfg to pick a reasonable implementation on a non-unix system.

saethlin · 2025-12-23T21:01:48Z

src/shims/unix/env.rs

+            return this.set_last_error_and_return_i32(LibcError("EFAULT"));
+        }
+
+        let mut uname_buf = unsafe { std::mem::zeroed() };


FYI, we try to avoid unsafe in the interpreter except where it is absolutely necessary.

Pushed a commit to initialise all fields to zero. Do note that will make porting to new OS, which might have a different set of fields in utsname, a bit more annoying.

You shouldn't use any libc types or functions here. Those correspond to the current host, which is entirely unrelated to the current target.

RalfJung · 2025-12-23T22:48:33Z

If that is not available, you might be able to use cfg to pick a reasonable implementation on a non-unix system.

I think we should avoid this -- I don't want Miri to become a platform abstraction layer full of cfg for all sorts of host systems. We have enough on our hands dealing with all sorts of target systems.

For uname, if we do have a shim at all, it should probably just return something plausible that is hard-coded. But I can easily see that causing more trouble than it solves.

What kernel features does a10 enable based on the kernel version? Chances are, Miri doesn't support them anyway. Everything we support is quite ancient, AFAIK. So it's probably best to just hard-code some old kernel version under cfg(miri) in your crate. (AFAIK, kernel version checking is an anti-pattern anyway. Isn't the usual approach to issue a syscall and check the error code?)

RalfJung · 2025-12-23T22:51:35Z

Looking at the code, this seems to be mostly about io_uring... and sure enough, a10 is an io_uring library. Miri is quite far from having any sort of io_uring support (see #4636). So even if uname works, I'm afraid Miri is not going to get very far in your test suite.

I appreciate the attempt to help, but I'm afraid Miri is not very suited for such super low-level platform-specific code.

Thomasdezeeuw · 2025-12-24T12:17:39Z

What kernel features does a10 enable based on the kernel version? Chances are, Miri doesn't support them anyway.

It doesn't change the code based on the kernel version, it only changes the tests to skip them if a certain feature is not supported and the OS would return some kind of not supported error.

Looking at the code, this seems to be mostly about io_uring... and sure enough, a10 is an io_uring library. Miri is quite far from having any sort of io_uring support (see #4636). So even if uname works, I'm afraid Miri is not going to get very far in your test suite.

To clear up any potential confusion, uname(2) is part of POSIX 2001 and is unrelated to io_uring.

This pr is an experiment for myself to get more familiar with Miri's codebase, I thought I do so while getting slightly closer to getting A10's test suite to run in Miri. The end goal for me would be to contribute support for io_uring (but I'm well aware that's a lot more work than this pr :) ).

Re: making the system call vs. hardcoded values. Let me know what is the best route here, I don't know enough about Miri's internals & goals to argue one way or the other.

RalfJung · 2025-12-24T13:30:38Z

Related prior work: #2494. We ended up not implementing that since it wouldn't really have helped for any usecase.

RalfJung · 2025-12-25T10:27:53Z

Thinking a bit more specifically about this case -- IMO it makes little sense to query the kernel version of the host and use it in the interpreted program. I can't imagine any way of using uname where that would give the desired behavior.

To clear up any potential confusion, uname(2) is part of POSIX 2001 and is unrelated to io_uring.

I understand it has nothing to do with io_uring. :) But the usecase you presented is "I have code that checks the kernel version to see which io_uring flags are supported" (if I understood it correctly). I am not entirely convinced that's a sufficient motivation, for the reasons stated above. However, "it is part of POSIX" is a motivation I could be convinced of.

However, if we give any kind of version number, we have to be a bit careful -- your current implementation uses something involving "Linux" and "6.18" on all Unix targets, which makes little sense for e.g. FreeBSD or Illumos. You're also setting machine to "x86_64" even if the current target is something else. So that definitely needs to be fixed.

Wouldn't it be better to not even try to make this look like a real Linux, and instead just say "this is Miri 0.1" (based on CARGO_PKG_VERSION)? Any code that parses version numbers has to already be know this is fragile and have appropriate fallbacks in place.

@rustbot author

rustbot · 2025-12-25T10:31:56Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

So we don't pretend to be Linux when running in isolation.

Thomasdezeeuw · 2025-12-26T11:15:34Z

I've implemented your suggestion @RalfJung and now it return values that are unlike Like (mostly Miri and Miri's version). I've kept the version field empty.

Does it still make sense to have the actual call when not isolated? If not I can remove that code as well.

Otherwise @rustbot ready

RalfJung · 2025-12-26T17:37:34Z

Does it still make sense to have the actual call when not isolated? If not I can remove that code as well.

No, as I said above I think that does not make sense. That should then also avoid the CI issues.

@rustbot author

The domainname field is only available on Linux and Android. For OS that don't have this field simply ignore the value.

This is used by FreeBSD to implement uname.

Thomasdezeeuw · 2026-01-02T15:43:30Z

This required a bit more work:

the returned architecture (machine field) is done retrieved from the virtual/Miri machine instead of the compiled (binary) constant
We ignore fields that are not present in the type, mainly domainname which is Linux/Android only.
For FreeBSD I added __xuname which is called by uname to do the actual implementation.

@rustbot ready

RalfJung

Thanks! We are entering the fine-tuning phase of this PR. :)

View changes since this review

RalfJung · 2026-01-03T15:07:19Z

src/shims/unix/foreign_items.rs

                let result = this.getpid()?;
                this.write_scalar(result, dest)?;
            }
+            "uname" => {


Apparently that's not universally the symbol name then, given what you had to do for freebsd? Please add a check similar to what we do for flock and other shims to ensure this arm is only taken on OSes where it makes sense.

I think is the correct name for the function, but the implementation for FreeBSD within libc then calls __xuname. I'm not exactly sure what would happen if we remove it from the list here, but I think it would cause errors to be honest.

I tried running it with uname here and with --target x86_64-unknown-freebsd and it does work, then I'll have to figure what the correct names are

This match arm here is just dead code for freebsd target. So just add a check to only allow this arm on the other Unixes.

src/shims/unix/freebsd/foreign_items.rs

tests/pass-dep/libc/libc-uname.rs

RalfJung · 2026-01-03T15:10:20Z

src/shims/unix/env.rs

+            ("sysname", "Miri"),
+            ("nodename", "Miri"),
+            ("release", env!("CARGO_PKG_VERSION")),
+            ("version", ""),


What does "version" usually contain and why is it empty here?

I'm not 100% sure, but I think it's very much OS dependant. Posix defines it as (https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_utsname.h.html):

Current version level of this release.

Some examples:

Arch Linux: #1 SMP PREEMPT_DYNAMIC Thu, 18 Dec 2025 18:00:18 +0000

macOS: Darwin Kernel Version 24.6.0: Wed Oct 15 21:12:15 PDT 2025; root:xnu-11417.140.69.703.14~1/RELEASE_ARM64_T6041

I'm open to suggestion on what to put here for Miri, but realistically I don't think this info is useful in general (outside from maybe logging it).

I don't really understand the distinction between "release" and "version"... but it seems like typically, both contain a version number. So maybe "version" should be "Miri 0.1" or so?

RalfJung · 2026-01-03T15:11:04Z

src/shims/unix/env.rs

+            // Since not all OS have all fields (e.g. domainname), we ignore
+            // fields that are not present.
+            if let Some(field) = this.try_project_field_named(&uname, name)? {


Is domainname the only exception here?

The usual approach we take is to assert that the fields we expect to exist do exist. See fn write_stat_buf. Seems best to remain consistent and follow the same approach here.

Is domainname the only exception here?

Yes. It's not the Posix standard, it seems like a glibc/GNU addition.

The usual approach we take is to assert that the fields we expect to exist do exist. See fn write_stat_buf. Seems best to remain consistent and follow the same approach here.

I'm not sure if the approach in write_stat_buf is a good idea to be honest. It would mean a higher cost when porting to now OS as you need to check if the OS has the field or not. Furthermore if we don't fill the field for an OS that does define it will cause UB if the user didn't initialise the buffer before the call.

I've split the values in required fields (using project_field_named) and optional fields (using the try_ variant, still ignoring if it's missing). Let me know what you think.

I guess it's fine... I'm not a huge fan of try_project_field_named even existing but OTOH we already gave it and use it elsewhere (though not very often). The better API here would somehow check that we did not miss a field but until we have that, we can go with the "try" variant.

Keeping the domainname as optional as it seems like only GNU/Linux uses this field.

Add a shim for uname systemcall

86a9f26

rustbot added the S-waiting-on-review Status: Waiting for a review to complete label Dec 22, 2025

Thomasdezeeuw added 2 commits December 22, 2025 18:56

Add cfg attributes for domainname

c8999eb

Seems like most the BSD family (FreeBSD, OpenBSD, NetBSD, macOS) doesn't have this fields, only Linux.

Fix type issue

afba9c9

x86_64 uses i8, aarch64 seems to use u8.

saethlin reviewed Dec 23, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels Dec 25, 2025

Thomasdezeeuw added 2 commits December 26, 2025 12:10

Replace fake Linux values with Miri values

55928e6

So we don't pretend to be Linux when running in isolation.

Remove unsafe block

1261460

rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels Dec 26, 2025

rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels Dec 26, 2025

Thomasdezeeuw added 4 commits December 28, 2025 16:22

Remove system call

d2cd0d6

Ignore fields not available on all OS

e719ada

The domainname field is only available on Linux and Android. For OS that don't have this field simply ignore the value.

Use machine arch instead of binary arch

b8707f8

Ignore test on Windows

7c3afd4

Add __xuname shim on FreeBSD

30260e7

This is used by FreeBSD to implement uname.

rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels Jan 2, 2026

RalfJung requested changes Jan 3, 2026

View reviewed changes

rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels Jan 3, 2026

Thomasdezeeuw added 3 commits January 5, 2026 11:54

Make fields defined in POSIX required

5917730

Keeping the domainname as optional as it seems like only GNU/Linux uses this field.

Use _size

cec6990

Remove outdated comment

cb3f2f6

Add a shim for uname systemcall #4784

Are you sure you want to change the base?

Add a shim for uname systemcall #4784

Conversation

Thomasdezeeuw commented Dec 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 22, 2025

Uh oh!

RalfJung commented Dec 22, 2025

Uh oh!

Thomasdezeeuw commented Dec 22, 2025

Uh oh!

Thomasdezeeuw commented Dec 22, 2025

Uh oh!

saethlin commented Dec 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Thomasdezeeuw commented Dec 24, 2025

Uh oh!

RalfJung commented Dec 24, 2025

Uh oh!

RalfJung commented Dec 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 25, 2025

Uh oh!

Thomasdezeeuw commented Dec 26, 2025

Uh oh!

RalfJung commented Dec 26, 2025

Uh oh!

Thomasdezeeuw commented Jan 2, 2026

Uh oh!

RalfJung left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Thomasdezeeuw commented Dec 22, 2025 •

edited

Loading

RalfJung commented Dec 23, 2025 •

edited

Loading

RalfJung commented Dec 23, 2025 •

edited

Loading

RalfJung commented Dec 25, 2025 •

edited

Loading

RalfJung left a comment •

edited by rustbot

Loading