All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	kwankhede@nvidia.com, corbet@lwn.net, hca@linux.ibm.com,
	gor@linux.ibm.com, agordeev@linux.ibm.com,
	borntraeger@linux.ibm.com, svens@linux.ibm.com,
	zhenyuw@linux.intel.com, zhi.a.wang@intel.com,
	jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
	rodrigo.vivi@intel.com, tvrtko.ursulin@linux.intel.com,
	airlied@linux.ie, daniel@ffwll.ch, farman@linux.ibm.com,
	mjrosato@linux.ibm.com, pasic@linux.ibm.com,
	vneethv@linux.ibm.com, oberpar@linux.ibm.com,
	freude@linux.ibm.com, akrowiak@linux.ibm.com,
	jjherne@linux.ibm.com, alex.williamson@redhat.com,
	cohuck@redhat.com, kevin.tian@intel.com, jchrist@linux.ibm.com,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	intel-gvt-dev@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [RFT][PATCH v1 5/6] vfio/ccw: Add kmap_local_page() for memcpy
Date: Fri, 24 Jun 2022 19:42:45 -0300	[thread overview]
Message-ID: <20220624224245.GC4147@nvidia.com> (raw)
In-Reply-To: <YrYayPvA7XlCZLQ2@Asurada-Nvidia>

On Fri, Jun 24, 2022 at 01:12:56PM -0700, Nicolin Chen wrote:

> > The kmap_local_page() arose because the code doing memcpy had to be
> > updated to go from a struct page to a void * for use with memcpy and
> > the kmap_local_page() is the correct API to use for that.
> > 
> > The existing code which casts a pfn to a void * is improper.
> 
> Yes.
> 
> If I understand everything correctly:
> 
> A PFN is not secure enough to promise that the memory is not IO. And
> direct access via memcpy() that only handles CPU memory will crash on
> S390 if the PFN is an IO PFN, as we have to use the memcpy_to/fromio()
> that uses the special S390 IO access instructions. On the other hand,
> a "struct page *" is always a CPU coherent thing that fits memcpy().
> 
> Also, casting a PFN to "void *" for memcpy() is not an proper practice,
> kmap_local_page() is the correct API to call here, though S390 doesn't
> use highmem, which means kmap_local_page() is a NOP.
> 
> There's a following patch changing the vfio_pin_pages() API to return
> a list of "struct page *" instead of PFNs. It will block any IO memory
> from ever getting into this call path, for such a security purpose. In
> this patch, add kmap_local_page() to prepare for that.

Yes, basically

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: mjrosato@linux.ibm.com, linux-doc@vger.kernel.org,
	airlied@linux.ie, kevin.tian@intel.com,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	kwankhede@nvidia.com, vneethv@linux.ibm.com,
	agordeev@linux.ibm.com, pasic@linux.ibm.com, kvm@vger.kernel.org,
	corbet@lwn.net, Christoph Hellwig <hch@infradead.org>,
	borntraeger@linux.ibm.com, intel-gfx@lists.freedesktop.org,
	zhi.a.wang@intel.com, jjherne@linux.ibm.com,
	farman@linux.ibm.com, jchrist@linux.ibm.com, gor@linux.ibm.com,
	linux-s390@vger.kernel.org, hca@linux.ibm.com,
	alex.williamson@redhat.com, freude@linux.ibm.com,
	rodrigo.vivi@intel.com, intel-gvt-dev@lists.freedesktop.org,
	akrowiak@linux.ibm.com, tvrtko.ursulin@linux.intel.com,
	cohuck@redhat.com, oberpar@linux.ibm.com, svens@linux.ibm.com
Subject: Re: [RFT][PATCH v1 5/6] vfio/ccw: Add kmap_local_page() for memcpy
Date: Fri, 24 Jun 2022 19:42:45 -0300	[thread overview]
Message-ID: <20220624224245.GC4147@nvidia.com> (raw)
In-Reply-To: <YrYayPvA7XlCZLQ2@Asurada-Nvidia>

On Fri, Jun 24, 2022 at 01:12:56PM -0700, Nicolin Chen wrote:

> > The kmap_local_page() arose because the code doing memcpy had to be
> > updated to go from a struct page to a void * for use with memcpy and
> > the kmap_local_page() is the correct API to use for that.
> > 
> > The existing code which casts a pfn to a void * is improper.
> 
> Yes.
> 
> If I understand everything correctly:
> 
> A PFN is not secure enough to promise that the memory is not IO. And
> direct access via memcpy() that only handles CPU memory will crash on
> S390 if the PFN is an IO PFN, as we have to use the memcpy_to/fromio()
> that uses the special S390 IO access instructions. On the other hand,
> a "struct page *" is always a CPU coherent thing that fits memcpy().
> 
> Also, casting a PFN to "void *" for memcpy() is not an proper practice,
> kmap_local_page() is the correct API to call here, though S390 doesn't
> use highmem, which means kmap_local_page() is a NOP.
> 
> There's a following patch changing the vfio_pin_pages() API to return
> a list of "struct page *" instead of PFNs. It will block any IO memory
> from ever getting into this call path, for such a security purpose. In
> this patch, add kmap_local_page() to prepare for that.

Yes, basically

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: mjrosato@linux.ibm.com, linux-doc@vger.kernel.org,
	airlied@linux.ie, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, kwankhede@nvidia.com,
	vneethv@linux.ibm.com, agordeev@linux.ibm.com,
	pasic@linux.ibm.com, kvm@vger.kernel.org, corbet@lwn.net,
	Christoph Hellwig <hch@infradead.org>,
	borntraeger@linux.ibm.com, intel-gfx@lists.freedesktop.org,
	jjherne@linux.ibm.com, farman@linux.ibm.com,
	jchrist@linux.ibm.com, gor@linux.ibm.com,
	linux-s390@vger.kernel.org, hca@linux.ibm.com,
	freude@linux.ibm.com, rodrigo.vivi@intel.com,
	intel-gvt-dev@lists.freedesktop.org, akrowiak@linux.ibm.com,
	cohuck@redhat.com, oberpar@linux.ibm.com, svens@linux.ibm.com
Subject: Re: [Intel-gfx] [RFT][PATCH v1 5/6] vfio/ccw: Add kmap_local_page() for memcpy
Date: Fri, 24 Jun 2022 19:42:45 -0300	[thread overview]
Message-ID: <20220624224245.GC4147@nvidia.com> (raw)
In-Reply-To: <YrYayPvA7XlCZLQ2@Asurada-Nvidia>

On Fri, Jun 24, 2022 at 01:12:56PM -0700, Nicolin Chen wrote:

> > The kmap_local_page() arose because the code doing memcpy had to be
> > updated to go from a struct page to a void * for use with memcpy and
> > the kmap_local_page() is the correct API to use for that.
> > 
> > The existing code which casts a pfn to a void * is improper.
> 
> Yes.
> 
> If I understand everything correctly:
> 
> A PFN is not secure enough to promise that the memory is not IO. And
> direct access via memcpy() that only handles CPU memory will crash on
> S390 if the PFN is an IO PFN, as we have to use the memcpy_to/fromio()
> that uses the special S390 IO access instructions. On the other hand,
> a "struct page *" is always a CPU coherent thing that fits memcpy().
> 
> Also, casting a PFN to "void *" for memcpy() is not an proper practice,
> kmap_local_page() is the correct API to call here, though S390 doesn't
> use highmem, which means kmap_local_page() is a NOP.
> 
> There's a following patch changing the vfio_pin_pages() API to return
> a list of "struct page *" instead of PFNs. It will block any IO memory
> from ever getting into this call path, for such a security purpose. In
> this patch, add kmap_local_page() to prepare for that.

Yes, basically

Jason

  reply	other threads:[~2022-06-24 22:42 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-16 23:52 [RFT][PATCH v1 0/6] Update vfio_pin/unpin_pages API Nicolin Chen
2022-06-16 23:52 ` Nicolin Chen
2022-06-16 23:52 ` [RFT][PATCH v1 1/6] vfio/ap: Pass in physical address of ind to ap_aqic() Nicolin Chen
2022-06-16 23:52   ` Nicolin Chen
2022-06-20 10:00   ` Harald Freudenberger
2022-06-20 10:00     ` Harald Freudenberger
2022-06-21 21:01     ` Nicolin Chen
2022-06-21 21:01       ` [Intel-gfx] " Nicolin Chen
2022-06-21 21:01       ` Nicolin Chen
2022-06-16 23:52 ` [RFT][PATCH v1 2/6] vfio/ccw: Only pass in contiguous pages Nicolin Chen
2022-06-16 23:52   ` Nicolin Chen
2022-06-16 23:52 ` [RFT][PATCH v1 3/6] vfio: Pass in starting IOVA to vfio_pin/unpin_pages API Nicolin Chen
2022-06-16 23:52   ` Nicolin Chen
2022-06-17  8:42   ` Christoph Hellwig
2022-06-17  8:42     ` [Intel-gfx] " Christoph Hellwig
2022-06-17 21:57     ` Nicolin Chen
2022-06-17 21:57       ` Nicolin Chen
2022-06-22  1:18     ` Nicolin Chen
2022-06-22  1:18       ` [Intel-gfx] " Nicolin Chen
2022-06-22  1:18       ` Nicolin Chen
2022-06-16 23:52 ` [RFT][PATCH v1 4/6] vfio: Rename user_iova of vfio_dma_rw() Nicolin Chen
2022-06-16 23:52   ` Nicolin Chen
2022-06-16 23:52 ` [RFT][PATCH v1 5/6] vfio/ccw: Add kmap_local_page() for memcpy Nicolin Chen
2022-06-16 23:52   ` Nicolin Chen
2022-06-17  8:44   ` Christoph Hellwig
2022-06-17  8:44     ` [Intel-gfx] " Christoph Hellwig
2022-06-17 21:58     ` Nicolin Chen
2022-06-17 21:58       ` Nicolin Chen
2022-06-20  2:57     ` Jason Gunthorpe
2022-06-20  2:57       ` [Intel-gfx] " Jason Gunthorpe
2022-06-20  2:57       ` Jason Gunthorpe
2022-06-20  6:32       ` Christoph Hellwig
2022-06-20  6:32         ` [Intel-gfx] " Christoph Hellwig
2022-06-20 15:39         ` Jason Gunthorpe
2022-06-20 15:39           ` [Intel-gfx] " Jason Gunthorpe
2022-06-20 15:39           ` Jason Gunthorpe
2022-06-21 21:21         ` Nicolin Chen
2022-06-21 21:21           ` [Intel-gfx] " Nicolin Chen
2022-06-21 21:21           ` Nicolin Chen
2022-06-24 13:56           ` Jason Gunthorpe
2022-06-24 13:56             ` [Intel-gfx] " Jason Gunthorpe
2022-06-24 13:56             ` Jason Gunthorpe
2022-06-24 19:22             ` Nicolin Chen
2022-06-24 19:22               ` Nicolin Chen
2022-06-24 19:30               ` Jason Gunthorpe
2022-06-24 19:30                 ` [Intel-gfx] " Jason Gunthorpe
2022-06-24 19:30                 ` Jason Gunthorpe
2022-06-24 20:12                 ` Nicolin Chen
2022-06-24 20:12                   ` Nicolin Chen
2022-06-24 22:42                   ` Jason Gunthorpe [this message]
2022-06-24 22:42                     ` [Intel-gfx] " Jason Gunthorpe
2022-06-24 22:42                     ` Jason Gunthorpe
2022-06-16 23:52 ` [RFT][PATCH v1 6/6] vfio: Replace phys_pfn with phys_page for vfio_pin_pages() Nicolin Chen
2022-06-16 23:52   ` Nicolin Chen
2022-06-17  8:54   ` Christoph Hellwig
2022-06-17  8:54     ` [Intel-gfx] " Christoph Hellwig
2022-06-17 22:06     ` Nicolin Chen
2022-06-17 22:06       ` Nicolin Chen
2022-06-19  6:18       ` Christoph Hellwig
2022-06-19  6:18         ` [Intel-gfx] " Christoph Hellwig
2022-06-19  6:41         ` Nicolin Chen
2022-06-19  6:41           ` Nicolin Chen
2022-06-20  3:00     ` Jason Gunthorpe
2022-06-20  3:00       ` [Intel-gfx] " Jason Gunthorpe
2022-06-20  3:00       ` Jason Gunthorpe
2022-06-20  5:51       ` Christoph Hellwig
2022-06-20  5:51         ` [Intel-gfx] " Christoph Hellwig
2022-06-20  6:37         ` Christoph Hellwig
2022-06-20  6:37           ` [Intel-gfx] " Christoph Hellwig
2022-06-20 15:36           ` Jason Gunthorpe
2022-06-20 15:36             ` [Intel-gfx] " Jason Gunthorpe
2022-06-20 15:36             ` Jason Gunthorpe
2022-06-21 21:47             ` Nicolin Chen
2022-06-21 21:47               ` [Intel-gfx] " Nicolin Chen
2022-06-21 21:47               ` Nicolin Chen

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=20220624224245.GC4147@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=agordeev@linux.ibm.com \
    --cc=airlied@linux.ie \
    --cc=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=corbet@lwn.net \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=farman@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=hch@infradead.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jchrist@linux.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=nicolinc@nvidia.com \
    --cc=oberpar@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=svens@linux.ibm.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=vneethv@linux.ibm.com \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhi.a.wang@intel.com \
    /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.