All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <dominique.martinet-KCE40YydGKI@public.gmane.org>
To: Shachar Raindel <raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Cc: "<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
	(linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [oss-security] RE: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access
Date: Fri, 3 Apr 2015 14:43:56 +0200	[thread overview]
Message-ID: <20150403124356.GA3141@u-blusson> (raw)
In-Reply-To: <AM3PR05MB0935F9F1011E30F11C2A08BDDCF10-LOZWmgKjnYgQouBfZGh8ttqRiQSDpxhJvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>

Hi,

Shachar Raindel wrote on Fri, Apr 03, 2015 at 11:49:13AM +0000:
> > couldn't get it to work - ibv_reg_mr would return EINVAL on an address
> > obtained by mmap.
> 
> Were you mmaping a normal disk file, or was the mmap targeting an MMIO of
> another hardware device? mmap of a normal disk file should work also with
> normal memory registration, assuming you are providing the proper length.

On a proper file.
It was a year or two ago, I actually tried again now and it does seem
to work alright even on older kernels... I wonder what I did wrong back
then!

> mmap of the MMIO area of another hardware device (i.e. interfacing an FPGA,
> NVRAM, or similar things) requires some code changes on both sides. The
> current kernel code in the infiniband side is using get_user_pages, which
> does not support MMIO pages. The proposed PeerDirect patches [1] allows peer
> device to declare ownership of virtual address ranges, and enable such
> registration. However, these patches are have not yet been merged upstream.

Interesting, I don't need this right now but it's good to know.

> > Conceptually as well I'm not sure how it's supposed to work, mmap should
> > only actually issue reads when memory access issues page faults (give or
> > take suitable readahead logic), but I don't think direct memory access
> > from the IB/RDMA adapter would issue such page faults ?
> 
> You are correct. RDMA adapters without ODP support do not issue page faults.
> Instead, during memory registration, the ib_umem code calls get_user_pages,
> which ensures all relevant pages are in memory, and pins them as needed.
> 
> > Likewise on writes, would need the kernel to notice memory has been
> > written and pages are dirty/needs flushing.
> > 
> 
> Similarly, when deregistering a writable memory region, the kernel driver
> marks all pages as dirty before unpinning them. You can see the code doing
> this in [2].

Ok this makes sense, thanks for clearing it up.

> Liran Liss gave a presentation about ODP at OFA [3]. The technology is
> available for ConnectIB devices using the most recent firmware and kernel
> versions above 3.19.

I don't have any recent kernel around, but I'll give it a shot next
week.
(I'm working on a userspace file server, nfs-ganesha, so being able to
mmap a file and use it directly for I/O is very promising for me!)


> [1] http://www.spinics.net/lists/linux-rdma/msg21770.html
> [2] http://lxr.free-electrons.com/source/drivers/infiniband/core/umem.c#L62
> [3] https://www.openfabrics.org/images/Workshops_2014/DevWorkshop/presos/Tuesday/pdf/09.30_2014_OFA_Workshop_ODP_update_final.pdf and https://www.youtube.com/watch?v=KbrlsXQbHCw


Thanks for the detailed reply, I'll dig a bit further and come back
straight to the list if need to.

-- 
Dominique Martinet
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2015-04-03 12:43 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18 17:39 CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Shachar Raindel
     [not found] ` <AM3PR05MB0935AABF569F15EA846B8E72DC000-LOZWmgKjnYgQouBfZGh8ttqRiQSDpxhJvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2015-04-01 17:28   ` Roland Dreier
2015-04-02  7:52     ` Shachar Raindel
2015-04-02 16:32       ` Roland Dreier
2015-04-02 16:39         ` Shachar Raindel
2015-04-02 10:04 ` Yann Droneaud
     [not found]   ` <1427969085.17020.5.camel-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-04-02 10:52     ` Shachar Raindel
2015-04-02 10:52       ` Shachar Raindel
2015-04-02 10:52       ` Shachar Raindel
     [not found]       ` <AM3PR05MB0935AA4898B4B519D2DAA3C4DCF20-LOZWmgKjnYgQouBfZGh8ttqRiQSDpxhJvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2015-04-02 13:30         ` Yann Droneaud
2015-04-02 13:30           ` Yann Droneaud
2015-04-02 15:18           ` Haggai Eran
2015-04-02 16:35             ` Yann Droneaud
2015-04-02 16:44               ` Shachar Raindel
2015-04-02 16:44                 ` Shachar Raindel
     [not found]                 ` <AM2PR05MB0929FB71C5A4DE92A7709F92DCF20-Wc3DjHnhGicijy4iGQu0rtqRiQSDpxhJvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2015-04-02 18:12                   ` Haggai Eran
2015-04-02 18:12                     ` Haggai Eran
2015-04-02 18:12                     ` Haggai Eran
     [not found]                     ` <1427998401240.52348-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2015-04-13 13:29                       ` Yann Droneaud
2015-04-13 13:29                         ` Yann Droneaud
     [not found]                         ` <1428931781.22575.232.camel-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-04-14  8:11                           ` Haggai Eran
2015-04-14  8:11                             ` Haggai Eran
2015-04-02 20:40                 ` Yann Droneaud
     [not found]                   ` <1428007208.22575.104.camel-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-04-03  8:39                     ` Haggai Eran
2015-04-03  8:39                       ` Haggai Eran
2015-04-03  8:39                       ` Haggai Eran
2015-04-03 11:49                       ` Yann Droneaud
     [not found]                 ` <20150402174401.GA24285@nautica>
2015-04-03 11:49                   ` [oss-security] " Shachar Raindel
     [not found]                     ` <AM3PR05MB0935F9F1011E30F11C2A08BDDCF10-LOZWmgKjnYgQouBfZGh8ttqRiQSDpxhJvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2015-04-03 12:43                       ` Dominique Martinet [this message]
2015-04-02 15:15       ` Yann Droneaud
2015-04-02 15:15         ` Yann Droneaud
2015-04-02 16:34         ` Shachar Raindel
2015-04-02 16:34           ` Shachar Raindel
     [not found]           ` <AM2PR05MB0929EDC60BBE5DAAAD4AB1B4DCF20-Wc3DjHnhGicijy4iGQu0rtqRiQSDpxhJvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2015-04-08 12:19             ` Yann Droneaud
2015-04-08 12:19               ` Yann Droneaud
2015-04-08 12:44               ` Yann Droneaud

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=20150403124356.GA3141@u-blusson \
    --to=dominique.martinet-kce40yydgki@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.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.