LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Haggai Eran <haggaie@mellanox.com>
To: Yann Droneaud <ydroneaud@opteya.com>,
	Shachar Raindel <raindel@mellanox.com>,
	Sagi Grimberg <sagig@mellanox.com>
Cc: "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, 2 Apr 2015 18:18:32 +0300	[thread overview]
Message-ID: <551D5DC8.6070909@mellanox.com> (raw)
In-Reply-To: <1427981431.22575.21.camel@opteya.com>

On 02/04/2015 16:30, Yann Droneaud wrote:
> Hi,
> 
> Le jeudi 02 avril 2015 à 10:52 +0000, Shachar Raindel a écrit :
>>> -----Original Message-----
>>> From: Yann Droneaud [mailto:ydroneaud@opteya.com]
>>> Sent: Thursday, April 02, 2015 1:05 PM
>>> Le mercredi 18 mars 2015 à 17:39 +0000, Shachar Raindel a écrit :
> 
>>>> +	/*
>>>> +	 * If the combination of the addr and size requested for this
>>> memory
>>>> +	 * region causes an integer overflow, return error.
>>>> +	 */
>>>> +	if ((PAGE_ALIGN(addr + size) <= size) ||
>>>> +	    (PAGE_ALIGN(addr + size) <= addr))
>>>> +		return ERR_PTR(-EINVAL);
>>>> +
>>>
>>> Can access_ok() be used here ?
>>>
>>>          if (!access_ok(writable ? VERIFY_WRITE : VERIFY_READ,
>>>                         addr, size))
>>>                   return ERR_PTR(-EINVAL);
>>>
>>
>> No, this will break the current ODP semantics.
>>
>> ODP allows the user to register memory that is not accessible yet.
>> This is a critical design feature, as it allows avoiding holding
>> a registration cache. Adding this check will break the behavior,
>> forcing memory to be all accessible when registering an ODP MR.
>>
> 
> Where's the check for the range being in userspace memory space,
> especially for the ODP case ?
> 
> For non ODP case (eg. plain old behavior), does get_user_pages()
> ensure the requested pages fit in userspace region on all 
> architectures ? I think so.

Yes, get_user_pages will return a smaller amount of pages than requested
if it encounters an unmapped region (or a region without write
permissions for write requests). If this happens, the loop in
ib_umem_get calls get_user_pages again with the next set of pages, and
this time if it the first page still cannot be mapped an error is returned.

> 
> In ODP case, I'm not sure such check is ever done ?

In ODP, we also call get_user_pages, but only when a page fault occurs
(see ib_umem_odp_map_dma_pages()). This allows the user to pre-register
a memory region that contains unmapped virtual space, and then mmap
different files into that area without needing to re-register.

> (Aside, does it take special mesure to protect shared mapping from
> being read and/or *written* ?)

I'm not sure I understand the question. Shared mappings that the process
is allowed to read or write are also allowed for the HCA (specifically,
to local and remote operations the same process performs using the HCA),
provided the application has registered their virtual address space as a
memory region.

Regards,
Haggai

  reply	other threads:[~2015-04-02 15:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AM3PR05MB0935AABF569F15EA846B8E72DC000@AM3PR05MB0935.eurprd05.prod.outlook.com>
2015-04-02 10:04 ` Yann Droneaud
2015-04-02 10:52   ` Shachar Raindel
2015-04-02 13:30     ` Yann Droneaud
2015-04-02 15:18       ` Haggai Eran [this message]
2015-04-02 16:35         ` Yann Droneaud
2015-04-02 16:44           ` Shachar Raindel
2015-04-02 18:12             ` Haggai Eran
2015-04-13 13:29               ` Yann Droneaud
2015-04-14  8:11                 ` Haggai Eran
2015-04-02 20:40             ` Yann Droneaud
2015-04-03  8:39               ` Haggai Eran
2015-04-03 11:49                 ` Yann Droneaud
2015-04-02 15:15     ` Yann Droneaud
2015-04-02 16:34       ` Shachar Raindel
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=551D5DC8.6070909@mellanox.com \
    --to=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 \
    --cc=ydroneaud@opteya.com \
    --subject='Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).