Re: [PATCH v1 1/3] softmmu/physmem: fallback to opening guest RAM file as readonly in a MAP_PRIVATE mapping

[David Hildenbrand <david@redhat.com>]

>> Commit 86635aa4e9d627d5142b81c57a33dd1f36627d07 mentions that we don't
>> want guests to be able to dirty pages on the host. The change you're
>> proposing would not protect against guests that dirty the memory.
> 
> The guest could write memory but not modify the file. Only with
> "share=off,readonly=on" of course, not with "share=on,readonly=on".
> 
>>
>> I don't know how important that requirement was (that commit was a
>> request from Kata Containers).
> 
> Let me take a look if Kata passes "share=on,readonly=on" or
> "share=off,readonly=off".
> 

At least their R/O DIMM test generates:

-device nvdimm,id=nv0,memdev=mem0,unarmed=on -object 
memory-backend-file,id=mem0,mem-path=/root,size=65536,readonly=on

So they are assuming readonly with implied share=off creates ROM. If 
only they would have specified share=on ...

One way would be letting the R/O nvdimm set the MR container to 
readonly. Then that guest also shouldn't be able to modify that memory. 
Let me think about that.

-- 
Cheers,

David / dhildenb