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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D808C433EF for ; Sat, 26 Feb 2022 01:35:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BCE698D0002; Fri, 25 Feb 2022 20:35:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B80B98D0001; Fri, 25 Feb 2022 20:35:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6D9E8D0002; Fri, 25 Feb 2022 20:35:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0060.hostedemail.com [216.40.44.60]) by kanga.kvack.org (Postfix) with ESMTP id 994A48D0001 for ; Fri, 25 Feb 2022 20:35:53 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4AE4B181AC217 for ; Sat, 26 Feb 2022 01:35:53 +0000 (UTC) X-FDA: 79183214586.18.343F7EA Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by imf29.hostedemail.com (Postfix) with ESMTP id C7576120006 for ; Sat, 26 Feb 2022 01:35:51 +0000 (UTC) Received: by mail-pj1-f49.google.com with SMTP id bx9-20020a17090af48900b001bc64ee7d3cso6372814pjb.4 for ; Fri, 25 Feb 2022 17:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=WpU9pCYtYHOq/uhaCsMM/7Jj3sPtOe5SaReKe0eszxI=; b=K+J7F9HzV/9Sz2xGcjH6EyDqDjhx+eBWkUzD+F07R9mvbWF7RdqTa4735O5p6O4Ie0 Au48mtHHDm/DdLoRoYDZbv8ge5D4Qe+qughCaJojbHdvwkouodhSAvwlA92Uuk4rbE2F ODF0loMxDpYS2JHEUDW2z4mwoFot5F+FyaIcg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=WpU9pCYtYHOq/uhaCsMM/7Jj3sPtOe5SaReKe0eszxI=; b=fkqpTTue6jt9lTqCmkNHiZXsrdizoTTjMa4CIc1KYs4PHRL6yF5md7RLqXwefuQP5w wrxORbUbgm+RhdUrzHbdZeuAXJAk1Cw1YfYJu+lFzRZgeewye2BI2fk+HhRgVw75DLd9 XZ7isyD4gN0mY87c8YfWuE+f53qEz3hQqtAiVc8l9IKxFkj9Ml5Derm2vU9wNlM3pByg Nq8SCoQAzd26f2Jxu59QlhwxyCztmBkC/o2Plowy++70LdSqU2W8aNBPrOCfls6JwedU apbPW/3+xqzPYCbjQ0VM8R6asi7/hcBLaCiN4hSFhnBtUUM7gwtpmBJnNIPl8VTRLHjV vIVQ== X-Gm-Message-State: AOAM532FWGGNHoeBQ6mB3PbMzs2MereCNksDPHS2Zh5hm8DcVSa43/Na RYQtjb5RhZMBqxljCGFvCUE3Wg== X-Google-Smtp-Source: ABdhPJzzGQp7d+uCevH36MY309ZkNeJKKafuPCRtKeMtR1sNdWqZbF3ofCp8kZwki+6glky8YIys/A== X-Received: by 2002:a17:902:8d8b:b0:14f:795a:977a with SMTP id v11-20020a1709028d8b00b0014f795a977amr10167644plo.104.1645839350969; Fri, 25 Feb 2022 17:35:50 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id h5-20020a056a001a4500b004e177b8cbfdsm4601227pfv.197.2022.02.25.17.35.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Feb 2022 17:35:50 -0800 (PST) Date: Fri, 25 Feb 2022 17:35:49 -0800 From: Kees Cook To: Andrew Morton Cc: Matthew Wilcox , Josh Poimboeuf , linux-mm@kvack.org, Muhammad Usama Anjum , David Laight , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH v3] usercopy: Check valid lifetime via stack depth Message-ID: <202202251728.1634F405@keescook> References: <20220225173345.3358109-1-keescook@chromium.org> <20220225160157.680ecdea21ce81183059bb63@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220225160157.680ecdea21ce81183059bb63@linux-foundation.org> X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: C7576120006 X-Stat-Signature: hmdr6sb18wrzamggpcin9x56pz1sa7je Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=K+J7F9Hz; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf29.hostedemail.com: domain of keescook@chromium.org designates 209.85.216.49 as permitted sender) smtp.mailfrom=keescook@chromium.org X-HE-Tag: 1645839351-491389 X-Bogosity: Ham, tests=bogofilter, spamicity=0.046025, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Feb 25, 2022 at 04:01:57PM -0800, Andrew Morton wrote: > On Fri, 25 Feb 2022 09:33:45 -0800 Kees Cook wrote: > > > Under CONFIG_HARDENED_USERCOPY=y, when exact stack frame boundary checking > > is not available (i.e. everything except x86 with FRAME_POINTER), check > > a stack object as being at least "current depth valid", in the sense > > that any object within the stack region but not between start-of-stack > > and current_stack_pointer should be considered unavailable (i.e. its > > lifetime is from a call no longer present on the stack). > > > > Introduce ARCH_HAS_CURRENT_STACK_POINTER to track which architectures > > have actually implemented the common global register alias. > > > > Additionally report usercopy bounds checking failures with an offset > > from current_stack_pointer, which may assist with diagnosing failures. > > > > The LKDTM USERCOPY_STACK_FRAME_TO and USERCOPY_STACK_FRAME_FROM tests > > (once slightly adjusted in a separate patch) will pass again with > > this fixed. > > Again, what does this actually do? One of the things that CONFIG_HARDENED_USERCOPY checks is whether an object is overlapping the stack at all. If it is, it performs a number of inexpensive bounds checks. One of the finer-grained checks is whether an object cross stack frame within the stack region. Doing this with CONFIG_FRAME_POINTER was cheap/easy. Doing it with ORC is too heavy, and was left out (a while ago), leaving the courser whole-stack check. The LKDTM tests try to exercise the cross-frame cases to validate the defense. They have been failing every since (which was expected). More below... > > > Reported-by: Muhammad Usama Anjum > > A link to that report would shed some light. But actually describing > the user-visible impact right there in the changelog is preferable. Yes, good point. The bug[1] involves multiple LKDTM tests and their failure modes, so it wasn't a very clean pointer. But I will include it. [1] https://github.com/kernelci/kernelci-project/issues/84 > It sounds like a selftest is newly failing, which makes it a > userspace-visible regression, perhaps? No, it's been failing since ORC was introduced, but the regression in coverage (due to switching from FRAME_POINTER to ORC unwinder) was minimal. While discussing this with Muhammad, I realized we did, actually, have something that could be tested that was less than "the entire stack area" and "each specific frame", and that was current stack depth, so we gain back a little coverage. > If so, do we have a Fixes: and is a cc:stable warranted? I don't think it's warranted; it is technically a new feature. -Kees -- Kees Cook