Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp1783042img; Sat, 23 Mar 2019 12:05:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqxxQaYlXTTT6czTjEm64VX4Nl+NyiAplcI+jYAlBDEDMxQYyl0baiEGynM20ZupFhXwEF4J X-Received: by 2002:a17:902:3283:: with SMTP id z3mr16300015plb.236.1553367948991; Sat, 23 Mar 2019 12:05:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553367948; cv=none; d=google.com; s=arc-20160816; b=IrV76VdLHiUTohinigAGfLPqdfk5LhQOsrygy2pYZE6cB6NcphgFeW4/heT6S3kKGa QaPqA3Ab4ZEWAAiV4ht2HszcWivQy1toFLHQqdUQLiB50aOCxYbOsr/3/zzkwg9jbeo2 7+pDvnnW29fGoYbpn+qDfIMBJR9oJIxJ3eI7F0Z85LJfcRC3iQ0+jAPMVjHHRN6UQooU MlKNKHjHdxKER5cUW76sEbU4YE49Tni5Z39diCou7u+QSTEvC4F/xHbYWsAJrEPcR+Te lP9aZowBrAv/wNcM6NViAnxsBSqhfZC9/9zUoQZgOKytxtiAAmfvScApP6k4leFc3AXw 1+qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=Wbb1IUHRWloPgfG5amCYei73cyPYndabTrsWTu46Ju0=; b=LP30SeS9YX/akNW85xxHru+Bk1kLF6I6wUoQaszWLEvP4tAIYVZT7HIGIh9dyKEipI wLgvEYhIk1wNA38Hwq3BphNX0WmNa4yV3d1s0qa6jvQHiiy8f40BQoj5o9LmcnDAqD2R kBlEqfceAp7xm83cyx8sWgd0Amn81+2w0qs3HMG/FDM//HkjUyN4X9J8YLAChXkKzpnA Q1Z1msowuTb1UUKEQJOVby/Jlveka26KLMIRaCtxqykiCRjqg7i+95HcwM4ipT0sK2GZ 3F+U/qJ+NqQCb4XCJ8BsBhw6pZgb+/vksjekW3acZUzufSNUZkWlB5o7Mp6Dq8+03zgM EkCg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b4si9812136pfj.16.2019.03.23.12.05.00; Sat, 23 Mar 2019 12:05:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727628AbfCWTCh (ORCPT + 99 others); Sat, 23 Mar 2019 15:02:37 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:42708 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727482AbfCWTCh (ORCPT ); Sat, 23 Mar 2019 15:02:37 -0400 Received: from p5492e2fc.dip0.t-ipconnect.de ([84.146.226.252] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1h7luT-0006MN-2v; Sat, 23 Mar 2019 20:02:25 +0100 Date: Sat, 23 Mar 2019 20:02:24 +0100 (CET) From: Thomas Gleixner To: Ralph Campbell cc: linux-kernel@vger.kernel.org, Craig Bergstrom , Linus Torvalds , Boris Ostrovsky , Fengguang Wu , Greg Kroah-Hartman , Hans Verkuil , Mauro Carvalho Chehab , Peter Zijlstra , Sander Eikelenboom , Sean Young , Ingo Molnar Subject: Re: [PATCH 1/1] x86/mm: Fix limit mmap() of /dev/mem to valid physical addresses In-Reply-To: <20190318224653.26549-2-rcampbell@nvidia.com> Message-ID: References: <20190318224653.26549-1-rcampbell@nvidia.com> <20190318224653.26549-2-rcampbell@nvidia.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ralph, On Mon, 18 Mar 2019, rcampbell@nvidia.com wrote: > From: Ralph Campbell > > If CONFIG_DEBUG_VIRTUAL is enabled, a read or write to /dev/mem can > trigger a VIRTUAL_BUG_ON() depending on the value of high_memory. > For example: > > read_mem() > valid_phys_addr_range(p=401f1550, count=8) > __pa(high_memory) > __phys_addr(x=ffffc88000000000) > // __START_KERNEL_map = ffffffff80000000 > // y = ffffc88000000000 - ffffffff80000000 > VIRTUAL_BUG_ON(phys_addr_valid(400000000000)) > // boot_cpu_data.x86_phys_bits=46 I have no idea why all the irrelevant information in this example would be helpful, but after extracting the meat I think I know what you want to say. > Since by design high_memory is outside the range of valid physical > addresses, use the non-error checking version __pa_nodebug(high_memory). high_memory is not outside the range of valid physical addresses by design. It's only outside when memory is populated right at the end of the physical address space. So what you really want to say in the changelog is: valid_phys_addr_range() is used to sanity check the physical address range of an operation, e.g. access to /dev/mem. It uses __pa(high_memory) internally. If memory is populated at the end of the physical address space, then __pa(high_memory) is outside of the physical address space because: high_memory = (void *)__va(max_pfn * PAGE_SIZE - 1) + 1; For the comparison in valid_phys_addr_range() this is not an issue, but if CONFIG_DEBUG_VIRTUAL is enabled, __pa() maps to __phys_addr(), which verifies that the resulting physical address is within the valid physical address space of the CPU. So in the case that memory is populated at the end of the physical address space, this is not true and triggers a VIRTUAL_BUG_ON(). Use ... instead, because ... > Fixes: be62a32044061cb4a3b70a10598e093f1319102e ("x86/mm: Limit mmap() of Please limit the sha1 to the first 12 characters. > /dev/mem to valid physical addresses") > No newline between Fixes and the rest please. > Signed-off-by: Ralph Campbell > --- a/arch/x86/mm/mmap.c > +++ b/arch/x86/mm/mmap.c > @@ -230,7 +230,7 @@ bool mmap_address_hint_valid(unsigned long addr, unsigned long len) > /* Can we access it for direct reading/writing? Must be RAM: */ > int valid_phys_addr_range(phys_addr_t addr, size_t count) > { > - return addr + count <= __pa(high_memory); > + return addr + count <= __pa_nodebug(high_memory); This lacks a comment. Aside of that I think there is no point in using __pa(high_memory) here. This is all about the physical address range. So this can be simply expressed via: return addr + count <= max_pfn * PAGE_SIZE; which is much more obvious. Thanks, tglx