Re: [PATCH v2 3/9] backends/hostmem-file: Add "rom" property to support VM templating with R/O files

[David Hildenbrand <david@redhat.com>]

On 22.08.23 15:27, Markus Armbruster wrote:
> David Hildenbrand <david@redhat.com> writes:
> 
>> For now, "share=off,readonly=on" would always result in us opening the
>> file R/O and mmap'ing the opened file MAP_PRIVATE R/O -- effectively
>> turning it into ROM.
>>
>> Especially for VM templating, "share=off" is a common use case. However,
>> that use case is impossible with files that lack write permissions,
>> because "share=off,readonly=on" will not give us writable RAM.
>>
>> The sole user of ROM via memory-backend-file are R/O NVDIMMs, but as we
>> have users (Kata Containers) that rely on the existing behavior --
>> malicious VMs should not be able to consume COW memory for R/O NVDIMMs --
>> we cannot change the semantics of "share=off,readonly=on"
>>
>> So let's add a new "rom" property with on/off/auto values. "auto" is
>> the default and what most people will use: for historical reasons, to not
>> change the old semantics, it defaults to the value of the "readonly"
>> property.
>>
>> For VM templating, one can now use:
>>      -object memory-backend-file,share=off,readonly=on,rom=off,...
>>
>> But we'll disallow:
>>      -object memory-backend-file,share=on,readonly=on,rom=off,...
>> because we would otherwise get an error when trying to mmap the R/O file
>> shared and writable. An explicit error message is cleaner.
>>
>> We will also disallow for now:
>>      -object memory-backend-file,share=off,readonly=off,rom=on,...
>>      -object memory-backend-file,share=on,readonly=off,rom=on,...
>> It's not harmful, but also not really required for now.
>>
>> Alternatives that were abandoned:
>> * Make "unarmed=on" for the NVDIMM set the memory region container
>>    readonly. We would still see a change of ROM->RAM and possibly run
>>    into memslot limits with vhost-user. Further, there might be use cases
>>    for "unarmed=on" that should still allow writing to that memory
>>    (temporary files, system RAM, ...).
>> * Add a new "readonly=on/off/auto" parameter for NVDIMMs. Similar issues
>>    as with "unarmed=on".
>> * Make "readonly" consume "on/off/file" instead of being a 'bool' type.
>>    This would slightly changes the behavior of the "readonly" parameter:
>>    values like true/false (as accepted by a 'bool'type) would no longer be
>>    accepted.
>>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
> 
> [...]
> 
>>   static void file_backend_instance_finalize(Object *o)
>> diff --git a/qapi/qom.json b/qapi/qom.json
>> index fa3e88c8e6..0cf83c6f39 100644
>> --- a/qapi/qom.json
>> +++ b/qapi/qom.json
>> @@ -668,6 +668,9 @@
>>   # @readonly: if true, the backing file is opened read-only; if false,
>>   #     it is opened read-write.  (default: false)
>>   #
>> +# @rom: whether to create Read Only Memory (ROM).  If set to 'auto', it
>> +#       defaults to the value of @readonly.  (default: auto, since 8.2)
>> +#
>>   # Since: 2.1
>>   ##
> 
> The commit message discusses how @readonly, @rom and @share interact.
> The doc comments don't, and users have to guess.
> 
> I can see two ways to help users:
> 
> 1. Describe their interaction in full, so users can understand how to
> get from them what they need.
> 
> 2. Provide suitable guidance on how to use them.
> 
>>   { 'struct': 'MemoryBackendFileProperties',
>> @@ -677,7 +680,8 @@
>>               '*discard-data': 'bool',
>>               'mem-path': 'str',
>>               '*pmem': { 'type': 'bool', 'if': 'CONFIG_LIBPMEM' },
>> -            '*readonly': 'bool' } }
>> +            '*readonly': 'bool',
>> +            '*rom': 'OnOffAuto' } }
>>   ##
>>   # @MemoryBackendMemfdProperties:
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index 29b98c3d4c..03ce0b0a30 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -4976,7 +4976,7 @@ SRST
>>       they are specified. Note that the 'id' property must be set. These
>>       objects are placed in the '/objects' path.
>>   
>> -    ``-object memory-backend-file,id=id,size=size,mem-path=dir,share=on|off,discard-data=on|off,merge=on|off,dump=on|off,prealloc=on|off,host-nodes=host-nodes,policy=default|preferred|bind|interleave,align=align,offset=offset,readonly=on|off``
>> +    ``-object memory-backend-file,id=id,size=size,mem-path=dir,share=on|off,discard-data=on|off,merge=on|off,dump=on|off,prealloc=on|off,host-nodes=host-nodes,policy=default|preferred|bind|interleave,align=align,offset=offset,readonly=on|off,rom=on|off|auto``
>>           Creates a memory file backend object, which can be used to back
>>           the guest RAM with huge pages.
>>   
>> @@ -5066,6 +5066,14 @@ SRST
>>           The ``readonly`` option specifies whether the backing file is opened
>>           read-only or read-write (default).
>>   
>> +        The ``rom`` option specifies whether to create Read Only Memory (ROM)
>> +        that cannot be modified by the VM. If set to ``on``, the VM cannot
>> +        modify the memory. If set to ``off``, the VM can modify the memory.
>> +        If set to ``auto`` (default), the value of the ``readonly`` property
>> +        is used. This option is primarily helpful for VM templating, where we
>> +        want to open a file readonly (``readonly=on``) and allow private
>> +        modifications of the memory by the VM (``share=off``, ``rom=off``).
>> +
> 
> Here, you provide some guidance.

Is that sufficient in your opinion? Then I could similarly replicate 
(unfortunately) it in the qapi/qom.json doc?

Thanks Markus!

-- 
Cheers,

David / dhildenb