[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for 5.0 v1 1/2] riscv: Don't use stage-2 PTE lookup protectio
From: |
Richard Henderson |
Subject: |
Re: [PATCH for 5.0 v1 1/2] riscv: Don't use stage-2 PTE lookup protection flags |
Date: |
Sat, 27 Jun 2020 15:48:36 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
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~