config: Undefine CONFIG_STRICT_DEVMEM for persissting servicing state

[romank-msft]

Persisting memory layout between servicing needs to map GPA regions that don't belong to VTL2, and the kernel doesn't allow that.

Undefine CONFIG_STRICT_DEVMEM to allow that. The ARM64 config doesn't define that, too. An alternate approach might be building out our own infra to match the contraints better.

[jstarks]

Can't we use the /dev/mshv_gpa device?

[jstarks]

(Or whatever it's called.)

We already access non-kernel memory all over the place today, I thought.

[romank-msft]

Sounds right to me. @chris-oo what do you think of using the /dev/mshv_gpa? The what we use for mapping the VTL0 memory

[romank-msft]

That said, perhaps we could avoid using /dev/mem altogether?

[romank-msft]

Looks like /dev/mem is used for getting some config data early in the openvmm_hcl life:

        let dev_mem = fs_err::OpenOptions::new()
            .read(true)
            .write(zero_on_drop)
            .open("/dev/mem")?;
        for range in config_ranges {
            mapping
                .map_file(
                    (range.start() - base) as usize,
                    range.len() as usize,
                    dev_mem.file(),
                    range.start(),
                    zero_on_drop,
                )
                .context("failed to memory map igvm parameters")?;
        }

If that data is passed in the DT, the user mode will get that from sysfs, and we can disable /dev/mem althogether

[smalis-msft]

That's been on the wishlist for a while microsoft/openvmm#263

[chris-oo]

That data isn't provided via dt - it's too large so it's still left in RAM. But I wonder if we stopped describing the ranges as E820_RESERVED could we still use /dev/mshv_gpa?

[romank-msft]

The kernel might take it if the range is not marked as reserved?

In a fantasy land, could have VTL3 with a minimum dispatch loop playing key-value store 😄

[romank-msft]

Perhaps the kernel could go over the special regions in DT and provide them as memory mapped files?

[allenpais]

Perhaps the kernel could go over the special regions in DT and provide them as memory mapped files?

/dev/mem allows raw physical memory access from userspace. Enabling CONFIG_STRICT_DEVMEM in the Linux kernel introduces stricter access controls on /dev/mem, which can be very important for system security.

[romank-msft]

Perhaps the kernel could go over the special regions in DT and provide them as memory mapped files?

/dev/mem allows raw physical memory access from userspace. Enabling CONFIG_STRICT_DEVMEM in the Linux kernel introduces stricter access controls on /dev/mem, which can be very important for system security.

That's why using it, in any form, is bad. Too unrestricted, even with CONFIG_STRICT_DEVMEM. If we can get rid of using it, would be awesome.