Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1589142pxb; Thu, 4 Feb 2021 17:48:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJzXX+oFm+SaJJKfkpe4kXFm3uAV2ByPMC8kFz0G7RfkklobyLWbel58rU1fkbn50k2jtEu/ X-Received: by 2002:a05:6402:220e:: with SMTP id cq14mr1341774edb.240.1612489713092; Thu, 04 Feb 2021 17:48:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612489713; cv=none; d=google.com; s=arc-20160816; b=ETxVCLd0jqwIbwmKbXYKhLUrxpPA1iCKZZxwoUTGpsfhH2XMejf/Cr407y/XLGnUI1 K1yQ4c+/Sgm4dzs4hDi09mvBYtFMsMwCmA1VEcjcV11PnpPRKKwdPH4kqP30r26sSBup 7tduEzzAof8KZt2ekuW2Ee+8XFO2J/s5cb/xnWif4coSUsYQ3pXIIbnLZJc6Cz1oK0RN FEn+DcqKcqWyvYcG2wRou2/YjYqW7eMbDPCriQ9RG8NOt0HPJBYOzRp+m14I60/FI614 HsTN3ZvKbyaQC7dK8v3yzdNrOm5LtPfBk231inb5Fo9YiYMG20cAOH1LhxWAM7OqwmA4 1jQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ob/Q0z75fUha7sOp70sKDWv4y9mB1atawq7qE94MTs8=; b=F1B3EDCJAaq5orGMyDuj+7EqVrRmUKP+FuV5W0IpYmKBduilNOwQ4a6k9/+CeH0FoQ GBPxgjImYTwinOmGP3zJNYzXT1JAD4X2w3sq12YAmBrKUNGEmTTv4e+hlAUsRN9efJZl 21XF/qtUBtZBCt4eDCwZfatY7AsxvFaNiB44JvB6Sh/tE5RVtctbSfsF248o1Rqsfdvi 1691yCYdUT0oWK8yVBScXRX0s0UWWyzx+DJgP0mr2QrmOLNaTiDaR+NgMuIvbQO7/3ZK jJzpBp3qLcoFSuVwAyYY67m1oOUBXAgMnFctgoX2L9R7bi9zYHoLUKlUNCdzlysB2TaA GTyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=YamBDRsT; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d5si3266780edo.481.2021.02.04.17.48.08; Thu, 04 Feb 2021 17:48:33 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b=YamBDRsT; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239717AbhBDU3B (ORCPT + 99 others); Thu, 4 Feb 2021 15:29:01 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:37262 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240105AbhBDUYB (ORCPT ); Thu, 4 Feb 2021 15:24:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612470155; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ob/Q0z75fUha7sOp70sKDWv4y9mB1atawq7qE94MTs8=; b=YamBDRsT/DGgjlEEU2gnfEKXQzyjq08J65ne3Es0B6VqookBoqTg3USp2F42RXDrD1b9UY 0CYLjCoZhmIEFZCVOYISKIpu7F5yoaWaCxZEjp3u3CaJhOFoDfuDawP9QR9evxoIX4nTGU l3lATF3zqFDywgPY4CSLTlKfgzNvsXo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-428-A7ohRb1EOQ2tcgOjpeJI5w-1; Thu, 04 Feb 2021 15:22:31 -0500 X-MC-Unique: A7ohRb1EOQ2tcgOjpeJI5w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0E1A18030B5; Thu, 4 Feb 2021 20:22:27 +0000 (UTC) Received: from treble (ovpn-114-156.rdu2.redhat.com [10.10.114.156]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2A7DB722D9; Thu, 4 Feb 2021 20:22:14 +0000 (UTC) Date: Thu, 4 Feb 2021 14:22:10 -0600 From: Josh Poimboeuf To: Ivan Babrou Cc: kernel-team , Ignat Korchagin , Hailong liu , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Miroslav Benes , Julien Thierry , Jiri Slaby , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel , Alasdair Kergon , Mike Snitzer , dm-devel@redhat.com, "Steven Rostedt (VMware)" , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , John Fastabend , KP Singh , Robert Richter , "Joel Fernandes (Google)" , Mathieu Desnoyers , Linux Kernel Network Developers , bpf@vger.kernel.org, Alexey Kardashevskiy Subject: Re: BUG: KASAN: stack-out-of-bounds in unwind_next_frame+0x1df5/0x2650 Message-ID: <20210204202210.4awpfn2ckdv7h5cf@treble> References: <20210203190518.nlwghesq75enas6n@treble> <20210203232735.nw73kugja56jp4ls@treble> <20210204001700.ry6dpqvavcswyvy7@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 04, 2021 at 11:51:44AM -0800, Ivan Babrou wrote: > > .macro FUNC_SAVE > > #the number of pushes must equal STACK_OFFSET > > + push %rbp > > + mov %rsp, %rbp > > push %r12 > > push %r13 > > push %r14 > > @@ -271,12 +273,14 @@ VARIABLE_OFFSET = 16*8 > > .endm > > > > .macro FUNC_RESTORE > > + add $VARIABLE_OFFSET, %rsp > > mov %r14, %rsp > > > > pop %r15 > > pop %r14 > > pop %r13 > > pop %r12 > > + pop %rbp > > .endm > > > > # Encryption of a single block > > > > This patch seems to fix the following warning: > > [ 147.995699][ C0] WARNING: stack going in the wrong direction? at > glue_xts_req_128bit+0x21f/0x6f0 [glue_helper] > > Or at least I cannot see it anymore when combined with your other > patch, not sure if it did the trick by itself. > > This sounds like a good reason to send them both. Ok, that's what I expected. The other patch fixed the unwinder failure mode to be the above (harmless) unwinder warning, instead of a disruptive KASAN failure. This patch fixes the specific underlying crypto unwinding metadata issue. I'll definitely be sending both fixes. The improved failure mode patch will come first because it's more urgent and lower risk. -- Josh