On 5/3/21 12:40 PM, Andy Lutomirski wrote: > >> On May 3, 2021, at 10:19 AM, Brijesh Singh <brijesh.singh@xxxxxxx> wrote: >> >> >>> On 5/3/21 11:15 AM, Dave Hansen wrote: >>>> On 5/3/21 8:37 AM, Brijesh Singh wrote: >>>> GHCB was just an example. Another example is a vfio driver accessing the >>>> shared page. If those pages are not marked shared then kernel access >>>> will cause an RMP fault. Ideally we should not be running into this >>>> situation, but if we do, then I am trying to see how best we can avoid >>>> the host crashes. >>> I'm confused. Are you suggesting that the VFIO driver could be passed >>> an address such that the host kernel would blindly try to write private >>> guest memory? >> Not blindly. But a guest could trick a VMM (qemu) to ask the host driver >> to access a GPA which is guest private page (Its a hypothetical case, so >> its possible that I may missing something). Let's see with an example: >> >> - A guest provides a GPA to VMM to write to (e.g DMA operation). >> >> - VMM translates the GPA->HVA and calls down to host kernel with the HVA. >> >> - The host kernel may pin the HVA to get the PFN for it and then kmap(). >> Write to the mapped PFN will cause an RMP fault if the guest provided >> GPA was not a marked shared in the RMP table. In an ideal world, a guest >> should *never* do this but what if it does ? >> >> >>> The host kernel *knows* which memory is guest private and what is >>> shared. It had to set it up in the first place. It can also consult >>> the RMP at any time if it somehow forgot. >>> >>> So, this scenario seems to be that the host got a guest physical address >>> (gpa) from the guest, it did a gpa->hpa->hva conversion and then wrote >>> the page all without bothering to consult the RMP. Shouldn't the the >>> gpa->hpa conversion point offer a perfect place to determine if the page >>> is shared or private? >> The GPA->HVA is typically done by the VMM, and HVA->HPA is done by the >> host drivers. So, only time we could verify is after the HVA->HPA. One >> of my patch provides a snp_lookup_page_in_rmptable() helper that can be >> used to query the page state in the RMP table. This means the all the >> host backend drivers need to enlightened to always read the RMP table >> before making a write access to guest provided GPA. A good guest should >> *never* be using a private page for the DMA operation and if it does >> then the fault handler introduced in this patch can avoid the host crash >> and eliminate the need to enlightened the drivers to check for the >> permission before the access. > Can we arrange for the page walk plus kmap process to fail? Sure, I will look into all the drivers which do a walk plus kmap to make sure that they fail instead of going into the fault path. Should I drop this patch or keep it just in the case we miss something?
