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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B563AC43219 for ; Mon, 3 Oct 2022 21:15:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229522AbiJCVPK (ORCPT ); Mon, 3 Oct 2022 17:15:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230252AbiJCVNv (ORCPT ); Mon, 3 Oct 2022 17:13:51 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4BCF4543F7 for ; Mon, 3 Oct 2022 14:08:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D0068B81612 for ; Mon, 3 Oct 2022 21:08:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64BF2C433D6; Mon, 3 Oct 2022 21:08:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1664831334; bh=lA6FZNjYQzcUfH5mIyT69Vnb680qRJHE27gil3rfFmk=; h=Date:To:From:Subject:From; b=Evdym0jHzHszWHtkgeyVDn94ikP+wqE+EY3LVWYqNoAz2eMgjvEGEADxWPfObsuvs BWmmajx24cgVY9sJHhTS60fWhlU16XorHWYxmQ427kOCcnX9XkhG4v++aIdSVjcBYk e+tmyHOZr01WwKnvtL0qwjZFa7uA3n1DYb4Mi8yc= Date: Mon, 03 Oct 2022 14:08:53 -0700 To: mm-commits@vger.kernel.org, willy@infradead.org, viro@zeniv.linux.org.uk, vegard.nossum@oracle.com, vbabka@suse.cz, tglx@linutronix.de, sfr@canb.auug.org.au, rostedt@goodmis.org, rientjes@google.com, pmladek@suse.com, peterz@infradead.org, penberg@kernel.org, mst@redhat.com, mingo@redhat.com, mark.rutland@arm.com, luto@kernel.org, keescook@chromium.org, iii@linux.ibm.com, iamjoonsoo.kim@lge.com, herbert@gondor.apana.org.au, hch@lst.de, gregkh@linuxfoundation.org, gor@linux.ibm.com, elver@google.com, edumazet@google.com, ebiggers@kernel.org, ebiggers@google.com, dvyukov@google.com, cl@linux.com, bp@alien8.de, axboe@kernel.dk, ast@kernel.org, arnd@arndb.de, andreyknvl@google.com, andreyknvl@gmail.com, glider@google.com, akpm@linux-foundation.org From: Andrew Morton Subject: [merged mm-stable] objtool-kmsan-list-kmsan-api-functions-as-uaccess-safe.patch removed from -mm tree Message-Id: <20221003210854.64BF2C433D6@smtp.kernel.org> Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org The quilt patch titled Subject: objtool: kmsan: list KMSAN API functions as uaccess-safe has been removed from the -mm tree. Its filename was objtool-kmsan-list-kmsan-api-functions-as-uaccess-safe.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Alexander Potapenko Subject: objtool: kmsan: list KMSAN API functions as uaccess-safe Date: Thu, 15 Sep 2022 17:04:05 +0200 KMSAN inserts API function calls in a lot of places (function entries and exits, local variables, memory accesses), so they may get called from the uaccess regions as well. KMSAN API functions are used to update the metadata (shadow/origin pages) for kernel memory accesses. The metadata pages for kernel pointers are also located in the kernel memory, so touching them is not a problem. For userspace pointers, no metadata is allocated. If an API function is supposed to read or modify the metadata, it does so for kernel pointers and ignores userspace pointers. If an API function is supposed to return a pair of metadata pointers for the instrumentation to use (like all __msan_metadata_ptr_for_TYPE_SIZE() functions do), it returns the allocated metadata for kernel pointers and special dummy buffers residing in the kernel memory for userspace pointers. As a result, none of KMSAN API functions perform userspace accesses, but since they might be called from UACCESS regions they use user_access_save/restore(). Link: https://lkml.kernel.org/r/20220915150417.722975-32-glider@google.com Signed-off-by: Alexander Potapenko Cc: Alexander Viro Cc: Alexei Starovoitov Cc: Andrey Konovalov Cc: Andrey Konovalov Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Christoph Hellwig Cc: Christoph Lameter Cc: David Rientjes Cc: Dmitry Vyukov Cc: Eric Biggers Cc: Eric Biggers Cc: Eric Dumazet Cc: Greg Kroah-Hartman Cc: Herbert Xu Cc: Ilya Leoshkevich Cc: Ingo Molnar Cc: Jens Axboe Cc: Joonsoo Kim Cc: Kees Cook Cc: Marco Elver Cc: Mark Rutland Cc: Matthew Wilcox Cc: Michael S. Tsirkin Cc: Pekka Enberg Cc: Peter Zijlstra Cc: Petr Mladek Cc: Stephen Rothwell Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Vegard Nossum Cc: Vlastimil Babka Signed-off-by: Andrew Morton --- tools/objtool/check.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) --- a/tools/objtool/check.c~objtool-kmsan-list-kmsan-api-functions-as-uaccess-safe +++ a/tools/objtool/check.c @@ -1062,6 +1062,26 @@ static const char *uaccess_safe_builtin[ "__sanitizer_cov_trace_cmp4", "__sanitizer_cov_trace_cmp8", "__sanitizer_cov_trace_switch", + /* KMSAN */ + "kmsan_copy_to_user", + "kmsan_report", + "kmsan_unpoison_entry_regs", + "kmsan_unpoison_memory", + "__msan_chain_origin", + "__msan_get_context_state", + "__msan_instrument_asm_store", + "__msan_metadata_ptr_for_load_1", + "__msan_metadata_ptr_for_load_2", + "__msan_metadata_ptr_for_load_4", + "__msan_metadata_ptr_for_load_8", + "__msan_metadata_ptr_for_load_n", + "__msan_metadata_ptr_for_store_1", + "__msan_metadata_ptr_for_store_2", + "__msan_metadata_ptr_for_store_4", + "__msan_metadata_ptr_for_store_8", + "__msan_metadata_ptr_for_store_n", + "__msan_poison_alloca", + "__msan_warning", /* UBSAN */ "ubsan_type_mismatch_common", "__ubsan_handle_type_mismatch", _ Patches currently in -mm which might be from glider@google.com are