oss-sec mailing list archives
Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access
From: Yann Droneaud <ydroneaud () opteya com>
Date: Thu, 02 Apr 2015 18:35:06 +0200
Hi Haggai, Le jeudi 02 avril 2015 à 18:18 +0300, Haggai Eran a écrit :
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 thismemory+ * 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.
OK, thanks for the description.
(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.
I was refering to description of get_user_pages(): http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/mm/gup.c?id=v4.0-rc6#n765 * @force: whether to force access even when user mapping is currently * protected (but never forces write access to shared mapping). But since ib_umem_odp_map_dma_pages() use get_user_pages() with force argument set to 0, it's OK. 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 ? Again, thanks for the information I was missing to understand how ODP is checking the memory ranges. Regards. -- Yann Droneaud OPTEYA
Current thread:
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Roland Dreier (Apr 01)
- RE: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Shachar Raindel (Apr 02)
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Roland Dreier (Apr 02)
- RE: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Shachar Raindel (Apr 02)
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Roland Dreier (Apr 02)
- <Possible follow-ups>
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Yann Droneaud (Apr 02)
- RE: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Shachar Raindel (Apr 02)
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Yann Droneaud (Apr 02)
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Haggai Eran (Apr 02)
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Yann Droneaud (Apr 02)
- RE: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Shachar Raindel (Apr 02)
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Yann Droneaud (Apr 02)
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Haggai Eran (Apr 02)
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Solar Designer (Apr 02)
- RE: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Shachar Raindel (Apr 02)
- RE: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Shachar Raindel (Apr 02)
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Yann Droneaud (Apr 02)
- RE: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Shachar Raindel (Apr 02)
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Yann Droneaud (Apr 08)
- Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access Yann Droneaud (Apr 08)