On 03/18/21 12:28, Lorenzo Susini wrote:
> Hello,
>
> Have some of you successfully used the KVM_MEM_READONLY slot flag?
I think the operation of the pflash device is based on that, yes.
One related commit is 235e8982ad39 ("kvm: support using KVM_MEM_READONLY
flag for regions", 2013-05-29).
So in pflash, there are memory_region_rom_device_set_romd() calls.
When the argument is false (readonly=false, rom_device=true,
*romd_mode=false*), the KVM memory slot is removed completely
(kvm_set_phys_mem()), and all accesses trap to QEMU (work as MMIO).
When the argument is true (readonly=false, rom_device=true,
*romd_mode=true*), a read-only memory slot is used, read/exec doesn't
trap, writes do (kvm_mem_flags(), memory_region_is_romd()).
I've copied Paolo, Vitaly, Peter and Phil.
Thanks
Laszlo
>
> I'm working on a project and I'm trying to protect the guest's IDT by using
> KVM, modifying kvm-all.c.
> I'm able to correctly locate the IDT in the host by reading IDTR with
> KVM_GET_SREGS,
> translating it with KVM_TRANSLATE and, by using the KVMSlot struct, I'm
> able to find the corresponding
> host virtual address. I've double checked the addresses with the Qemu
> Monitor (gpa2hva and gva2gpa) and they
> are correct.
>
> Then, I decided to split the slot where the IDT currently lives into three
> separate ones, setting the IDT in its own private slot and making it
> read-only with KVM_MEM_READONLY:
>
> INITIAL SLOT ===> PRE IDT SLOT | IDT SLOT (KVM_MEM_READONLY) | POST IDT
> SLOT.
>
> By doing this, the VM continues its execution normally. Also, I'm not
> moving memory in the host when
> reassigning slots, so I'm just changing the sizes and the addresses when
> doing kvm_set_userspace_memory_region,
> there's no need to move data anywhere else in my opinion, and this is
> confirmed by the fact that VM, after doing so, behaves normally.
>
> However, when I try to register a new interrupt handler (for instance for
> the edu device, just to try it out), it works perfectly,
> meaning that the IDT is not really read-only. Do you have any idea why? Any
> suggestions on how to solve the problem?
> Of course I've also checked KVM_CAP_READONLY_MEM, no problem with that.
>
> Anyway, is this the right place to post?
>
> Thank you,
> Lorenzo
>
