Message ID | 20221110203504.1985010-3-seanjc@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp365216wru; Thu, 10 Nov 2022 12:40:50 -0800 (PST) X-Google-Smtp-Source: AMsMyM5pD9du6VkyjyHON5RDplYLbusy0CbeIrAMXCbJ62+FOPnClCM1/voKX2qCLh07zhkrNu8o X-Received: by 2002:a17:906:341b:b0:79e:9d9b:d41f with SMTP id c27-20020a170906341b00b0079e9d9bd41fmr3892344ejb.404.1668112850255; Thu, 10 Nov 2022 12:40:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668112850; cv=none; d=google.com; s=arc-20160816; b=WJDnBo7cJd/ssrvQ1h3tLUVmw9LkNt9QDPg0Z6FiiBdkyr1Vntk+APb3OmdEWe01VE MX5B9WVKOxL8OjYAF/tjAts/oD0XlRTGCkcWH1t4cmvw7Q7pD/z87fHLKjWU25fqJjpJ gVg3hPvEPTrKdMzdPTC0NORlZtG1Z/tMPgiwNEEKMdcXki1u6VUb1+LL/uowWwWPk/Fu QKW7r9HYwsf3uI+QtkSbMPAokRpi0A1dL5LTQZxhr7Lc5Y0/DrZOMZVvo+ZPjjN1m4SB HLQFpvAKmIO+aM6WqdJ54rGeve9GaYinVR+urLJIE9DxOgCNrdP2bEN4lECuP5rrGuUY lJrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:reply-to:dkim-signature; bh=Q9x7ezoTY10MerxwSgds+z/5z/6k15MGNtHnWLn8Ah8=; b=heMdnlG1XbiMBlakBNtnq+5L+O77ztrMbCuJcwnEehxtarE7KdEgc6K0m/TxlpvJ8Z LizfWtlxzxpxHPWbo/LaYVy0WTkvypWUTIJvaQAAVS9zUFguL6Kf+6ebXmXLeXvSJELO PYZZpcMjN6XYUeuEpvsV5leqKlLEV+c219BIx16kaghJ9e4xoc12xnqRbzOO5hqL/8O3 upWT8vvGv0nKeH6UyZjMNSafWlJcWL2AYtWDQ17k8A1GUPunYAYCywyb1XDk16CfJMLz zBICa2hHZG9jSGJL/eaQy+njNlM8Y5HJid7XZFNBla5a1kbz2MUXmcdLHTUschdFZOfI bHAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=pY2zGdbH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t5-20020a05640203c500b00461f2136969si508908edw.242.2022.11.10.12.40.26; Thu, 10 Nov 2022 12:40:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=pY2zGdbH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231955AbiKJUfR (ORCPT <rfc822;winker.wchi@gmail.com> + 99 others); Thu, 10 Nov 2022 15:35:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231686AbiKJUfL (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 10 Nov 2022 15:35:11 -0500 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C38C56397 for <linux-kernel@vger.kernel.org>; Thu, 10 Nov 2022 12:35:10 -0800 (PST) Received: by mail-pl1-x649.google.com with SMTP id t3-20020a170902e84300b00186ab03043dso2075860plg.20 for <linux-kernel@vger.kernel.org>; Thu, 10 Nov 2022 12:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=Q9x7ezoTY10MerxwSgds+z/5z/6k15MGNtHnWLn8Ah8=; b=pY2zGdbHb7cw1f5XJ56nl3aps6H5XcgxKLQV4ftuzo3flY4sAjrnuFMHXN7m7Ce+Zj d/xYoolxvxFqCZx0jgivinhEb8M7BMYJFnrtRdBmlzEhNQmy4pmZEl6disDUenuPmrUL VOr74QV1qC/IfcXQ2jijKjsEGh8XiYgjLYN2Gkjt0J4WTpTd7A2eYjNoXMeR7Lka1cLr 5mW0bp8iysa5R33fjOmvrgWoM9nlAteckOgLOdohHRlscFFaA878N86pmSu10I4YciQ2 ZNk4w14WTzkuUs1T8RnaAwcm5ax48SYxJ4NSgMVFZQp5EmSTYwPHp/BCR9oXl5vWSZpe CnrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Q9x7ezoTY10MerxwSgds+z/5z/6k15MGNtHnWLn8Ah8=; b=4mzCUeU/IopYVKBJ2BJ+ibmJuSZ+rxyO11DC93hXGi7hMybLsEkZ/H7t2dQ5ArLWJ5 uEoUoQsvKR/2fFf0Gr7iQ8OdiBmr00MoOYqBafx9nu1xuqUGy8bPSm+hOfyDGBmBwgeI pRSoRVuo5FLi9NnrC14oi0nkwjDbB+nHsb5DSLjeOhQv/FBFoqdxRJ2bGG0alDyo3MvA qJ/i5vJ3v5+w6TPLFN5NaFUHGxib1jxEPjjkMiycyjPDQFwiYg+dNRSlFjwfgi6k/AZl yaTq3yk+kvDUEZvRuQMPNCO7Krr6f0JqYgX1i89hkVe5Wene/QPX7Db3Cs2vetnoIWNe Exnw== X-Gm-Message-State: ACrzQf0tZShRCut8yCTNmi7vSxNsQ8mXHKfTac7LUyvdcQWaW1EaIIXl iCWdFgVpK2eavF4VAYaAyzup/V8bcyc= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:d510:b0:186:61a7:ae94 with SMTP id b16-20020a170902d51000b0018661a7ae94mr1897055plg.2.1668112510143; Thu, 10 Nov 2022 12:35:10 -0800 (PST) Reply-To: Sean Christopherson <seanjc@google.com> Date: Thu, 10 Nov 2022 20:35:01 +0000 In-Reply-To: <20221110203504.1985010-1-seanjc@google.com> Mime-Version: 1.0 References: <20221110203504.1985010-1-seanjc@google.com> X-Mailer: git-send-email 2.38.1.431.g37b22c650d-goog Message-ID: <20221110203504.1985010-3-seanjc@google.com> Subject: [PATCH v2 2/5] x86/mm: Populate KASAN shadow for entire per-CPU range of CPU entry area From: Sean Christopherson <seanjc@google.com> To: Dave Hansen <dave.hansen@linux.intel.com>, Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, x86@kernel.org, Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: "H. Peter Anvin" <hpa@zytor.com>, Alexander Potapenko <glider@google.com>, Andrey Konovalov <andreyknvl@gmail.com>, Dmitry Vyukov <dvyukov@google.com>, Vincenzo Frascino <vincenzo.frascino@arm.com>, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Sean Christopherson <seanjc@google.com>, syzbot+ffb4f000dc2872c93f62@syzkaller.appspotmail.com, syzbot+8cdd16fd5a6c0565e227@syzkaller.appspotmail.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749143100218294532?= X-GMAIL-MSGID: =?utf-8?q?1749143100218294532?= |
Series |
x86/kasan: Bug fixes for recent CEA changes
|
|
Commit Message
Sean Christopherson
Nov. 10, 2022, 8:35 p.m. UTC
Populate a KASAN shadow for the entire possible per-CPU range of the CPU
entry area instead of requiring that each individual chunk map a shadow.
Mapping shadows individually is error prone, e.g. the per-CPU GDT mapping
was left behind, which can lead to not-present page faults during KASAN
validation if the kernel performs a software lookup into the GDT. The DS
buffer is also likely affected.
The motivation for mapping the per-CPU areas on-demand was to avoid
mapping the entire 512GiB range that's reserved for the CPU entry area,
shaving a few bytes by not creating shadows for potentially unused memory
was not a goal.
The bug is most easily reproduced by doing a sigreturn with a garbage
CS in the sigcontext, e.g.
int main(void)
{
struct sigcontext regs;
syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul);
syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
memset(®s, 0, sizeof(regs));
regs.cs = 0x1d0;
syscall(__NR_rt_sigreturn);
return 0;
}
to coerce the kernel into doing a GDT lookup to compute CS.base when
reading the instruction bytes on the subsequent #GP to determine whether
or not the #GP is something the kernel should handle, e.g. to fixup UMIP
violations or to emulate CLI/STI for IOPL=3 applications.
BUG: unable to handle page fault for address: fffffbc8379ace00
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 16c03a067 P4D 16c03a067 PUD 15b990067 PMD 15b98f067 PTE 0
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 3 PID: 851 Comm: r2 Not tainted 6.1.0-rc3-next-20221103+ #432
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:kasan_check_range+0xdf/0x190
Call Trace:
<TASK>
get_desc+0xb0/0x1d0
insn_get_seg_base+0x104/0x270
insn_fetch_from_user+0x66/0x80
fixup_umip_exception+0xb1/0x530
exc_general_protection+0x181/0x210
asm_exc_general_protection+0x22/0x30
RIP: 0003:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
RSP: 0003:0000000000000000 EFLAGS: 00000202
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000000001d0
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
Fixes: 9fd429c28073 ("x86/kasan: Map shadow for percpu pages on demand")
Reported-by: syzbot+ffb4f000dc2872c93f62@syzkaller.appspotmail.com
Suggested-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: kasan-dev@googlegroups.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/mm/cpu_entry_area.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
Comments
On 11/10/22 23:35, Sean Christopherson wrote: > Populate a KASAN shadow for the entire possible per-CPU range of the CPU > entry area instead of requiring that each individual chunk map a shadow. > Mapping shadows individually is error prone, e.g. the per-CPU GDT mapping > was left behind, which can lead to not-present page faults during KASAN > validation if the kernel performs a software lookup into the GDT. The DS > buffer is also likely affected. > > The motivation for mapping the per-CPU areas on-demand was to avoid > mapping the entire 512GiB range that's reserved for the CPU entry area, > shaving a few bytes by not creating shadows for potentially unused memory > was not a goal. > > The bug is most easily reproduced by doing a sigreturn with a garbage > CS in the sigcontext, e.g. > > int main(void) > { > struct sigcontext regs; > > syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul); > syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul); > syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul); > > memset(®s, 0, sizeof(regs)); > regs.cs = 0x1d0; > syscall(__NR_rt_sigreturn); > return 0; > } > > to coerce the kernel into doing a GDT lookup to compute CS.base when > reading the instruction bytes on the subsequent #GP to determine whether > or not the #GP is something the kernel should handle, e.g. to fixup UMIP > violations or to emulate CLI/STI for IOPL=3 applications. > > BUG: unable to handle page fault for address: fffffbc8379ace00 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 16c03a067 P4D 16c03a067 PUD 15b990067 PMD 15b98f067 PTE 0 > Oops: 0000 [#1] PREEMPT SMP KASAN > CPU: 3 PID: 851 Comm: r2 Not tainted 6.1.0-rc3-next-20221103+ #432 > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 > RIP: 0010:kasan_check_range+0xdf/0x190 > Call Trace: > <TASK> > get_desc+0xb0/0x1d0 > insn_get_seg_base+0x104/0x270 > insn_fetch_from_user+0x66/0x80 > fixup_umip_exception+0xb1/0x530 > exc_general_protection+0x181/0x210 > asm_exc_general_protection+0x22/0x30 > RIP: 0003:0x0 > Code: Unable to access opcode bytes at 0xffffffffffffffd6. > RSP: 0003:0000000000000000 EFLAGS: 00000202 > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000000001d0 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > </TASK> > > Fixes: 9fd429c28073 ("x86/kasan: Map shadow for percpu pages on demand") > Reported-by: syzbot+ffb4f000dc2872c93f62@syzkaller.appspotmail.com > Suggested-by: Andrey Ryabinin <ryabinin.a.a@gmail.com> > Cc: Alexander Potapenko <glider@google.com> > Cc: Andrey Konovalov <andreyknvl@gmail.com> > Cc: Dmitry Vyukov <dvyukov@google.com> > Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> > Cc: kasan-dev@googlegroups.com > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > arch/x86/mm/cpu_entry_area.c | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) > Reviewed-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
diff --git a/arch/x86/mm/cpu_entry_area.c b/arch/x86/mm/cpu_entry_area.c index d831aae94b41..7c855dffcdc2 100644 --- a/arch/x86/mm/cpu_entry_area.c +++ b/arch/x86/mm/cpu_entry_area.c @@ -91,11 +91,6 @@ void cea_set_pte(void *cea_vaddr, phys_addr_t pa, pgprot_t flags) static void __init cea_map_percpu_pages(void *cea_vaddr, void *ptr, int pages, pgprot_t prot) { - phys_addr_t pa = per_cpu_ptr_to_phys(ptr); - - kasan_populate_shadow_for_vaddr(cea_vaddr, pages * PAGE_SIZE, - early_pfn_to_nid(PFN_DOWN(pa))); - for ( ; pages; pages--, cea_vaddr+= PAGE_SIZE, ptr += PAGE_SIZE) cea_set_pte(cea_vaddr, per_cpu_ptr_to_phys(ptr), prot); } @@ -195,6 +190,9 @@ static void __init setup_cpu_entry_area(unsigned int cpu) pgprot_t tss_prot = PAGE_KERNEL; #endif + kasan_populate_shadow_for_vaddr(cea, CPU_ENTRY_AREA_SIZE, + early_cpu_to_node(cpu)); + cea_set_pte(&cea->gdt, get_cpu_gdt_paddr(cpu), gdt_prot); cea_map_percpu_pages(&cea->entry_stack_page,