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 9C770C433EF for ; Tue, 21 Jun 2022 21:19:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355849AbiFUVTW (ORCPT ); Tue, 21 Jun 2022 17:19:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33900 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355816AbiFUVTC (ORCPT ); Tue, 21 Jun 2022 17:19:02 -0400 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 56D7A2F3A9 for ; Tue, 21 Jun 2022 14:04:38 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]:59736) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1o3l2y-008PZ1-37; Tue, 21 Jun 2022 15:04:28 -0600 Received: from ip68-227-174-4.om.om.cox.net ([68.227.174.4]:57252 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1o3l2w-00G9Ba-OZ; Tue, 21 Jun 2022 15:04:27 -0600 From: "Eric W. Biederman" To: Mathieu Desnoyers Cc: Derek Bruening , Kevin Malachowski , Alexander Mikhalitsyn , Florian Weimer , Carlos O'Donell , Paul Turner , Simon Marchi , Peter Oskolkov , Chris Kennelly , Pedro Alves , Bui Quang Minh , linux-kernel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86 , "H. Peter Anvin" , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , "Paul E. McKenney" , Boqun Feng , Kees Cook , "Chang S. Bae" , Brian Gerst , Andrei Vagin , Pavel Tikhomirov References: <20220618182515.95831-1-minhquangbui99@gmail.com> <258546133.12151.1655739550814.JavaMail.zimbra@efficios.com> <648712158.13199.1655748645141.JavaMail.zimbra@efficios.com> <87y1xper17.fsf@email.froward.int.ebiederm.org> <871717002.20576.1655841912053.JavaMail.zimbra@efficios.com> Date: Tue, 21 Jun 2022 16:04:18 -0500 In-Reply-To: <871717002.20576.1655841912053.JavaMail.zimbra@efficios.com> (Mathieu Desnoyers's message of "Tue, 21 Jun 2022 16:05:12 -0400 (EDT)") Message-ID: <87pmj1enjh.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1o3l2w-00G9Ba-OZ;;;mid=<87pmj1enjh.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.174.4;;;frm=ebiederm@xmission.com;;;spf=softfail X-XM-AID: U2FsdGVkX18zc+rDFOEBT4bWBnCryNsw5KoKma6AAho= X-SA-Exim-Connect-IP: 68.227.174.4 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH] rseq: x86: Fix rseq_cs get cleared when returning from signal handler X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mathieu Desnoyers writes: > ----- On Jun 21, 2022, at 3:48 PM, Eric W. Biederman ebiederm@xmission.com wrote: > >> Derek Bruening writes: >> >>> From the viewpoint of dynamic binary translation/instrumentation and >>> memtrace (go/memtrace), removing those RSEQ_CS_FLAG_NO_RESTART_ON_* flags >>> is a good thing as it reduces complexity and makes it easier to handle rseq >>> (which is painful enough to handle already). >> >> It sounds like there is consensus. >> >> Does someone want to code up a simple patch that detects when >> RSEQ_CS_NO_RESTART_ON_SIGNAL and does a WARN_ON_ONCE and fails if >> someone uses so it can be set to Linus in the next merge window. >> >> After no one screams at that patch it should be safe to remove the >> functionality, because you have empirical proof that no one uses >> that functionality. > > Sure, I can whip up something. > > I'll send it to Peter Zijlstra shortly. > > I plan to, as you suggest, WARN_ON_ONCE() when this happens, and return > an error when the rseq flags or rseq_cs flags contain either of the > RSEQ_CS_FLAG_NO_RESTART_ON_* flags. This error is handled by forcing a > killing the process with sigsegv: > > __rseq_handle_notify_resume() > [...] > error: > sig = ksig ? ksig->sig : 0; > force_sigsegv(sig); > > Does it look acceptable ? I think so. force_sigsegv preps things so that when you go into exit_to_user_mode_loop the signal handler kills the process. So assuming that happens after force_sigsegv that looks good. Eric