On Tue, Aug 22, 2023 at 01:44:49PM +0200, David Hildenbrand wrote:
> Currently, when using a true R/O NVDIMM (ROM memory backend) with a label
> area, the VM can easily crash QEMU by trying to write to the label area,
> because the ROM memory is mmap'ed without PROT_WRITE.
>
> [root@vm-0 ~]# ndctl disable-region region0
> disabled 1 region
> [root@vm-0 ~]# ndctl zero-labels nmem0
> -> QEMU segfaults
>
> Let's remember whether we have a ROM memory backend and properly
> reject the write request:
>
> [root@vm-0 ~]# ndctl disable-region region0
> disabled 1 region
> [root@vm-0 ~]# ndctl zero-labels nmem0
> zeroed 0 nmem
>
> In comparison, on a system with a R/W NVDIMM:
>
> [root@vm-0 ~]# ndctl disable-region region0
> disabled 1 region
> [root@vm-0 ~]# ndctl zero-labels nmem0
> zeroed 1 nmem
>
> For ACPI, just return "unsupported", like if no label exists. For spapr,
> return "H_P2", similar to when no label area exists.
>
> Could we rely on the "unarmed" property? Maybe, but it looks cleaner to
> only disallow what certainly cannot work.
>
> After all "unarmed=on" primarily means: cannot accept persistent writes. In
> theory, there might be setups where devices with "unarmed=on" set could
> be used to host non-persistent data (temporary files, system RAM, ...); for
> example, in Linux, admins can overwrite the "readonly" setting and still
> write to the device -- which will work as long as we're not using ROM.
> Allowing writing label data in such configurations can make sense.
>
> Fixes: dbd730e85987 ("nvdimm: check -object memory-backend-file, readonly=on
> option")
> Signed-off-by: David Hildenbrand <[email protected]>
> ---
> hw/acpi/nvdimm.c | 11 ++++++++---
> hw/mem/nvdimm.c | 10 +++++++---
> hw/ppc/spapr_nvdimm.c | 3 ++-
> include/hw/mem/nvdimm.h | 6 ++++++
> 4 files changed, 23 insertions(+), 7 deletions(-)Reviewed-by: Stefan Hajnoczi <[email protected]>
signature.asc
Description: PGP signature
