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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 06FDAEB64D8 for ; Thu, 22 Jun 2023 11:58:06 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256 header.s=casper.20170209 header.b=pSWWLPWk; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4QmzQh3lz0z30XT for ; Thu, 22 Jun 2023 21:58:04 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256 header.s=casper.20170209 header.b=pSWWLPWk; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=infradead.org (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org; envelope-from=peterz@infradead.org; receiver=lists.ozlabs.org) Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4QmzPd60B9z2xrD for ; Thu, 22 Jun 2023 21:57:09 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=dnuSRjit9BClyf8ssWCLDDODxXJZmhDnJ4paeO5Nhx4=; b=pSWWLPWkaaoJwHc5BYho2poyPl eIWhn/5lqy2SEgEoeR3nAv0aJ8EHJmEWIJd1pNAfu6XYd3iA1O0K29sU64D64FD89ly99k0csSzr6 /Yf44ZWG5r1/r112unkcSNqmOEFsnJ0IvnVjdtAkNmAO9AQWc1o4P0yHC+mBLwUSiUQ7FE0bdA9lh v6HwdXpSBBNckOoEpyjh5Vl/7X7BxoC8B860EG/qV4xYN9NQxldNh1LTQhU35lNy0OPwpkt+6q1EM TEp5tJ83ZWBXcldmwOlDKqgo28P7Gral3S6BrII6lffytuKus/FlQUaypbE+qdNfn7/7v3vGBBB92 oDeVJM5Q==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1qCIvr-00FZUB-Ln; Thu, 22 Jun 2023 11:56:59 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 4B83F300338; Thu, 22 Jun 2023 13:56:59 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 1FD74241BF9B6; Thu, 22 Jun 2023 13:56:59 +0200 (CEST) Date: Thu, 22 Jun 2023 13:56:59 +0200 From: Peter Zijlstra To: Christophe Leroy Subject: Re: [PATCH v2 14/14] powerpc: Implement UACCESS validation on PPC32 Message-ID: <20230622115659.GO4253@hirez.programming.kicks-ass.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-kernel@vger.kernel.org, Nicholas Piggin , Naveen N Rao , Sathvika Vasireddy , linuxppc-dev@lists.ozlabs.org, Josh Poimboeuf Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Jun 22, 2023 at 12:54:36PM +0200, Christophe Leroy wrote: > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > index f850ab892ad5..8ac5711a055f 100644 > --- a/tools/objtool/check.c > +++ b/tools/objtool/check.c > @@ -218,6 +218,7 @@ static bool __dead_end_function(struct objtool_file *file, struct symbol *func, > "kthread_exit", > "kunit_try_catch_throw", > "lbug_with_loc", > + "longjmp", > "machine_real_restart", > "make_task_dead", > "mpt_halt_firmware", > @@ -230,7 +231,9 @@ static bool __dead_end_function(struct objtool_file *file, struct symbol *func, > "sev_es_terminate", > "snp_abort", > "start_kernel", > + "start_secondary_resume", > "stop_this_cpu", > + "unrecoverable_exception", > "usercopy_abort", > "x86_64_start_kernel", > "x86_64_start_reservations", Someone went and changed all that in tip/objtool/core :-) But perhaps, like the uaccess_safe_builtins[] array below, should we start marking sections so we can remember where stuff comes from later? > @@ -1335,6 +1338,8 @@ static const char *uaccess_safe_builtin[] = { > "rep_stos_alternative", > "rep_movs_alternative", > "__copy_user_nocache", > + "__copy_tofrom_user", > + "__arch_clear_user", > NULL > }; Do we want to rename the 'misc' sectino to 'x86' and start a 'ppc32' section there?