From: Yann Droneaud <ydroneaud@opteya.com>
To: Shachar Raindel <raindel@mellanox.com>
Cc: Haggai Eran <haggaie@mellanox.com>,
Sagi Grimberg <sagig@mellanox.com>,
"oss-security@lists.openwall.com"
<oss-security@lists.openwall.com>,
"<linux-rdma@vger.kernel.org> (linux-rdma@vger.kernel.org)"
<linux-rdma@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access
Date: Thu, 02 Apr 2015 22:40:08 +0200 [thread overview]
Message-ID: <1428007208.22575.104.camel@opteya.com> (raw)
In-Reply-To: <AM2PR05MB0929FB71C5A4DE92A7709F92DCF20@AM2PR05MB0929.eurprd05.prod.outlook.com>
Hi,
Le jeudi 02 avril 2015 à 16:44 +0000, Shachar Raindel a écrit :
> > -----Original Message-----
> > From: Yann Droneaud [mailto:ydroneaud@opteya.com]
> > Sent: Thursday, April 02, 2015 7:35 PM
> > Another related question: as the large memory range could be registered
> > by user space with ibv_reg_mr(pd, base, size, IB_ACCESS_ON_DEMAND),
> > what's prevent the kernel to map a file as the result of mmap(0, ...)
> > in this region, making it available remotely through IBV_WR_RDMA_READ /
> > IBV_WR_RDMA_WRITE ?
> >
>
> This is not a bug. This is a feature.
>
> Exposing a file through RDMA, using ODP, can be done exactly like this.
> Given that the application explicitly requested this behavior, I don't
> see why it is a problem.
If the application cannot choose what will end up in the region it has
registered, it's an issue !
What might happen if one library in a program call mmap(0, size, ...) to
load a file storing a secret (a private key), and that file ends up
being mapped in an registered but otherwise free region (afaict, the
kernel is allowed to do it) ?
What might happen if one library in a program call call mmap(0,
size, ..., MAP_ANONYMOUS,...) to allocate memory, call mlock(), then
write in this location a secret (a passphrase), and that area ends up
in the memory region registered for on demand paging ?
The application haven't choose to disclose these confidential piece of
information, but they are available for reading/writing by remote
through RDMA given it knows the rkey of the memory region (which is a
32bits value).
I hope I'm missing something, because I'm not feeling confident such
behavor is a feature.
> Actually, some of our tests use such flows.
> The mmu notifiers mechanism allow us to do this safely. When the page is
> written back to disk, it is removed from the ODP mapping. When it is
> accessed by the HCA, it is brought back to RAM.
>
I'm not discussing about the benefit of On Demand Paging and why it's a
very good feature to expose files through RDMA.
I'm trying to understand how the application can choose what is exposed
through RDMA if it registers a very large memory region for later use
(but do not actually explicitly map something there yet): what's the
consequences ?
void *start = sbrk(0);
size_t size = ULONG_MAX - (unsigned long)start;
ibv_reg_mr(pd, start, size, IB_ACCESS_ON_DEMAND)
Regards.
--
Yann Droneaud
OPTEYA
next prev parent reply other threads:[~2015-04-02 20:40 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 [this message]
[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
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=1428007208.22575.104.camel@opteya.com \
--to=ydroneaud@opteya.com \
--cc=haggaie@mellanox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=oss-security@lists.openwall.com \
--cc=raindel@mellanox.com \
--cc=sagig@mellanox.com \
--cc=stable@vger.kernel.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.