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


Reply via email to