Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1018305pxf; Thu, 25 Mar 2021 21:59:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxzTbe5RHPFuwmv16r50QZCbuDnnBodW9sh77UTsQ4e25iIT3vQW3Zoz6YNqNzFPeSmjEE3 X-Received: by 2002:a05:6402:1754:: with SMTP id v20mr12685676edx.191.1616734741364; Thu, 25 Mar 2021 21:59:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616734741; cv=none; d=google.com; s=arc-20160816; b=AECi4O+257tuWPCwKuoPJ2T1ZgEkM58MR6ijrb/EvW56RpqkndHz7ONCSEEwSSPLFs mvU4UrI4jsu3AVWsbabOEtPYmDUW+IToJ7mHyb45UlCtvmz19N4QEu6+owSVd3fCdjyM PIqBKT5Fs35dWEovrXJC3fatS25CvEnD31srcSRzyCBAxfn5o6LuJKjQTzzK34YJlEvz 9ewoX2vt4Mom9o5j4BIPToQK+14fxr4wWsO/p4EUwONeh+ozBFgMWRDeFYJCfqxHGVX0 cM3q7uILmtdQ2EFzqIb3QAqIyQ6FKRQ3ZNnSPTVhK+ENWnWKrnmTpe6FZhJ/musJeIfK KDzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=wYYG3IKddP8LSdwbtP5uHNMJkiuoIy/hGSkeT0QwkCQ=; b=KI0+RCucnQQRJ67UP2itwdPpY9U8zrrI92Vlh31WtP881x70ggrUulrYXdzPL/PoL9 4BgcpA22vd+qVWcpM3pEKpfilXDelt+dTq3osTFHmkNEIWR/7z3h6MK+4DfxXVlnTRiP AlDUO7CMdilCriAY91GYBSw/yo09EcbgKAjdeDgY//wBLRQXQWuYsHhtvXQEfN+QyDuB Pui0pMg34A1ntTpVCyIDIeJav6CK/mYx8tSJvl/Iicj4IEHmBRIBU7G6luHNxpTLNnqR IFgXHzgzSOIbZSzgvvrZtSPQ+8CqhHiVkyCwi8aYeBdyVVVLBNSHuiudno5bnkaxGpIR ODOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DA+GzhnN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u25si5622508edo.148.2021.03.25.21.58.38; Thu, 25 Mar 2021 21:59:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DA+GzhnN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229458AbhCZE5e (ORCPT + 99 others); Fri, 26 Mar 2021 00:57:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:56134 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229486AbhCZE5V (ORCPT ); Fri, 26 Mar 2021 00:57:21 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 627F961A45 for ; Fri, 26 Mar 2021 04:57:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616734637; bh=Jo0P5Muvb8+8gfjPQRi5hsZaxh6GN7AU308texcxIAA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DA+GzhnNXjZ1nnTteLALR+Catssi3ud00zohi3LtxDDuSeJ7bDzDJH4jGbLnuhy2r HtnPCr0263Z1wj08m2IJzhN3ThSUASTu9VQxrLpxCWLr4WARYUJTACwCiliFbf6cVu 2vkD/oCO6FwyQXPMd6h4tXi69t8m9owoEGMQuiWAdBHHNIxuZYMjMgThfVSMbsy7q+ Ut818JRaMB8LFFuHnIE8HEcTXUhsi6eJs1J3+exrbBMTyAxOwcS0V5xnIKZ4COBk0H FO5Ij6lwmtTMu2FgM6GnsfHxGL4QQRlpj5ABDdd4aqTZFPh+GjqPfRfCpNcOYDThwf rUYFoIFJbdJVA== Received: by mail-lj1-f176.google.com with SMTP id 184so5912363ljf.9 for ; Thu, 25 Mar 2021 21:57:17 -0700 (PDT) X-Gm-Message-State: AOAM531e5kzqbeO8udsO+nr/+aKVe7iP55RpVedwQyufbjpov4nDcDkn LdJ147b47y4YnfjTCCrVnT3CqX4n3vWPOnFeM57vMA== X-Received: by 2002:a17:907:2809:: with SMTP id eb9mr12915334ejc.204.1616734624746; Thu, 25 Mar 2021 21:57:04 -0700 (PDT) MIME-Version: 1.0 References: <20210316065215.23768-1-chang.seok.bae@intel.com> <20210316065215.23768-6-chang.seok.bae@intel.com> <20210325185435.GB32296@zn.tnic> In-Reply-To: <20210325185435.GB32296@zn.tnic> From: Andy Lutomirski Date: Thu, 25 Mar 2021 21:56:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 5/6] x86/signal: Detect and prevent an alternate signal stack overflow To: Borislav Petkov Cc: Andy Lutomirski , "Chang S. Bae" , Andrew Cooper , Boris Ostrovsky , Juergen Gross , Stefano Stabellini , Thomas Gleixner , Ingo Molnar , X86 ML , Len Brown , Dave Hansen , "H. J. Lu" , Dave Martin , Jann Horn , Michael Ellerman , "Carlos O'Donell" , Tony Luck , "Ravi V. Shankar" , libc-alpha , linux-arch , Linux API , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 25, 2021 at 11:54 AM Borislav Petkov wrote: > > On Thu, Mar 25, 2021 at 11:13:12AM -0700, Andy Lutomirski wrote: > > diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c > > index ea794a083c44..53781324a2d3 100644 > > --- a/arch/x86/kernel/signal.c > > +++ b/arch/x86/kernel/signal.c > > @@ -237,7 +237,8 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, size_t frame_size, > > unsigned long math_size = 0; > > unsigned long sp = regs->sp; > > unsigned long buf_fx = 0; > > - int onsigstack = on_sig_stack(sp); > > + bool already_onsigstack = on_sig_stack(sp); > > + bool entering_altstack = false; > > int ret; > > > > /* redzone */ > > @@ -246,15 +247,25 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, size_t frame_size, > > > > /* This is the X/Open sanctioned signal stack switching. */ > > if (ka->sa.sa_flags & SA_ONSTACK) { > > - if (sas_ss_flags(sp) == 0) > > + /* > > + * This checks already_onsigstack via sas_ss_flags(). > > + * Sensible programs use SS_AUTODISARM, which disables > > + * that check, and programs that don't use > > + * SS_AUTODISARM get compatible but potentially > > + * bizarre behavior. > > + */ > > + if (sas_ss_flags(sp) == 0) { > > sp = current->sas_ss_sp + current->sas_ss_size; > > + entering_altstack = true; > > + } > > } else if (IS_ENABLED(CONFIG_X86_32) && > > - !onsigstack && > > + !already_onsigstack && > > regs->ss != __USER_DS && > > !(ka->sa.sa_flags & SA_RESTORER) && > > ka->sa.sa_restorer) { > > /* This is the legacy signal stack switching. */ > > sp = (unsigned long) ka->sa.sa_restorer; > > + entering_altstack = true; > > } > > What a mess this whole signal handling is. I need a course in signal > handling to understand what's going on here... > > > > > sp = fpu__alloc_mathframe(sp, IS_ENABLED(CONFIG_X86_32), > > @@ -267,8 +278,16 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, size_t frame_size, > > * If we are on the alternate signal stack and would overflow it, don't. > > * Return an always-bogus address instead so we will die with SIGSEGV. > > */ > > - if (onsigstack && !likely(on_sig_stack(sp))) > > + if (unlikely(entering_altstack && > > + (sp <= current->sas_ss_sp || > > + sp - current->sas_ss_sp > current->sas_ss_size))) { > > You could've simply done > > if (unlikely(entering_altstack && !on_sig_stack(sp))) > > here. Nope. on_sig_stack() is a horrible kludge and won't work here. We could have something like __on_sig_stack() or sp_is_on_sig_stack() or something, though. > > > > + if (show_unhandled_signals && printk_ratelimit()) { > > + pr_info("%s[%d] overflowed sigaltstack", > > + tsk->comm, task_pid_nr(tsk)); > > + } > > Why do you even wanna issue that? It looks like callers will propagate > an error value up and people don't look at dmesg all the time. I figure that the people whose programs spontaneously crash should get a hint why if they look at dmesg. Maybe the message should say "overflowed sigaltstack -- try noavx512"? We really ought to have a SIGSIGFAIL signal that's sent, double-fault style, when we fail to send a signal.