Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp769578ybl; Wed, 11 Dec 2019 07:15:30 -0800 (PST) X-Google-Smtp-Source: APXvYqzrqd1zfqaifBnk2QcydBmayHdGXIRErDkyM6XZivPurcxDEwOfY+0JwK5q7uotGKxz0D1J X-Received: by 2002:aca:b986:: with SMTP id j128mr3339194oif.16.1576077329953; Wed, 11 Dec 2019 07:15:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576077329; cv=none; d=google.com; s=arc-20160816; b=pjM6A++t6Q+iuZsKTlf5ufWFS5taps2McwzSsoIKhohIMBg0FQbBUss3bzL7XAw1W4 uMhADD18nSB7H7uqM9zZtD4IpbENvh7h/dg11CNl1VDTItg/q/C+6zREEKDC1iz7E7mu DcR8x07aQA8p22qnM+Qkvx76J7MdfquyUK+pjT5WCbjz1+FkwQZX6S3wKfX63c6WWMF7 7Fei4laOEOEqVGPJk02uS26LKiabezjFSw1ymBwiMkjA9gla9UJH08hBcBpa4D77aCTF kKjdtZgQoFYskcBVqK6uUrNC6a5uiC0Mx4TxCKWXYm8ckLpnICQs0w4X+zpzsOpo6YnK Pa3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=QP1B632zM29AhVqlwxIQsYlWTEDktOi/uEfa2n6TBJ0=; b=k5waMqbiZCdEe1524uFsjBqf6Zf2BR6tGGxfnloC9YuKf15ugI+DN6R7IGa+wBhUYd YowgZnreazhJn4islm911+XcVVbesgThRTAA776TXTuX5uQ3UCsaAqlkBRLOIz0G+IpW LVVDvwqxSwDGZLbYHSHkcMizKxOvwPeUkt+ZHYfWaG0x6uh6yK7yWh2IwDbxs3XV5yva Q3g5vLAsJWJ7E5au7tIEswOJOD6BOZ9AzHJDiTdP2csrQD2NxYkwwIrwmzpTZ2j5FYp9 64dfGdGq/168qNfH5dPflV5S2HnFZWFM3IQwABpTnbXSfcpXums9JPWvwXXXyCQbDTeU PhJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=jyQUmKIE; 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 u186si1318262oig.29.2019.12.11.07.15.17; Wed, 11 Dec 2019 07:15:29 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=default header.b=jyQUmKIE; 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 S1731092AbfLKPO0 (ORCPT + 99 others); Wed, 11 Dec 2019 10:14:26 -0500 Received: from mail.kernel.org ([198.145.29.99]:37488 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730621AbfLKPNj (ORCPT ); Wed, 11 Dec 2019 10:13:39 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CD7F924654; Wed, 11 Dec 2019 15:13:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576077218; bh=cics5kjVSYpYnPvKQuCF/mMDXQpUxK2EhuST2U+tfd8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jyQUmKIEChNWI/nzcaTRaSajjTC6bs99MUxAgH6cWN6XWzY3lriZWmMFnWQrP7bvb RNbrvddKq0dDWo/IJXFtNJZKo6DSTiFcm1mCAzohvbrWHucDtcX7304MB+HS+eUD3l V0k7fZIZwojzWE/Yh5dKJE0tc27t+kXj6gVIsCEQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Borislav Petkov , Joerg Roedel , Andy Lutomirski , Borislav Petkov , Dave Hansen , Joerg Roedel , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , hpa@zytor.com, Ingo Molnar Subject: [PATCH 5.3 062/105] x86/mm/32: Sync only to VMALLOC_END in vmalloc_sync_all() Date: Wed, 11 Dec 2019 16:05:51 +0100 Message-Id: <20191211150246.703073844@linuxfoundation.org> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191211150221.153659747@linuxfoundation.org> References: <20191211150221.153659747@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Joerg Roedel commit 9a62d20027da3164a22244d9f022c0c987261687 upstream. The job of vmalloc_sync_all() is to help the lazy freeing of vmalloc() ranges: before such vmap ranges are reused we make sure that they are unmapped from every task's page tables. This is really easy on pagetable setups where the kernel page tables are shared between all tasks - this is the case on 32-bit kernels with SHARED_KERNEL_PMD = 1. But on !SHARED_KERNEL_PMD 32-bit kernels this involves iterating over the pgd_list and clearing all pmd entries in the pgds that are cleared in the init_mm.pgd, which is the reference pagetable that the vmalloc() code uses. In that context the current practice of vmalloc_sync_all() iterating until FIX_ADDR_TOP is buggy: for (address = VMALLOC_START & PMD_MASK; address >= TASK_SIZE_MAX && address < FIXADDR_TOP; address += PMD_SIZE) { struct page *page; Because iterating up to FIXADDR_TOP will involve a lot of non-vmalloc address ranges: VMALLOC -> PKMAP -> LDT -> CPU_ENTRY_AREA -> FIX_ADDR This is mostly harmless for the FIX_ADDR and CPU_ENTRY_AREA ranges that don't clear their pmds, but it's lethal for the LDT range, which relies on having different mappings in different processes, and 'synchronizing' them in the vmalloc sense corrupts those pagetable entries (clearing them). This got particularly prominent with PTI, which turns SHARED_KERNEL_PMD off and makes this the dominant mapping mode on 32-bit. To make LDT working again vmalloc_sync_all() must only iterate over the volatile parts of the kernel address range that are identical between all processes. So the correct check in vmalloc_sync_all() is "address < VMALLOC_END" to make sure the VMALLOC areas are synchronized and the LDT mapping is not falsely overwritten. The CPU_ENTRY_AREA and the FIXMAP area are no longer synced either, but this is not really a proplem since their PMDs get established during bootup and never change. This change fixes the ldt_gdt selftest in my setup. [ mingo: Fixed up the changelog to explain the logic and modified the copying to only happen up until VMALLOC_END. ] Reported-by: Borislav Petkov Tested-by: Borislav Petkov Signed-off-by: Joerg Roedel Cc: Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Dave Hansen Cc: Joerg Roedel Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: hpa@zytor.com Fixes: 7757d607c6b3: ("x86/pti: Allow CONFIG_PAGE_TABLE_ISOLATION for x86_32") Link: https://lkml.kernel.org/r/20191126111119.GA110513@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/mm/fault.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -197,7 +197,7 @@ void vmalloc_sync_all(void) return; for (address = VMALLOC_START & PMD_MASK; - address >= TASK_SIZE_MAX && address < FIXADDR_TOP; + address >= TASK_SIZE_MAX && address < VMALLOC_END; address += PMD_SIZE) { struct page *page;