All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jason Wang <jasowang@redhat.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	virtualization@lists.linux-foundation.org, linux-mm@kvack.org
Subject: Re: [PATCH v4 3/3] virtio-mem: disallow mapping virtio-mem memory via /dev/mem
Date: Tue, 14 Sep 2021 07:52:13 -0400	[thread overview]
Message-ID: <20210914075046-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <e5344ed1-6aaf-9e0a-a32d-f7cf69fe5a34@redhat.com>

On Tue, Sep 14, 2021 at 11:45:25AM +0200, David Hildenbrand wrote:
> On 03.09.21 09:02, Michael S. Tsirkin wrote:
> > On Thu, Sep 02, 2021 at 06:09:19PM +0200, David Hildenbrand wrote:
> > > We don't want user space to be able to map virtio-mem device memory
> > > directly (e.g., via /dev/mem) in order to have guarantees that in a sane
> > > setup we'll never accidentially access unplugged memory within the
> > > device-managed region of a virtio-mem device, just as required by the
> > > virtio-spec.
> > > 
> > > As soon as the virtio-mem driver is loaded, the device region is visible
> > > in /proc/iomem via the parent device region. From that point on user space
> > > is aware of the device region and we want to disallow mapping anything
> > > inside that region (where we will dynamically (un)plug memory) until
> > > the driver has been unloaded cleanly and e.g., another driver might take
> > > over.
> > > 
> > > By creating our parent IORESOURCE_SYSTEM_RAM resource with
> > > IORESOURCE_EXCLUSIVE, we will disallow any /dev/mem access to our
> > > device region until the driver was unloaded cleanly and removed the
> > > parent region. This will work even though only some memory blocks are
> > > actually currently added to Linux and appear as busy in the resource tree.
> > > 
> > > So access to the region from user space is only possible
> > > a) if we don't load the virtio-mem driver.
> > > b) after unloading the virtio-mem driver cleanly.
> > > 
> > > Don't build virtio-mem if access to /dev/mem cannot be restricticted --
> > > if we have CONFIG_DEVMEM=y but CONFIG_STRICT_DEVMEM is not set.
> > > 
> > > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > > Signed-off-by: David Hildenbrand <david@redhat.com>
> > 
> > 
> > > ---
> > >   drivers/virtio/Kconfig      | 1 +
> > >   drivers/virtio/virtio_mem.c | 4 +++-
> > >   2 files changed, 4 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > > index ce1b3f6ec325..ff80cd03f1d1 100644
> > > --- a/drivers/virtio/Kconfig
> > > +++ b/drivers/virtio/Kconfig
> > > @@ -101,6 +101,7 @@ config VIRTIO_MEM
> > >   	depends on MEMORY_HOTPLUG_SPARSE
> > >   	depends on MEMORY_HOTREMOVE
> > >   	depends on CONTIG_ALLOC
> > > +	depends on !DEVMEM || STRICT_DEVMEM
> > >   	help
> > >   	 This driver provides access to virtio-mem paravirtualized memory
> > >   	 devices, allowing to hotplug and hotunplug memory.
> > 
> > It would be nicer if there was a symbol in the MEMORY_ namespace
> > we can depend on exported by mm and depending on !DEVMEM ||
> > STRICT_DEVMEM.
> > 
> > E.g.
> > 
> > config MEMORY_EXCLUSIVE
> >          def_bool y
> >          depends on !DEVMEM || STRICT_DEVMEM
> > 
> > and then in virtio
> > 	depends on MEMORY_EXCLUSIVE
> > 
> > 
> 
> Yes, but I'm not able to come up with an expressive name. MEMORY_EXCLUSIVE
> can be highly misleading ...


I mean ... it enables IORESOURCE_EXCLUSIVE ... but ok ...
MEMORY_EXCLUSIVE_KERNEL_MAP ?

> 
> > the virtio change itself is ok though:
> > 
> > Acked-by: Michael S. Tsirkin <mst@redhat.com>
> 
> Thanks!
> 
> 
> -- 
> Thanks,
> 
> David / dhildenb


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH v4 3/3] virtio-mem: disallow mapping virtio-mem memory via /dev/mem
Date: Tue, 14 Sep 2021 07:52:13 -0400	[thread overview]
Message-ID: <20210914075046-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <e5344ed1-6aaf-9e0a-a32d-f7cf69fe5a34@redhat.com>

On Tue, Sep 14, 2021 at 11:45:25AM +0200, David Hildenbrand wrote:
> On 03.09.21 09:02, Michael S. Tsirkin wrote:
> > On Thu, Sep 02, 2021 at 06:09:19PM +0200, David Hildenbrand wrote:
> > > We don't want user space to be able to map virtio-mem device memory
> > > directly (e.g., via /dev/mem) in order to have guarantees that in a sane
> > > setup we'll never accidentially access unplugged memory within the
> > > device-managed region of a virtio-mem device, just as required by the
> > > virtio-spec.
> > > 
> > > As soon as the virtio-mem driver is loaded, the device region is visible
> > > in /proc/iomem via the parent device region. From that point on user space
> > > is aware of the device region and we want to disallow mapping anything
> > > inside that region (where we will dynamically (un)plug memory) until
> > > the driver has been unloaded cleanly and e.g., another driver might take
> > > over.
> > > 
> > > By creating our parent IORESOURCE_SYSTEM_RAM resource with
> > > IORESOURCE_EXCLUSIVE, we will disallow any /dev/mem access to our
> > > device region until the driver was unloaded cleanly and removed the
> > > parent region. This will work even though only some memory blocks are
> > > actually currently added to Linux and appear as busy in the resource tree.
> > > 
> > > So access to the region from user space is only possible
> > > a) if we don't load the virtio-mem driver.
> > > b) after unloading the virtio-mem driver cleanly.
> > > 
> > > Don't build virtio-mem if access to /dev/mem cannot be restricticted --
> > > if we have CONFIG_DEVMEM=y but CONFIG_STRICT_DEVMEM is not set.
> > > 
> > > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > > Signed-off-by: David Hildenbrand <david@redhat.com>
> > 
> > 
> > > ---
> > >   drivers/virtio/Kconfig      | 1 +
> > >   drivers/virtio/virtio_mem.c | 4 +++-
> > >   2 files changed, 4 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > > index ce1b3f6ec325..ff80cd03f1d1 100644
> > > --- a/drivers/virtio/Kconfig
> > > +++ b/drivers/virtio/Kconfig
> > > @@ -101,6 +101,7 @@ config VIRTIO_MEM
> > >   	depends on MEMORY_HOTPLUG_SPARSE
> > >   	depends on MEMORY_HOTREMOVE
> > >   	depends on CONTIG_ALLOC
> > > +	depends on !DEVMEM || STRICT_DEVMEM
> > >   	help
> > >   	 This driver provides access to virtio-mem paravirtualized memory
> > >   	 devices, allowing to hotplug and hotunplug memory.
> > 
> > It would be nicer if there was a symbol in the MEMORY_ namespace
> > we can depend on exported by mm and depending on !DEVMEM ||
> > STRICT_DEVMEM.
> > 
> > E.g.
> > 
> > config MEMORY_EXCLUSIVE
> >          def_bool y
> >          depends on !DEVMEM || STRICT_DEVMEM
> > 
> > and then in virtio
> > 	depends on MEMORY_EXCLUSIVE
> > 
> > 
> 
> Yes, but I'm not able to come up with an expressive name. MEMORY_EXCLUSIVE
> can be highly misleading ...


I mean ... it enables IORESOURCE_EXCLUSIVE ... but ok ...
MEMORY_EXCLUSIVE_KERNEL_MAP ?

> 
> > the virtio change itself is ok though:
> > 
> > Acked-by: Michael S. Tsirkin <mst@redhat.com>
> 
> Thanks!
> 
> 
> -- 
> Thanks,
> 
> David / dhildenb

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2021-09-14 11:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02 16:09 [PATCH v4 0/3] virtio-mem: disallow mapping virtio-mem memory via /dev/mem David Hildenbrand
2021-09-02 16:09 ` David Hildenbrand
2021-09-02 16:09 ` [PATCH v4 1/3] kernel/resource: clean up and optimize iomem_is_exclusive() David Hildenbrand
2021-09-02 16:09   ` David Hildenbrand
2021-09-02 16:09 ` [PATCH v4 2/3] kernel/resource: disallow access to exclusive system RAM regions David Hildenbrand
2021-09-02 16:09   ` David Hildenbrand
2021-09-02 16:09 ` [PATCH v4 3/3] virtio-mem: disallow mapping virtio-mem memory via /dev/mem David Hildenbrand
2021-09-02 16:09   ` David Hildenbrand
2021-09-03  7:02   ` Michael S. Tsirkin
2021-09-03  7:02     ` Michael S. Tsirkin
2021-09-14  9:45     ` David Hildenbrand
2021-09-14  9:45       ` David Hildenbrand
2021-09-14 11:52       ` Michael S. Tsirkin [this message]
2021-09-14 11:52         ` Michael S. Tsirkin
2021-09-14 11:57         ` David Hildenbrand
2021-09-14 11:57           ` David Hildenbrand
2021-09-14 12:04           ` Michael S. Tsirkin
2021-09-14 12:04             ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210914075046-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guohanjun@huawei.com \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.