Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1301545imm; Wed, 23 May 2018 13:47:29 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoWHK5+GvI1Oz5qhTdOCkOnOINpSduVUfFDybG0iF1iGaDDaih/CON/ScLNYy4yvKBVM8Wo X-Received: by 2002:a17:902:2848:: with SMTP id e66-v6mr4450053plb.319.1527108449222; Wed, 23 May 2018 13:47:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527108449; cv=none; d=google.com; s=arc-20160816; b=woDxHL4grpcg2bsoIl5AmUW6IAYo71DPF0jwxBg5GMGUfa22FQx4cFhK3lhpv9nOXj G83L2+/T6xkwj0wNI8JXlu1cVvd1v9S7iNUY+miezxp8VjyPiPbz23u20hkUXGoGxXzW wwDOhNe4EQjQyN0q9Ki1RoUEiM1lCt02hVhYZl+njSHebTU9sbrEw+mWf20zqNrm13TM Wq1I2byeLcvPvjpxmc6M+GpcklsSejtS32GFx6Pd23CHSDOdfGlbcE5KpoDZCFF88ewq KvH8ihvVpNUU8E36EuDuUxkU+M/mtuHPds8wqyWjzpX2WVVS8TEj7lRXNAqV0/xf6tDK NP6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=Z15sA8als530fidnixY7YH3i9WLGGtnsPPe/Ttv20cE=; b=nVr2hO5PisDGVA78jRGskBXhloRIxxaWZSwdPAExAjmq9r+H62v8eSv/Q1PPniqmbu hawBCTy/N9+6dd3KOtrAgNr9xcPITc7lbp2/dfadjKgcNl9OiRq8uS4CMKmSlirMY2JC uNDHligqD7x5LBQVsrYVqHcDQ9gqWNvMNAWJlVJ+P8nYjWE7unsXU+LWaqZa3zi4+kFc OyTUDae1kcnvZy/Rd3OaEpCVnT68qV+oS4GoUpcwSszhkGn84fPQIsHm4MqUCvlQVimp +XKw0sHmaOsFQXKjssubu4zxMOgOfWl6D++N6EkOPkMTFc6NBgbFfJ/53QlEn81apfRA kXwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=Tfl+rxys; dkim=fail header.i=@chromium.org header.s=google header.b=Rz5c1JxI; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m13-v6si15899153pgt.624.2018.05.23.13.47.13; Wed, 23 May 2018 13:47:29 -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; dkim=fail header.i=@google.com header.s=20161025 header.b=Tfl+rxys; dkim=fail header.i=@chromium.org header.s=google header.b=Rz5c1JxI; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934900AbeEWUrC (ORCPT + 99 others); Wed, 23 May 2018 16:47:02 -0400 Received: from mail-vk0-f66.google.com ([209.85.213.66]:43371 "EHLO mail-vk0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934241AbeEWUrB (ORCPT ); Wed, 23 May 2018 16:47:01 -0400 Received: by mail-vk0-f66.google.com with SMTP id x191-v6so13996214vke.10 for ; Wed, 23 May 2018 13:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Z15sA8als530fidnixY7YH3i9WLGGtnsPPe/Ttv20cE=; b=Tfl+rxysd3FV6HqiY8w4Xe1gnjgJm/8EYwLCNiHj/h8JimVf4q1T0iXgvJJKWcu74/ voSC70UnmePVt7Mb6c2TK34ISNU+n2zP3GdLFwDVS76o5id6MjgewSu2FuAk3eg7wyUC sH9DzTJOuHTtaAngsLOOCLRGUmzLQAtLfFyax9kv2z0oXgz5ClrilVzJMaGBbKb4o+E1 qsOIswKU91s8nr2AFkLGw1MhkiKR+WSgsnX8HoUqIaD50p6SfGEk9PLqn8SCsgsaidfk Uqzy2pcRPOIc5+dW8tLyPx4GIb4z8xovPVcn1f5IbtkgC1gcwN4rJNRpRe6uh+MUwl0D 6Wog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Z15sA8als530fidnixY7YH3i9WLGGtnsPPe/Ttv20cE=; b=Rz5c1JxIbf8kBC5NwKwWwAxwlpYF4lOEmiufEgE9xj+KK8MM2Z4jXn/7JQLwfc0Yj1 g+40vsaGm4PLxyJktiEbXsPgj+iFwkxih8u20G/pjrEt1LK1P7PW0CcDLsZi7w6ARl3w AsT5RzDTfID/Rg2vjmI/Vl7cE7wIjvp0MYjyg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Z15sA8als530fidnixY7YH3i9WLGGtnsPPe/Ttv20cE=; b=IKXJ2r50Y4CiagWbkauCfo6fKNPpTRUVQktuoeYxfcBvf3yj+t8qvNxKNIQiCST0vB ptbZqfdNQoFgDMEaw+v4bMCJK9FHdjbadomb3gFpLTOPUbIc+o2dF1X0PAfFWg6xVYAC wID7tqxSyvQBC7E8YI2zVsLiKGvgoQxtzMgYpdDo4Z7iPWrTH8vE+pMMddLSVTuIlEEN Sx4l9owt845JCJW9ajaRMENPSdVHJFlW2XV1PCQk5QoyFwxD++gAXNxodqjb0lPHGdhp SCbIimdgZ3Y/6GOqkBwPy/sr2w0MbrEyIpMANbRgESFQhzfrZ15LVu2U3QZjFi/hbtNV gbig== X-Gm-Message-State: ALKqPwcVQCoWCNZs1EpmjLsYt6Wq+gnMbhugL31MUJiAtiETrR++hraS eOHitwBVhwzEb9tlbYBIseUDxHa6BUwMBzfNLLMFQA== X-Received: by 2002:a1f:72cf:: with SMTP id n198-v6mr2808752vkc.149.1527108420169; Wed, 23 May 2018 13:47:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1f:bd1:0:0:0:0:0 with HTTP; Wed, 23 May 2018 13:46:59 -0700 (PDT) In-Reply-To: <20180523184346.487-1-labbott@redhat.com> References: <20180523184346.487-1-labbott@redhat.com> From: Kees Cook Date: Wed, 23 May 2018 13:46:59 -0700 X-Google-Sender-Auth: DC7yuzVkvSpheqAyXdmoIX6djJ4 Message-ID: Subject: Re: [PATCHv2] arm64: Make sure permission updates happen for pmd/pud To: Laura Abbott Cc: Catalin Marinas , Will Deacon , Ard Biesheuvel , linux-arm-kernel , LKML , Peter Robinson Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 23, 2018 at 11:43 AM, Laura Abbott wrote: > Commit 15122ee2c515 ("arm64: Enforce BBM for huge IO/VMAP mappings") > disallowed block mappings for ioremap since that code does not honor > break-before-make. The same APIs are also used for permission updating > though and the extra checks prevent the permission updates from happening, > even though this should be permitted. This results in read-only permissions > not being fully applied. Visibly, this can occasionaly be seen as a failure > on the built in rodata test when the test data ends up in a section or > as an odd RW gap on the page table dump. Fix this by using > pgattr_change_is_safe instead of p*d_present for determining if the > change is permitted. > > Reported-by: Peter Robinson > Fixes: 15122ee2c515 ("arm64: Enforce BBM for huge IO/VMAP mappings") > Signed-off-by: Laura Abbott Reviewed-by: Kees Cook Thanks for fixing this! -Kees > --- > v2: Switch to using pgattr_change_is_safe per suggestion of Will > --- > arch/arm64/mm/mmu.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > index 2dbb2c9f1ec1..493ff75670ff 100644 > --- a/arch/arm64/mm/mmu.c > +++ b/arch/arm64/mm/mmu.c > @@ -933,13 +933,15 @@ int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t prot) > { > pgprot_t sect_prot = __pgprot(PUD_TYPE_SECT | > pgprot_val(mk_sect_prot(prot))); > + pud_t new_pud = pfn_pud(__phys_to_pfn(phys), sect_prot); > > - /* ioremap_page_range doesn't honour BBM */ > - if (pud_present(READ_ONCE(*pudp))) > + /* Only allow permission changes for now */ > + if (!pgattr_change_is_safe(READ_ONCE(pud_val(*pudp)), > + pud_val(new_pud))) > return 0; > > BUG_ON(phys & ~PUD_MASK); > - set_pud(pudp, pfn_pud(__phys_to_pfn(phys), sect_prot)); > + set_pud(pudp, new_pud); > return 1; > } > > @@ -947,13 +949,15 @@ int pmd_set_huge(pmd_t *pmdp, phys_addr_t phys, pgprot_t prot) > { > pgprot_t sect_prot = __pgprot(PMD_TYPE_SECT | > pgprot_val(mk_sect_prot(prot))); > + pmd_t new_pmd = pfn_pmd(__phys_to_pfn(phys), sect_prot); > > - /* ioremap_page_range doesn't honour BBM */ > - if (pmd_present(READ_ONCE(*pmdp))) > + /* Only allow permission changes for now */ > + if (!pgattr_change_is_safe(READ_ONCE(pmd_val(*pmdp)), > + pmd_val(new_pmd))) > return 0; > > BUG_ON(phys & ~PMD_MASK); > - set_pmd(pmdp, pfn_pmd(__phys_to_pfn(phys), sect_prot)); > + set_pmd(pmdp, new_pmd); > return 1; > } > > -- > 2.17.0 > -- Kees Cook Pixel Security