Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3952076imm; Tue, 11 Sep 2018 04:50:09 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdb+y768xxFcNy2taQ30QKOvJHmc9RH6f9qnnMVk5Qpd+9MuvL6dGv3m4ngAEudCBKcxoFj3 X-Received: by 2002:a62:ea05:: with SMTP id t5-v6mr29413870pfh.228.1536666609741; Tue, 11 Sep 2018 04:50:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536666609; cv=none; d=google.com; s=arc-20160816; b=hDtQpPRJzPHUB8QdSvrS2I6QK4i3Icbjon11nGIKoqdwBuclyocFNgH+xo9a5tU7Ld LZ9wJubaD9VeRzqzhUji+voxNv7kc9TN2I734jY7dDlQ+J1gEy55kPPCsgViArcW73qD Otl74vFY1vRQe40egrmGNp9JsL7m5jlms7Zx/HrJ0ytu1RfGvKO7VsLmmxSqfFQF153e k7ZYToDeMw6LsnDgxfdIxb4eOOeVT4wnxFFqeotAJBMdIrJubMlM7wrHV2cvwhLNP/XA dKPUhNpTku9lD3hyNTgEZJnvvLZW6snSB4iF8cLyqc3D1zpaEwzzeZJ7QHcMmZEyZO+n RyUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=BjVlHTj6T8HDrsjjPdrhWdRqCFP8t+u4nyDEitTaapc=; b=srrTrrWaJ2q2iwWKFNcgBh+uBy1rQZCw8nkbwlfKKrE4DtPJtTjDic03/ZqzNR+Gbw IAOoaUZTBnmlz4gKWfr9xwAx0828BpvbNnI0F9Orlq+VkpFKRxy7SwP0ogetl8KQ55m0 lGNZCK1QJcU/rwl1HGhAgNyLxcS/RUKVLbk0qEjrHBJgdrNXe0Gsj59IKU2QvDlL0Tyh vkdUXoE9Zz2EongBXleMc+RsXkUjFBigQlau66rCEf5PMyb36lO4HqEB77ZS815hk7GS O6UHT28+urEq7tjqVPU3VGypBGE/3TwYGrxkpAG4f8BpF1c8DdmtZkdCA9RMPHb/lB2h 9pZQ== 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 u90-v6si20237435pfk.82.2018.09.11.04.49.53; Tue, 11 Sep 2018 04:50:09 -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 S1727010AbeIKQsa (ORCPT + 99 others); Tue, 11 Sep 2018 12:48:30 -0400 Received: from mx2.suse.de ([195.135.220.15]:57126 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726622AbeIKQs3 (ORCPT ); Tue, 11 Sep 2018 12:48:29 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 043BCAD7D; Tue, 11 Sep 2018 11:49:29 +0000 (UTC) Date: Tue, 11 Sep 2018 13:49:27 +0200 From: Joerg Roedel To: Thomas Gleixner Cc: Meelis Roos , Linux Kernel list , linux-mm@kvack.org, Andrea Arcangeli , Linus Torvalds Subject: Re: 32-bit PTI with THP = userspace corruption Message-ID: <20180911114927.gikd3uf3otxn2ekq@suse.de> References: <20180830205527.dmemjwxfbwvkdzk2@suse.de> <20180831070722.wnulbbmillxkw7ke@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, [ Andrea, maybe you can have a quick look here too, please? Maybe I am overlooking a simple way to fix the issue. Problem description is below. ] On Sat, Sep 08, 2018 at 12:24:10PM +0200, Thomas Gleixner wrote: > > I'll try to reproduce and work on a fix. > > Any progress on this? Yes, but slower than I hoped because an infection sent me to bed for a couple of days :/ So I can reproduce the issue, and the core problem is that with 32-bit legacy paging the PGD level is also the huge-page level. This means that we have two huge PTEs for every mapping and also two places where we have to look for A/D bits. The problem now is that the kernel only looks at the huge PTE in the kernel page-table when it evaluates A/D bits. This causes data corruption when it misses an A/D bit. I had a look into the THP and the HugeTLBfs code, and that is not really easy to fix there. As I can see it now, there are a few options to fix that, but most of them are ugly: 1) Use Software A/D bits for 2-level legacy paging (ugly because we need separate PAGE_* macros for that paging mode then) 2) Update all the places in THP and HugeTLBfs code that evaluate A/D bits to take both PTEs into account (ugly too for obvious reasons) 3) Disable THP and HugeTLBfs on 2-level paging kernels when PTI is enabled (ugly because it breaks userspace expectations) 4) Disable PTI support on 2-level paging by making it dependent on CONFIG_X86_PAE. This is, imho, the least ugly option because the machines that do not support PAE are most likely too old to be affected my Meltdown anyway. We might also consider switching i386_defconfig to PAE? I am not a THP or HugeTLBfs expert and maybe I am overlooking a simpler way to fix this issue. But as it stands now I am in favour for option number 4. Any other thoughts? Thanks, Joerg