From owner-svn-src-all@freebsd.org Fri Feb 9 17:46:34 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DCBDF169E1; Fri, 9 Feb 2018 17:46:34 +0000 (UTC) (envelope-from jtl@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED24E6F9D3; Fri, 9 Feb 2018 17:46:33 +0000 (UTC) (envelope-from jtl@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E38FA27FD6; Fri, 9 Feb 2018 17:46:33 +0000 (UTC) (envelope-from jtl@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w19HkX8f078038; Fri, 9 Feb 2018 17:46:33 GMT (envelope-from jtl@FreeBSD.org) Received: (from jtl@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w19HkXAD078037; Fri, 9 Feb 2018 17:46:33 GMT (envelope-from jtl@FreeBSD.org) Message-Id: <201802091746.w19HkXAD078037@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: jtl set sender to jtl@FreeBSD.org using -f From: "Jonathan T. Looney" Date: Fri, 9 Feb 2018 17:46:33 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r329071 - head/sys/amd64/amd64 X-SVN-Group: head X-SVN-Commit-Author: jtl X-SVN-Commit-Paths: head/sys/amd64/amd64 X-SVN-Commit-Revision: 329071 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 17:46:34 -0000 Author: jtl Date: Fri Feb 9 17:46:33 2018 New Revision: 329071 URL: https://svnweb.freebsd.org/changeset/base/329071 Log: On bootup, the amd64 pmap initialization code creates page-table mappings for the pages used for the kernel and some initial allocations used for the page table. It maps the kernel and the blocks used for these initial allocations using 2MB pages. However, if the kernel does not end on a 2MB boundary, it still maps the last portion using a 2MB page, but reports that the unused 4K blocks within this 2MB allocation are free physical blocks. This means that these same physical blocks could also be mapped elsewhere - for example, into a user process. Given the proximity to the kernel text and data area, it seems wise to avoid allowing someone to write data to physical blocks also mapped into these virtual addresses. (Note that this isn't a security vulnerability: the direct map makes most/all memory on the system mapped into kernel space. And, nothing in the kernel should be trying to access these pages, as the virtual addresses are unused. It simply seems wise to avoid reusing these physical blocks while they are mapped to virtual addresses so close to the kernel text and data area.) Consequently, let's reserve the physical blocks covered by the page-table mappings for these initial allocations. Reviewed by: kib, markj MFC after: 2 weeks Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D14268 Modified: head/sys/amd64/amd64/pmap.c Modified: head/sys/amd64/amd64/pmap.c ============================================================================== --- head/sys/amd64/amd64/pmap.c Fri Feb 9 17:25:34 2018 (r329070) +++ head/sys/amd64/amd64/pmap.c Fri Feb 9 17:46:33 2018 (r329071) @@ -957,6 +957,13 @@ create_pagetables(vm_paddr_t *firstaddr) pd_p[i] = (i << PDRSHIFT) | X86_PG_RW | X86_PG_V | PG_PS | pg_g; + /* + * Because we map the physical blocks in 2M pages, adjust firstaddr + * to record the physical blocks we've actually mapped into kernel + * virtual address space. + */ + *firstaddr = round_2mpage(*firstaddr); + /* And connect up the PD to the PDP (leaving room for L4 pages) */ pdp_p = (pdp_entry_t *)(KPDPphys + ptoa(KPML4I - KPML4BASE)); for (i = 0; i < nkpdpe; i++)