On 6/25/20 12:02 PM, Alistair Francis wrote:
>> (3) Do we need to validate vbase_prot for write before updating the PTE for
>> Access or Dirty? That seems like a loop-hole to allow silent modification of
>> hypervisor read-only memory.
>
> That's a good point.
>
> Updating the accessed bit seems correct to me as we did access it and
> that doesn't then provide write permissions.
I guess my first question is: Does the stage2 hypervisor pte provide read-only
memory?
If not, all of this is moot.
However, if it does, consider:
(1) The guest os creates a stage1 page table with a leaf table
within the read-only memory. This is obviously hokey.
(2) The guest os accesses a virtual address that utilizes the
aforementioned PTE, the hardware (qemu) updates the
accessed bit.
(3) The read-only page has now been modified. Oops.
>> I do wonder if it might be easier to manage all of this by using additional
>> TLBs to handle the stage2 and physical address spaces. That's probably too
>> invasive for this stage of development though.
>
> Do you mean change riscv_cpu_mmu_index() to take into account
> virtulisation and have more then the current 3 (M, S and U) MMU
> indexes?
I had been thinking that you might be able to use some form of mmu-indexed
load/lookup instead of address_space_ldq. Which would require 1 mmuidx that is
physically mapped (same as M?) and another that uses only the hypervisor's
second stage lookup.
r~
