Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp2031656imn; Mon, 1 Aug 2022 08:44:35 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vh53th3NY+G+v/WqfRirEuMmeG1zMlq7O2Njjyg/rJZLECwqGS/EP+gUormS2th4wIiUlW X-Received: by 2002:a17:907:971a:b0:72b:6bab:abc2 with SMTP id jg26-20020a170907971a00b0072b6bababc2mr13009940ejc.551.1659368675510; Mon, 01 Aug 2022 08:44:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659368675; cv=none; d=google.com; s=arc-20160816; b=Lu0kQNPbRSGfeB8s0gdQdbqQBdkNut9SxGdEVbxlIX5PVJnNeY1h6JQfRsjGP8f9h4 0GTRBzN8RcxzbKikJ3SO+PgdRJAfBqM3z3xWVmvudnfMFYrFMMiS5HCBeTjE71cLOBv2 fb3qo0rMz7DGOHBwt9poQ7yY41Lfi/vQFl/s2ryU0W5Jf3EjybDXV4yCgeDtIj1T+905 zOqufHftzgaD63Os1pA4o8Y6eRpUecRgzvAaUwhDxg5xHOVDCx1gTKpLmw8yUDRRFS+3 QIZi0DRMnW5oFjuMFjGtETs0hbiesN4Tph5xYC5UbmSJoZ7Qu2SKR31U760y+NJ4UDcj PCfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:dkim-signature:dkim-filter; bh=Omq/uk2xaYsFc2SnbTFQ8Np0ewayqBDo2ZaBgjfBp6A=; b=c6w6Yhhr7sCFFhcI+PGGWGU9Cvo2wq+HQvATSD02RtFpdy8mg/6Hkm6CxnLaz8QAAh AXvlV8shFobhwyCULHN5weXMw8nvv+vsqkaF6HYCOa2EZvk4R5Xi/vtVYeAj512Pl+6G yWMWYJsLp7xqIp6JMC9N6q3Ky12FKWAxHRtKdMHS3QWjpJiHuo8mGpGUUfobpYrFqswh jwH31qFMVf2l9dX995GNm+Qkq+fVHUkusgoXnT7zo5RcYGZL1aZhtCVxK1yEXocY4LYs c0ULwvb1s/9XkvESQhIAxc8qu7GtAZ38YXh0IF5BX94bp7ftlOw9nkq4ybi4MWeJ8Zyu ENaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=hQsyBsFh; 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=NONE sp=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id di17-20020a170906731100b0072a6e7a054dsi1173750ejc.975.2022.08.01.08.44.10; Mon, 01 Aug 2022 08:44:35 -0700 (PDT) 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=@efficios.com header.s=default header.b=hQsyBsFh; 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=NONE sp=NONE dis=NONE) header.from=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233319AbiHAOnt (ORCPT + 99 others); Mon, 1 Aug 2022 10:43:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54512 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232759AbiHAOn0 (ORCPT ); Mon, 1 Aug 2022 10:43:26 -0400 Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC03F3E741; Mon, 1 Aug 2022 07:42:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 9B6D6354FD0; Mon, 1 Aug 2022 10:42:46 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QMZj_jTw1QdE; Mon, 1 Aug 2022 10:42:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 101353550BA; Mon, 1 Aug 2022 10:42:46 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 101353550BA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1659364966; bh=Omq/uk2xaYsFc2SnbTFQ8Np0ewayqBDo2ZaBgjfBp6A=; h=Date:From:To:Message-ID:MIME-Version; b=hQsyBsFhZGR2HBjKVRTylO783wrqVCDAV9vJ7Mo1m/pJGhG8Do1JuWZ3TqmY/e0i+ l6eNir06gZ/PR5Yj5urlm0h3MINBQvx6Zn7ooholxF+uHk8SHheWKiludVlnigHVPq wm9UI2I1iV/mXReFV6tXJTebRtB/Mhsojtj16kXp0nyD0hN8Js2ejNskhWBmkfqcA3 MfPEWI+73BXqrFMbeKLiKfakkss6oQt3Vw3ZF+sxeQSvbbvMUoLymKxcWIz9ai+hJN nX8B0C8zF0PbLMGjiPzddkI/B0sgWtiRcksAm3NLgChoPPc7hcoPpdOssC8+vdUWsO 0Cz+KHrh2MpOQ== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qVFcZWVe3CeT; Mon, 1 Aug 2022 10:42:46 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id EC0AC354F2C; Mon, 1 Aug 2022 10:42:45 -0400 (EDT) Date: Mon, 1 Aug 2022 10:42:45 -0400 (EDT) From: Mathieu Desnoyers To: Florian Weimer Cc: Ingo Molnar , Peter Zijlstra , linux-kernel , Thomas Gleixner , "Paul E . McKenney" , Boqun Feng , "H. Peter Anvin" , Paul Turner , linux-api , Peter Oskolkov Message-ID: <1656318880.93523.1659364965914.JavaMail.zimbra@efficios.com> In-Reply-To: <87tu6wm46t.fsf@oldenburg.str.redhat.com> References: <20220622194617.1155957-1-mathieu.desnoyers@efficios.com> <20220622194617.1155957-2-mathieu.desnoyers@efficios.com> <87tu6wm46t.fsf@oldenburg.str.redhat.com> Subject: Re: [PATCH 2/2] rseq: Kill process when unknown flags are encountered in ABI structures MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_4304 (ZimbraWebClient - FF100 (Linux)/8.8.15_GA_4304) Thread-Topic: rseq: Kill process when unknown flags are encountered in ABI structures Thread-Index: pv0m3/O0YjWhUVPgCMLJGmsVZ4uj9w== X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS 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: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Aug 1, 2022, at 10:25 AM, Florian Weimer fweimer@redhat.com wrote: > * Ingo Molnar: > >> * Mathieu Desnoyers wrote: >> >>> rseq_abi()->flags and rseq_abi()->rseq_cs->flags 29 upper bits are >>> currently unused. >>> >>> The current behavior when those bits are set is to ignore them. This is >>> not an ideal behavior, because when future features will start using >>> those flags, if user-space fails to correctly validate that the kernel >>> indeed supports those flags (e.g. with a new sys_rseq flags bit) before >>> using them, it may incorrectly assume that the kernel will handle those >>> flags way when in fact those will be silently ignored on older kernels. >>> >>> Validating that unused flags bits are cleared will allow a smoother >>> transition when those flags will start to be used by allowing >>> applications to fail early, and obviously, when they attempt to use the >>> new flags on an older kernel that does not support them. >>> >>> Signed-off-by: Mathieu Desnoyers >>> --- >>> kernel/rseq.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/kernel/rseq.c b/kernel/rseq.c >>> index 81d7dc80787b..bda8175f8f99 100644 >>> --- a/kernel/rseq.c >>> +++ b/kernel/rseq.c >>> @@ -176,7 +176,7 @@ static int rseq_need_restart(struct task_struct *t, u32 >>> cs_flags) >>> u32 flags, event_mask; >>> int ret; >>> >>> - if (WARN_ON_ONCE(cs_flags & RSEQ_CS_NO_RESTART_FLAGS)) >>> + if (WARN_ON_ONCE(cs_flags & RSEQ_CS_NO_RESTART_FLAGS) || cs_flags) >>> return -EINVAL; >>> >>> /* Get thread flags. */ >>> @@ -184,7 +184,7 @@ static int rseq_need_restart(struct task_struct *t, u32 >>> cs_flags) >>> if (ret) >>> return ret; >>> >>> - if (WARN_ON_ONCE(flags & RSEQ_CS_NO_RESTART_FLAGS)) >>> + if (WARN_ON_ONCE(flags & RSEQ_CS_NO_RESTART_FLAGS) || flags) >>> return -EINVAL; >> >> Just to make it clear: no existing libraries/tooling out there have learned >> to rely on the old ABI that ignored unset flags, right? Only then is this >> patch ABI-safe. > > I believe glibc initializes the flag fields to zero before calling the > rseq system call. (I don't know if the rseq system call does its own > initialization; maybe it should if it doesn't do so already.) Initialization and following updates of rseq_abi()->flags and rseq_abi()->rseq_cs->flags is done by user-space, so the rseq system call does not initialize any of those fields. Indeed glibc initialize the rseq_abi()->flags to 0, and does not use rseq_abi()->rseq_cs->flags as of now. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com