[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] nvdimm: allow read/write zero-size namespace la
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH] nvdimm: allow read/write zero-size namespace label |
Date: |
Mon, 16 Jan 2017 13:34:01 +0000 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
On Sat, Jan 14, 2017 at 07:22:28PM +0800, Li Qiang wrote:
> Hello Guangrong,
>
>
> 2017-01-13 17:00 GMT+08:00 Xiao Guangrong <address@hidden>:
>
> >
> >
> > On 01/13/2017 11:02 AM, Li Qiang wrote:
> >
> >> From: Li Qiang <address@hidden>
> >>
> >> The spec doesn't say the namespace label can't be zero
> >> when read/write it. As this is no harmful, just allow
> >> it.
> >>
> >>
> > WHY?
> >
> > The spec said that the label should be at least 128K.
> >
>
> Yes, the label size has a limit, but in NVDIMM_DSM_Interface_Example.pdf
> section 4.5.1
> When the guest get namespace label data, the 'Length' is not limited, if it
> is 0, it will trigger
> this assert.
>
> static void nvdimm_validate_rw_label_data(NVDIMMDevice *nvdimm, uint64_t
> size,
> uint64_t offset)
> {
> assert((nvdimm->label_size >= size + offset) && (offset + size >
> offset));
> }
>
> Though I don't know what the exact behavior of this action in real
> hardware. I just think it should not
> trigger assert and exit when the guest get 0-size label data.
>
> Anyway, this is just a suggestion, If my understand is wrong, just ignore
> this.
QEMU must prevent guests from triggering assertions. If the assertion
causes a core dump then host resources are consumed and this could be a
denial-of-service. An assertion failure in nested virtualization can
kill sibling VMs and is therefore also a denial-of-service.
The size=0 case must be handled in some way (either an error or a nop).
Stefan
signature.asc
Description: PGP signature