All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@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 12:22:36 -0700	[thread overview]
Message-ID: <YrYO/KAa2bqmxEIu@Asurada-Nvidia> (raw)
In-Reply-To: <20220624135615.GO4147@nvidia.com>

On Fri, Jun 24, 2022 at 10:56:15AM -0300, Jason Gunthorpe wrote:

> > How about the updated commit log below? Thanks.
> > 
> > The pinned PFN list returned from vfio_pin_pages() is converted using
> > page_to_pfn(), so direct access via memcpy() will crash on S390 if the
> > PFN is an IO PFN, as we have to use the memcpy_to/fromio(), which uses
> > the special s390 IO access instructions.
> > 
> > As a standard practice for security purpose, add kmap_local_page() to
> > block any IO memory from ever getting into this call path.
> 
> The kmap_local_page is not about the IO memory, the switch to struct
> page is what is protecting against IO memory.
> 
> Use kmap_local_page() is just the correct way to convert a struct page
> into a CPU address to use with memcpy and it is a NOP on S390 because
> it doesn't use highmem/etc.

I thought the whole purpose of switching to "struct page *" was to use
kmap_local_page() for the memcpy call, and the combination of these two
does the protection. Do you mind explaining how the switching part does
the protection?

Thanks!

WARNING: multiple messages have this Message-ID (diff)
From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@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 12:22:36 -0700	[thread overview]
Message-ID: <YrYO/KAa2bqmxEIu@Asurada-Nvidia> (raw)
In-Reply-To: <20220624135615.GO4147@nvidia.com>

On Fri, Jun 24, 2022 at 10:56:15AM -0300, Jason Gunthorpe wrote:

> > How about the updated commit log below? Thanks.
> > 
> > The pinned PFN list returned from vfio_pin_pages() is converted using
> > page_to_pfn(), so direct access via memcpy() will crash on S390 if the
> > PFN is an IO PFN, as we have to use the memcpy_to/fromio(), which uses
> > the special s390 IO access instructions.
> > 
> > As a standard practice for security purpose, add kmap_local_page() to
> > block any IO memory from ever getting into this call path.
> 
> The kmap_local_page is not about the IO memory, the switch to struct
> page is what is protecting against IO memory.
> 
> Use kmap_local_page() is just the correct way to convert a struct page
> into a CPU address to use with memcpy and it is a NOP on S390 because
> it doesn't use highmem/etc.

I thought the whole purpose of switching to "struct page *" was to use
kmap_local_page() for the memcpy call, and the combination of these two
does the protection. Do you mind explaining how the switching part does
the protection?

Thanks!

  reply	other threads:[~2022-06-24 19:22 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 [this message]
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
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=YrYO/KAa2bqmxEIu@Asurada-Nvidia \
    --to=nicolinc@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=jgg@nvidia.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=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.