On Thu, Dec 13, 2018 at 10:32:08PM +0000, Adam Steen wrote: > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Thursday, December 13, 2018 9:36 AM, Mike Larkin <[email protected]> > 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 > > > >
As it might be a while before I can get to this, you could add an ioctl to vmmioctl that took a vm ID, and GPA. Then just use pmap_write_protect on the EPT pmap with the desired permissions and you should be in business. I can help eyeball some diffs but my plate is currently full. Happy to help guide though. -ml
