‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, December 13, 2018 9:36 AM, Mike Larkin <mlar...@azathoth.net> wrote:
> On Thu, Dec 13, 2018 at 12:41:10AM +0000, Adam Steen wrote: > > > 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 > > There are two different maps maintained here. One is in vmd or whatever > userland equivalent you're using to set up Solo5. The other is the map > used by the EPT part in vmm. > > These are shared via uvm_share. I don't know how hard it would be to make > permission changes on one side of the map match the other automatically (nor > am I sure that even makes sense). > > What I could offer would be a new ioctl to set permissions on the EPT side. > Something like "vmm_mprotect_ept" or the like. Would that work? > > -ml Paraphrasing Martin Lucina, Something like "vmm_mprotect_ept" or the like, would work for the project, A nice to have feature of this would be to allow execute-only EPT mappings. see [1] Cheers Adam [1] https://github.com/Solo5/solo5/issues/303#issuecomment-446911276
