From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91647C4741F for ; Fri, 30 Oct 2020 02:49:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0D28620BED for ; Fri, 30 Oct 2020 02:49:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="SUW+4c/G" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D28620BED Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 90A006B0073; Thu, 29 Oct 2020 22:49:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 891EC6B0074; Thu, 29 Oct 2020 22:49:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 759DE6B0075; Thu, 29 Oct 2020 22:49:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id 411396B0073 for ; Thu, 29 Oct 2020 22:49:49 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E5C8C8249980 for ; Fri, 30 Oct 2020 02:49:48 +0000 (UTC) X-FDA: 77427061656.20.vein05_27028ed27292 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id CB7D3180C07A3 for ; Fri, 30 Oct 2020 02:49:48 +0000 (UTC) X-HE-Tag: vein05_27028ed27292 X-Filterd-Recvd-Size: 6585 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Fri, 30 Oct 2020 02:49:48 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id i6so6004677lfd.1 for ; Thu, 29 Oct 2020 19:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iyTdtZ1FYlfsFiUutt0GVS7r1yGxXmwfsMwCFfiA6Mo=; b=SUW+4c/GNE2jYgqJQV5kCIdiJARuhagFhX6ggUAoYxWGbqSqx02k4o9Tbnm3CNpKFs FF3l0+3VB4TT6FMDYhi8KoTZnmVhyAbOsiYPc2Bzhqu3IkAa+nt2nmOuGJNcaOoeFFmH eImGHLnDZLkLEAwPK9vvuFXDgePNGK/8A91nKOP3jpox4HFLofcCdk+6+QhiVVmuN0nV MZ6YymaPmdL9ktRdNMeFZfQ9UpwoeXvweWZv24EzEw5oxsjbIJrrzW8NPseQLz2KIB0S kvTPc+Ur9VsGUKlMApEFPWvIkmBYzIGWhA62E8vNbVv/qjnouitKYK9OQtDpL3SCfgQc wFMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iyTdtZ1FYlfsFiUutt0GVS7r1yGxXmwfsMwCFfiA6Mo=; b=avbUNF75aIyXC4wAMs39CmerX3XB66qnh7CVfnxji0aI4iMp9qQOD3K3As6MfFoi2v gjLpWrGmPYpRHMqzX4yvMpHEqbzEwSH4E52pbpbeAKBHtxfs+dkzkCYY9RXcuQiKMH12 CfdYsmMnuERRRMUce/ITujFS/rcX4OsOSKCz4C9Cu8zvov3+xMZgL61qidnukO7I/+Ws NGkdpKnXu0tlWDlvXoZ0VULomfFWYKqnGTMsy5jYMJEJ7H6nmBoI3rIcuIlGZr6JczOS oLo74QWF0zj6wpNsYj86KnW5AoeFeTxicAADmsgY7oNSMl3uNk0t2ZnMIZ6WMY1oqcnz EtCg== X-Gm-Message-State: AOAM531f1LmSqkvTeJRfeQkrbpbzbjs7hWpc5QP5YY5IYsKWbCR8uK2m 0dkU5UN31BndRmMZWGLOJfCwngQu5WEn59OVUYwSog== X-Google-Smtp-Source: ABdhPJz0jmO93efSvKGBuuwFlhC4NS3zSciN4aPqYzgeBthjdtsZqkNkjTWffgFn28Gq3ZSltgk0QyJUydfGIqk06xw= X-Received: by 2002:a19:ef07:: with SMTP id n7mr22380lfh.482.1604026186911; Thu, 29 Oct 2020 19:49:46 -0700 (PDT) MIME-Version: 1.0 References: <20201029131649.182037-1-elver@google.com> <20201029131649.182037-3-elver@google.com> In-Reply-To: <20201029131649.182037-3-elver@google.com> From: Jann Horn Date: Fri, 30 Oct 2020 03:49:19 +0100 Message-ID: Subject: Re: [PATCH v6 2/9] x86, kfence: enable KFENCE for x86 To: Marco Elver Cc: Andrew Morton , Alexander Potapenko , "H . Peter Anvin" , "Paul E . McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christoph Lameter , Dave Hansen , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jonathan Cameron , Jonathan Corbet , Joonsoo Kim , joern@purestorage.com, Kees Cook , Mark Rutland , Pekka Enberg , Peter Zijlstra , SeongJae Park , Thomas Gleixner , Vlastimil Babka , Will Deacon , "the arch/x86 maintainers" , "open list:DOCUMENTATION" , kernel list , kasan-dev , Linux ARM , Linux-MM Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Oct 29, 2020 at 2:17 PM Marco Elver wrote: > Add architecture specific implementation details for KFENCE and enable > KFENCE for the x86 architecture. In particular, this implements the > required interface in for setting up the pool and > providing helper functions for protecting and unprotecting pages. > > For x86, we need to ensure that the pool uses 4K pages, which is done > using the set_memory_4k() helper function. > > Reviewed-by: Dmitry Vyukov > Co-developed-by: Marco Elver > Signed-off-by: Marco Elver > Signed-off-by: Alexander Potapenko [...] > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c [...] > @@ -725,6 +726,9 @@ no_context(struct pt_regs *regs, unsigned long error_code, > if (IS_ENABLED(CONFIG_EFI)) > efi_recover_from_page_fault(address); > > + if (kfence_handle_page_fault(address)) > + return; We can also get to this point due to an attempt to execute a data page. That's very unlikely (given that the same thing would also crash if you tried to do it with normal heap memory, and KFENCE allocations are extremely rare); but we might want to try to avoid handling such faults as KFENCE faults, since KFENCE will assume that it has resolved the fault and retry execution of the faulting instruction. Once kernel protection keys are introduced, those might cause the same kind of trouble. So we might want to gate this on a check like "if ((error_code & X86_PF_PROT) == 0)" (meaning "only handle the fault if the fault was caused by no page being present", see enum x86_pf_error_code). Unrelated sidenote: Since we're hooking after exception fixup handling, the debug-only KFENCE_STRESS_TEST_FAULTS can probably still cause some behavioral differences through spurious faults in places like copy_user_enhanced_fast_string (where the exception table entries are used even if the *kernel* pointer, not the user pointer, causes a fault). But since KFENCE_STRESS_TEST_FAULTS is exclusively for KFENCE development, the difference might not matter. And ordering them the other way around definitely isn't possible, because the kernel relies on being able to fixup OOB reads. So there probably isn't really anything we can do better here; it's just something to keep in mind. Maybe you can add a little warning to the help text for that Kconfig entry that warns people about this? > + > oops: > /* > * Oops. The kernel tried to access some bad page. We'll have to > -- > 2.29.1.341.ge80a0c044ae-goog >