Re: vmm(4) update EPT to match mprotect in intial elf load. (Solo5 using vmm, doesn't involved vmd)
On Thu, Dec 13, 2018 at 10:32:08PM +, Adam Steen wrote: > ‐‐‐ Original Message ‐‐‐ > On Thursday, December 13, 2018 9:36 AM, Mike Larkin > wrote: > > > On Thu, Dec 13, 2018 at 12:41:10AM +, 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
Re: vmm(4) update EPT to match mprotect in intial elf load. (Solo5 using vmm, doesn't involved vmd)
‐‐‐ Original Message ‐‐‐ On Thursday, December 13, 2018 9:36 AM, Mike Larkin wrote: > On Thu, Dec 13, 2018 at 12:41:10AM +, 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
Re: vmm(4) update EPT to match mprotect in intial elf load. (Solo5 using vmm, doesn't involved vmd)
On Thu, Dec 13, 2018 at 12:41:10AM +, 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
vmm(4) update EPT to match mprotect in intial elf load. (Solo5 using vmm, doesn't involved vmd)
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
