From patchwork Tue Nov 17 23:54:47 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Collingbourne X-Patchwork-Id: 11913703 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=-16.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable 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 63A37C2D0E4 for ; Tue, 17 Nov 2020 23:56:11 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D97EC2072C for ; Tue, 17 Nov 2020 23:56:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="vTvnzxlk"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="Md/nmo4u" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D97EC2072C Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:From:Subject:Mime-Version:Message-Id:Date: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=hTraJ0G5ol0BGCWbtfqzaj1zQJWGpHeDv4rYSXYbG/I=; b=vTvnzxlkJ/WjOwneZrMAQbpNht BumoFVU6hEhVdMH7IA5nlFTngYaRhcID3N2sSUEs6uZCPzeOXfG/rPbjvlpGd2RxQUKzgDbhgrgqt 7nQVaM/pMtqLNMfXZLGin67Go6l83W74hS2EqHDZewCBQYLTiL4dCUdhnbvPhbr9iwJnVvzilMDSB w/uyW1G6qAA1rrmHdQSybPIs24ZaQfLHC0TalpzKi9Sv0xU3p05fLt93+BPReeaJ5jaD5NPL0+cGG 0TcFIjmsJTouoFEyLsuck4KhXUf6uWYfZLlEw9eyANbjRF+kb/5Y8esmpDxvlxRJDh4QHcneI2Z18 GzfyvQXg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfAoP-0002aF-A8; Tue, 17 Nov 2020 23:55:01 +0000 Received: from mail-pf1-x44a.google.com ([2607:f8b0:4864:20::44a]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfAoN-0002ZP-01 for linux-arm-kernel@lists.infradead.org; Tue, 17 Nov 2020 23:55:00 +0000 Received: by mail-pf1-x44a.google.com with SMTP id u3so7963pfm.22 for ; Tue, 17 Nov 2020 15:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=sender:date:message-id:mime-version:subject:from:to:cc; bh=F67sbUoPJ71YXDG7sdUK0EmBqROtcgMmtrjF66jycJ4=; b=Md/nmo4uiAVyWtqr7sCUzbTACIHP4eOwwozR73nab59SpdXPs8GapTu+xjzW6JH2aE GhtfmU+lugSfD10mpukhmiFFxA6gkp/sbPB8yqpft1lJ3WHXzK4lqwNG9k10dQv1JEND 31erme1g+RM0BrFqmT+73UMO86i2vdv+rBA5xBkG/V5kagU8zEPZTS9/QaRq162rltRZ LXZunBwniZET8NRFdhhIyl3LQEiF5YI+25bLj61nDddPxmAFCR8drF+PNifaIWTRt9Fx pVuRy67Ap5XQxuZZDpiHe/ggdaMv0sMklDkbZTNnIPBqMY/yW8DwLHCJdrW0XzkvFkDt iLRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:message-id:mime-version:subject:from :to:cc; bh=F67sbUoPJ71YXDG7sdUK0EmBqROtcgMmtrjF66jycJ4=; b=Jq+1U0ORUT4snbLgtkK8HaJV7ebNKXCXDWU/aIgdtIpZs8cxBmT0gNkRBdzt0PGP9b VX/XmwUhMdE10kX4hWIN1UlZcoNMlb5te9XSaftynlh1AAIIn2L0h4dyGGNDWy6M3ndi G0fXRLol9VEWyxCTiXw0w3JISsSFzTqaByXEEJB3PelzUESs3FIX+rihoh3e60JtZAZU SUqhzH5RpoFQHhdi/sMVPLExDUUSD3m5zO9NoWkk46iXRSRH0MEqMENHtzDTTlVManSX A+qosW4peeWOC0P8H0uEO6MKfNLRQFGxGUQEjLUFUgD+SADeKbfVGoNnmzRRFb/p7IcW bqXQ== X-Gm-Message-State: AOAM531sPhFmSf3fXgrhUYVytpCl5ycjiz920/+r20fM7wjR+GW4xxSc he4ck81g3KhTAGQwUPF5BiYO7mI= X-Google-Smtp-Source: ABdhPJwlmN1K/jlt1uoHIVnW31y/VSYJ7CSIVvxjavwBUeC71cH00smjXcq31zUDviTB4xHMlEgLniE= X-Received: from pcc-desktop.svl.corp.google.com ([2620:15c:2ce:0:7220:84ff:fe09:385a]) (user=pcc job=sendgmr) by 2002:a62:17c8:0:b029:18b:5a97:a8d1 with SMTP id 191-20020a6217c80000b029018b5a97a8d1mr1823895pfx.15.1605657295349; Tue, 17 Nov 2020 15:54:55 -0800 (PST) Date: Tue, 17 Nov 2020 15:54:47 -0800 Message-Id: <20201117235447.816252-1-pcc@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.29.2.299.gdc1121823c-goog Subject: [PATCH v2] sigaction.2: Document SA_EXPOSE_TAGBITS and the flag support detection protocol From: Peter Collingbourne To: Catalin Marinas , Evgenii Stepanov , Kostya Serebryany , Vincenzo Frascino , Dave Martin , Will Deacon , Oleg Nesterov , "Eric W. Biederman" , "James E.J. Bottomley" , Michael Kerrisk , Alejandro Colomar X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201117_185459_090418_C55B795F X-CRM114-Status: GOOD ( 19.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-man@vger.kernel.org, Andrey Konovalov , Helge Deller , Kevin Brodsky , linux-api@vger.kernel.org, David Spickett , Peter Collingbourne , Linux ARM Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Signed-off-by: Peter Collingbourne --- These features are implemented in this patch series: https://lore.kernel.org/linux-arm-kernel/cover.1605235762.git.pcc@google.com/ which is still under review, so the patch should not be applied yet. Alejandro, thanks for the review. Since the patch was almost rewritten I didn't base this on your patch, instead I tried to use the correct formatting in this patch. v2: - fix formatting - address feedback from Dave man2/sigaction.2 | 125 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 125 insertions(+) diff --git a/man2/sigaction.2 b/man2/sigaction.2 index 6a8142324..0e4236a43 100644 --- a/man2/sigaction.2 +++ b/man2/sigaction.2 @@ -250,6 +250,44 @@ This flag is meaningful only when establishing a signal handler. .\" .I sa_sigaction .\" field was added in Linux 2.1.86.) .\" +.TP +.BR SA_UNSUPPORTED +Used to dynamically probe for flag bit support. +.IP +If an attempt to register a handler succeeds with this flag set in +.I act->sa_flags +alongside other flags that are potentially unsupported by the kernel, +and an immediately subsequent +.BR sigaction () +call specifying the same signal number n and with non-NULL +.I oldact +yields +.B SA_UNSUPPORTED +.I clear +in +.IR oldact->sa_flags , +then +.IR oldact->sa_flags +may be used as a bitmask +describing which of the potentially unsupported flags are, +in fact, supported. +See the section "Dynamically probing for flag bit support" +below for more details. +.TP +.BR SA_EXPOSE_TAGBITS " (since Linux 5.x)" +Normally, when delivering a signal, +an architecture-specific set of tag bits are cleared from the +.I si_addr +field of +.IR siginfo_t . +If this flag is set, +an architecture-specific subset of the tag bits will be preserved in +.IR si_addr . +.IP +Programs that need to be compatible with Linux versions older than 5.x +must use +.B SA_UNSUPPORTED +to probe for support. .SS The siginfo_t argument to a SA_SIGINFO handler When the .B SA_SIGINFO @@ -833,6 +871,93 @@ Triggered by a .BR seccomp (2) filter rule. .RE +.SS Dynamically probing for flag bit support +The +.BR sigaction () +call on Linux accepts unknown bits set in +.I act->sa_flags +without error. +The behavior of the kernel starting with Linux 5.x is that a second +.BR sigaction () +will clear unknown bits from +.IR oldact->sa_flags . +However, historically, a second +.BR sigaction () +call would typically leave those bits set in +.IR oldact->sa_flags . +.PP +This means that support for new flags cannot be detected +simply by testing for a flag in +.IR sa_flags , +and a program must test that +.B SA_UNSUPPORTED +has been cleared before relying on the contents of +.IR sa_flags . +.PP +Since the behavior of the signal handler cannot be guaranteed +unless the check passes, +it is wise to either block the affected signal +while registering the handler and performing the check in this case, +or where this is not possible, +for example if the signal is synchronous, to issue the second +.BR sigaction () +in the signal handler itself. +.PP +In kernels that do not support a specific flag, +the kernel's behavior is as if the flag was not set, +even if the flag was set in +.IR act->sa_flags . +.PP +The flags +.BR SA_NOCLDSTOP , +.BR SA_NOCLDWAIT , +.BR SA_SIGINFO , +.BR SA_ONSTACK , +.BR SA_RESTART , +.BR SA_NODEFER , +.BR SA_RESETHAND , +and, if defined by the architecture, +.B SA_RESTORER +may not be reliably probed for using this mechanism, +because they were introduced before Linux 5.x. +However, in general, programs may assume that these flags are supported, +since they have all been supported since Linux 2.6, +which was released in the year 2003. +.PP +The following example program exits with status 0 if +.B SA_EXPOSE_TAGBITS +is determined to be supported, and 1 otherwise. +.PP +.EX +#include +#include +#include + +void handler(int signo, siginfo_t *info, void *context) { + struct sigaction oldact; + if (sigaction(SIGSEGV, 0, &oldact) == 0 && + !(oldact.sa_flags & SA_UNSUPPORTED) && + (oldact.sa_flags & SA_EXPOSE_TAGBITS)) { + _exit(0); + } else { + _exit(1); + } +} + +int main(void) { + struct sigaction act = {}; + act.sa_flags = SA_SIGINFO | SA_UNSUPPORTED | SA_EXPOSE_TAGBITS; + act.sa_sigaction = handler; + if (sigaction(SIGSEGV, &act, 0) != 0) { + perror("sigaction"); + return 1; + } + + /* Force a SIGSEGV. */ + *(volatile int *)0 = 0; + return 1; +} +.EE .SH RETURN VALUE .BR sigaction () returns 0 on success; on error, \-1 is returned, and