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 E8F21C433EF for ; Sat, 26 Feb 2022 02:22:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 18DD98D0002; Fri, 25 Feb 2022 21:22:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 13D738D0001; Fri, 25 Feb 2022 21:22:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 006078D0002; Fri, 25 Feb 2022 21:22:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id E6A708D0001 for ; Fri, 25 Feb 2022 21:22:24 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B3CB621EA7 for ; Sat, 26 Feb 2022 02:22:24 +0000 (UTC) X-FDA: 79183331808.05.CAB563A Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf27.hostedemail.com (Postfix) with ESMTP id 3E17140002 for ; Sat, 26 Feb 2022 02:22:24 +0000 (UTC) Received: by mail-pg1-f172.google.com with SMTP id 12so6256705pgd.0 for ; Fri, 25 Feb 2022 18:22:24 -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=NU41BZVIshf7xI3L4T/th6wwfkRDpNs6CMZQ6sz+OAM=; b=P6Xk413iS6EAWJWQRkLzz7tKoG18NCXD+I/wkPxSiv5SfckJssGuwRaZrxNU66YxYO XOWgPxrzCcCADU7qobCC4NNMNYu5DrVJqZKCyml6vFAmQy1+57T7crw9dlU3TmZKxlin SeNvXjscHDzJUZOpUXhEQoqNxOS5sxijcUJmQ= 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=NU41BZVIshf7xI3L4T/th6wwfkRDpNs6CMZQ6sz+OAM=; b=ejXmg5BqXeOGg2bpsRV0xWsmfkEACcgwanu2Yvm/db8dvlGYvUqzeQjITFbrhupub3 A5fDnC14+2X8GLVkQnTYW0gyVHZZ88CFOXAbdF6ZMPVEfGpvIfWSBqnbuHOGG4QjdlZN c2Bm2y/pC7COwTL913ZbcOly6uHpbpexA7QGnTO2HQ6Kvw70eTaBy7k6i7FRUkizqBe7 nfDsK/U3L5Hddx/Qjsz854VKyvc0FxwdVd5bKKjgZ8wxox+0YyajcvGv4LZZhAGHIZgX FB7jDz7A2MRvO40NFGrNFKZTDGdbpJ5UXYZt3wazuIN8mydJZNycOQy9Scu5ZKuDUtY3 xQQg== X-Gm-Message-State: AOAM53158LV+flggFnKowWgDzbLD1oZcoBNU7ADB9OJW4TccRyp1TWmd RvoznUhAERnMpp+gYeCYr3rjNA== X-Google-Smtp-Source: ABdhPJx+FVw9r8IymeMRCm4kNuD+w2IV8xHis4JNEOsKF3lH1u8GZSFdKMk4mq8Sj3CelVcc0a4w6w== X-Received: by 2002:a05:6a00:3018:b0:4e1:de9a:a5a3 with SMTP id ay24-20020a056a00301800b004e1de9aa5a3mr10699058pfb.80.1645842143157; Fri, 25 Feb 2022 18:22:23 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id pg14-20020a17090b1e0e00b001bbadc2205dsm3946625pjb.20.2022.02.25.18.22.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Feb 2022 18:22:22 -0800 (PST) Date: Fri, 25 Feb 2022 18:22:22 -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: <202202251818.BC91622D@keescook> References: <20220225173345.3358109-1-keescook@chromium.org> <20220225160157.680ecdea21ce81183059bb63@linux-foundation.org> <202202251728.1634F405@keescook> <20220225174657.9e1af8ec59ce8dbf223f84c5@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220225174657.9e1af8ec59ce8dbf223f84c5@linux-foundation.org> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3E17140002 X-Stat-Signature: p4obq8mm1ib41d4i7yscnju3ppak7o6i Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=P6Xk413i; spf=pass (imf27.hostedemail.com: domain of keescook@chromium.org designates 209.85.215.172 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspam-User: X-HE-Tag: 1645842144-477322 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 05:46:57PM -0800, Andrew Morton wrote: > On Fri, 25 Feb 2022 17:35:49 -0800 Kees Cook wrote: > > > 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? > > > > [answers] > > > > OK, thanks. I think a new changelog is warranted? Yup, I've cut/pasted most of that into the new changelog: usercopy: Check valid lifetime via stack depth One of the things that CONFIG_HARDENED_USERCOPY sanity-checks is whether an object that is about to be copied to/from userspace 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 crosses stack frames within the stack region. Doing this on x86 with CONFIG_FRAME_POINTER was cheap/easy. Doing it with ORC was deemed too heavy, and was left out (a while ago), leaving the courser whole-stack check. The LKDTM tests USERCOPY_STACK_FRAME_TO and USERCOPY_STACK_FRAME_FROM try to exercise these cross-frame cases to validate the defense is working. They have been failing ever since ORC was added (which was expected). While Muhammad was investigating various LKDTM failures[1], he asked me for additional details on them, and I realized that when exact stack frame boundary checking is not available (i.e. everything except x86 with FRAME_POINTER), it could check if a stack object is 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) pass again with this fixed. [1] https://github.com/kernelci/kernelci-project/issues/84 Cc: Matthew Wilcox (Oracle) Cc: Josh Poimboeuf Cc: Andrew Morton Cc: linux-mm@kvack.org Reported-by: Muhammad Usama Anjum Signed-off-by: Kees Cook --- v1: https://lore.kernel.org/lkml/20220216201449.2087956-1-keescook@chromium.org v2: https://lore.kernel.org/lkml/20220224060342.1855457-1-keescook@chromium.org v3: https://lore.kernel.org/lkml/20220225173345.3358109-1-keescook@chromium.org v4: - improve commit log (akpm) > What's your preferred path for upstreaming this change? I figured I would take it via my for-next/hardening tree; I have 2 arch changes ready to go (Acked by maintainers) there too (to add current_stack_pointer). Thanks for the review! -- Kees Cook