[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v5] virtio-pmem: PMEM device spec
On Wed, Oct 06 2021, Pankaj Gupta <pankaj.gupta.linux@gmail.com> wrote: > Posting virtio specification for virtio pmem device. Virtio pmem is a > paravirtualized device which allows the guest to bypass page cache. > Virtio pmem kernel driver is merged in Upstream Kernel 5.3. Also, Qemu > device is merged in Qemu 4.1. > > Signed-off-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> > --- > > Incorporated all the suggestions during the review. Request for > merging the spec. > > v3 -> v4 > Text format changes in security implication section - Stefan > Minor text/while space change - Cornelia > > conformance.tex | 16 +++++- > content.tex | 1 + > virtio-pmem.tex | 128 ++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 143 insertions(+), 2 deletions(-) > create mode 100644 virtio-pmem.tex > (...) > +\subsection{Possible security implications}\label{sec:Device Types / PMEM Device / Possible Security Implications} > + > +There could be potential security implications depending on how > +memory mapped backing device is used. By default device emulation > +is done with SHARED memory mapping. There is a contract between driver > +and device to access shared memory region for read or write operations. > + > +If a malicious driver or device maps the same memory region, the attacker > +can make use of known side channel attacks to predict the current state of data. > +If both attacker and victim somehow execute same shared code after a flush > +or evict operation, with difference in execution timing attacker could infer > +another device's data. > + > +\subsection{Countermeasures}\label{sec:Device Types / PMEM Device / Possible Security Implications / Countermeasures} > + > +\subsubsection{ With SHARED mapping}\label{sec:Device Types / PMEM Device / Possible Security Implications / Countermeasures / SHARED} Nit: drop the space after the opening bracket (also below.) > + > +If a device's backing region is shared between multiple devices, this may act > +as a metric for side channel attacks. As a counter measure every device > +should have its own (not shared with another driver) SHARED backing memory. > + > +\subsubsection{ With PRIVATE mapping}\label{sec:Device Types / PMEM Device / Possible Security Implications / Countermeasures / PRIVATE} > +There maybe be chances of side channels attack with PRIVATE > +memory mapping similar to SHARED with read-only shared mappings. > +PRIVATE is not used for virtio pmem making this usecase > +irrelevant. > + > +\subsubsection{ Workload specific mapping}\label{sec:Device Types / PMEM Device / Possible Security Implications / Countermeasures / Workload} > +For SHARED mappings, for the workload is a single application inside > +the driver and there is no risk in sharing data. Device sharing Sorry for noticing this only now, but I have trouble parsing this sentence. Does it mean that you can use SHARED mapping if the workload is a single application? > +same backing region with SHARED mapping can be used as a valid configuration. > + > +\subsubsection{ Prevent cache eviction}\label{sec:Device Types / PMEM Device / Possible Security Implications / Countermeasures / Cache eviction} > +Don't allow device shared region eviction from driver filesystem trim or discard > +like commands with virtio pmem. This rules out any possibility of evict-reload > +cache side channel attacks if backing region is shared (SHARED) > +between mutliple devices. Though if we use per device backing file with > +shared mapping this countermeasure is not required.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]