diff options
author | David Hildenbrand <david@redhat.com> | 2023-09-06 14:04:58 +0200 |
---|---|---|
committer | David Hildenbrand <david@redhat.com> | 2023-09-19 10:23:21 +0200 |
commit | 4d6b23f7e2b7a34a6ab3b7c40693d8b1a0dee0b5 (patch) | |
tree | 370fd1ad3e54b383f3e4c46ba1c69821724a1721 /module-common.c | |
parent | b2cccb52bd9bef2948a150d204b20119b6c3ad58 (diff) |
softmmu/physmem: Fail creation of new files in file_ram_open() with readonly=true
Currently, if a file does not exist yet, file_ram_open() will create new
empty file and open it writable. However, it even does that when
readonly=true was specified.
Specifying O_RDONLY instead to create a new readonly file would
theoretically work, however, ftruncate() will refuse to resize the new
empty file and we'll get a warning:
ftruncate: Invalid argument
And later eventually more problems when actually mmap'ing that file and
accessing it.
If someone intends to let QEMU open+mmap a file read-only, better
create+resize+fill that file ahead of time outside of QEMU context.
We'll now fail with:
./qemu-system-x86_64 \
-object memory-backend-file,id=ram0,mem-path=tmp,readonly=true,size=1g
qemu-system-x86_64: can't open backing store tmp for guest RAM: No such file or directory
All use cases of readonly files (R/O NVDIMMs, VM templating) work on
existing files, so silently creating new files might just hide user
errors when accidentally specifying a non-existent file.
Note that the only memory-backend-file will end up calling
memory_region_init_ram_from_file() -> qemu_ram_alloc_from_file() ->
file_ram_open().
Move error reporting to the single caller.
Message-ID: <20230906120503.359863-7-david@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Diffstat (limited to 'module-common.c')
0 files changed, 0 insertions, 0 deletions