Hi All The Solo5/Mirage tender is in the process of enforcing that guest executable code is not also writable (W^X), but it looks like vmm is not updating EPT to match the prot from mprotect().
further information https://github.com/Solo5/solo5/issues/303#issuecomment-446503933 copied here for completeness <-- quote --> @mato OpenBSD will not allow an mprotect call with both write and execute enabled, W^X has been enforced at OS level since September 2016. I initially hit this in porting efforts. @adamsteen I know that. What I don't know is, does this subsequent `mprotect()` for a PHDR with `PF_X | PF_R` set (i.e. `.text`) https://github.com/mato/solo5/blob/enforce-nox/tenders/hvt/hvt_elf.c#L215 called on the guest memory range initially set up at https://github.com/mato/solo5/blob/enforce-nox/tenders/hvt/hvt_openbsd.c#L117 have the intended effect on the underlying EPT mapping actually used by vmm to back that memory, i.e. disallowing `PROT_WRITE`. I'm guessing it does as otherwise the OpenBSD port would probably not work at all since the initial mapping does not include `PROT_EXEC`, but given that the FreeBSD vmm has a separate interface for this (VM_MMAP_MEMSEG) I'm not 100% sure. To confirm, could you build the branch at https://github.com/mato/solo5/tree/enforce-nox, manually run the `test_nox` case, and post the output? While you're at it, can you confirm that all the other new tests there pass? <-- end quote --> Is there some way i can ensure that vmm updates the EPT to match the prot from inital mprotect(). Cheers Adam
