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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB4ACC433EF for ; Wed, 11 May 2022 14:44:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244978AbiEKOos (ORCPT ); Wed, 11 May 2022 10:44:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243123AbiEKOop (ORCPT ); Wed, 11 May 2022 10:44:45 -0400 Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E5A2CC9EED for ; Wed, 11 May 2022 07:44:44 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id 204so2192991pfx.3 for ; Wed, 11 May 2022 07:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:user-agent:in-reply-to:references :message-id:mime-version:content-transfer-encoding; bh=bhQcuDbFN+fU3KR8R1nULy14OTLdd3tjeHOq6LBw/jA=; b=MfXAcKYU2l7shoPUEUT9umv0AimyIjCIDa/u/6CQTXKd7rI7SytNx4+XIbFn2F/H5L XmIfFWQ18UDPbWGEP7Dz38TbOKQYHunwXjiaAf1k/d6A2vSpF8yYFGpbr/TrbQtY/JBQ nlboE1r/uv06bW4AmuUu5DuZnkZwKEcor8K4A= 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:user-agent:in-reply-to :references:message-id:mime-version:content-transfer-encoding; bh=bhQcuDbFN+fU3KR8R1nULy14OTLdd3tjeHOq6LBw/jA=; b=HxTEyg8c7JFfAYFXu0fU3hgl2fZ96m4WLmmavXf8hCAcLAVHfnCP4dHF+euogwYkAv YXi+6AiZGDx8QonWvawkCvztyF7ml/Y+oljxweuaamJ/ojlWnczOnEBv8cP42bI3fRiM tjmcTOhQlZ6LAPVAlRBdvdXp1m3CiDDztB0ac6YjdSCYNyhiOjx7J4fcaFdRFXVwJEcy EkJc7H4yoJMAXKMNaPKHYjSiBhGFEvMkA5i8O5wlffLnDfrI4sUJny2Dv7vg++7oppsA 9EN7N7s2wa+88aU/OlK7IOn/JOLYvhaFlZvTkYfns9CXq2nmG0fOijGNBz0oY75xTBXM 5HQw== X-Gm-Message-State: AOAM532a0arJrXjYjj+e5FOzJ2mbWIUtwnpLm+3wGRAMjuWM8+hxVrxt xeY6Qxjxgt1MZVx2yQ4raQ/W0npgBfrwTg== X-Google-Smtp-Source: ABdhPJxZRgTo5oBTB6xChSJb/iElkzIkdPJzP8D0P+aQil2OueSocD8iod/FzFrA7CbbxWv7NK/PaA== X-Received: by 2002:a63:941:0:b0:3c6:8d64:ec01 with SMTP id 62-20020a630941000000b003c68d64ec01mr15724384pgj.322.1652280284455; Wed, 11 May 2022 07:44:44 -0700 (PDT) Received: from [127.0.0.1] (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id o6-20020a17090a420600b001cd498dc153sm2722800pjg.3.2022.05.11.07.44.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 May 2022 07:44:44 -0700 (PDT) Date: Wed, 11 May 2022 07:44:41 -0700 From: Kees Cook To: Mark Rutland CC: Alexander Popov , linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, luto@kernel.org, will@kernel.org Subject: Re: [PATCH v2 03/13] stackleak: remove redundant check User-Agent: K-9 Mail for Android In-Reply-To: References: <20220427173128.2603085-1-mark.rutland@arm.com> <20220427173128.2603085-4-mark.rutland@arm.com> <202205101958.2A33DE20@keescook> Message-ID: <33711C66-BB24-4A75-8756-3CDDA02BC0CD@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On May 11, 2022 1:02:45 AM PDT, Mark Rutland wr= ote: >On Tue, May 10, 2022 at 08:00:38PM -0700, Kees Cook wrote: >> On Tue, May 10, 2022 at 12:46:48PM +0100, Mark Rutland wrote: >> > On Sun, May 08, 2022 at 09:17:01PM +0300, Alexander Popov wrote: >> > > On 27=2E04=2E2022 20:31, Mark Rutland wrote: >> > > > In __stackleak_erase() we check that the `erase_low` value derive= d from >> > > > `current->lowest_stack` is above the lowest legitimate stack poin= ter >> > > > value, but this is already enforced by stackleak_track_stack() wh= en >> > > > recording the lowest stack value=2E >> > > >=20 >> > > > Remove the redundant check=2E >> > > >=20 >> > > > There should be no functional change as a result of this patch=2E >> > >=20 >> > > Mark, I can't agree here=2E I think this check is important=2E >> > > The performance profit from dropping it is less than the confidence= decrease :) >> > >=20 >> > > With this check, if the 'lowest_stack' value is corrupted, stacklea= k doesn't >> > > overwrite some wrong kernel memory, but simply clears the whole thr= ead >> > > stack, which is safe behavior=2E >> >=20 >> > If you feel strongly about it, I can restore the check, but I struggl= e to >> > believe that it's worthwhile=2E The `lowest_stack` value lives in the >> > task_struct, and if you have the power to corrupt that you have the p= ower to do >> > much more interesting things=2E >> >=20 >> > If we do restore it, I'd like to add a big fat comment explaining the >> > rationale (i=2Ee=2E that it only matter if someone could corrupt >> > `current->lowest_stack`, as otherwise that's guarnateed to be within = bounds)=2E >>=20 >> Yeah, let's restore it and add the comment=2E While I do agree it's lik= ely >> that such an corruption would likely mean an attacker had significant >> control over kernel memory already, it is not uncommon that an attack >> only has a limited index from a given address, etc=2E Or some manipulat= ion >> is possible via weird gadgets, etc=2E It's unlikely, but not impossible= , >> and a bounds-check for that value is cheap compared to the rest of the >> work happening=2E :) > >Fair enough; I can go spin a patch restoring this=2E I'm somewhat unhappy= with >silently fixing that up, though -- IMO it'd be better to BUG() or similar= in >that case=2E I share your desires, and this was exactly what Alexander originally propo= sed, but Linus rejected it violently=2E :( https://lore=2Ekernel=2Eorg/lkml/CA+55aFy6jNLsywVYdGp83AMrXBo_P-pkjkphPGrO= =3D82SPKCpLQ@mail=2Egmail=2Ecom/ --=20 Kees Cook 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5E704C433F5 for ; Wed, 11 May 2022 14:45:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:References: In-Reply-To:Subject:CC:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZORQUtl5kcul4ToGz9RjNtcLeoKocb/6O0YxBMS4dCI=; b=OOJGKq9HeDEGd3 +zthnKzUB3s0/tnz19l0wVQIHaz9jKL8gYQVHdAsII3TYPFBEXzjCWzFUBiiLtwHFb88dwLd/Ld+2 EFz0Y7vEFCLynSpJ993txgiF+xHU8yHrR2ovTH9PsutyJ6pQWvxIgA8JTu/7VTQlh1c++E1xFvZ9M ofdHvkIA1m3NixaGsvIuJp6CAcrMXljS6VMb0zh33KZn3j/2vYJGpQUzx4rONP7PX8fKKIZn3PMg2 TdPpp6stPET1p4j3Ea5Pp+Y2O5tm3sGsnfzJypAKrd6sHex/Ql+Z0aumXyxqF+6pXhtDcNF97TAJA vo9LeGnFldmIAfLRr3ng==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nona7-007I5s-3L; Wed, 11 May 2022 14:44:51 +0000 Received: from mail-pg1-x52d.google.com ([2607:f8b0:4864:20::52d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nona3-007I4M-FM for linux-arm-kernel@lists.infradead.org; Wed, 11 May 2022 14:44:49 +0000 Received: by mail-pg1-x52d.google.com with SMTP id 31so1980767pgp.8 for ; Wed, 11 May 2022 07:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:user-agent:in-reply-to:references :message-id:mime-version:content-transfer-encoding; bh=bhQcuDbFN+fU3KR8R1nULy14OTLdd3tjeHOq6LBw/jA=; b=MfXAcKYU2l7shoPUEUT9umv0AimyIjCIDa/u/6CQTXKd7rI7SytNx4+XIbFn2F/H5L XmIfFWQ18UDPbWGEP7Dz38TbOKQYHunwXjiaAf1k/d6A2vSpF8yYFGpbr/TrbQtY/JBQ nlboE1r/uv06bW4AmuUu5DuZnkZwKEcor8K4A= 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:user-agent:in-reply-to :references:message-id:mime-version:content-transfer-encoding; bh=bhQcuDbFN+fU3KR8R1nULy14OTLdd3tjeHOq6LBw/jA=; b=E66TAK4hB1rS9Owc0kzCOoxgMeRvjzsogCxJKIUNJeA8JGbjKXqf/k3artmqHFGxMG X7RmeULws6ukLwG/Pz8bS5ebOdtY7EDUH3VlbpzUnmPTEmmVuEMlg2VPRysDPoQEyvL/ 8bocHihaKb8pCtXdVWxg16d6QYDcZt/jN9vDKVXVQo01rowcTXZZ4P5JiF/iJDXqJiJS 9YRt+xvGIksCguxzfTY8FNvyPJGxXBW/ntIgmCDfujNGhhhsWO+Pic1SphP94Oahz2Mz BhC8yvmMJDHEgR2L34IH/3vfv1UkXz3cPb5gJEklYfuJ4WnjMLaIk7PMIdYlCX8abSio wMRQ== X-Gm-Message-State: AOAM532T7OKI/nTZu0egkGMNtpsFjJiDzW/PFO8yKIUA1dxA7pzW/+Y3 Qui701EtvSby8gRUBwKhxA/tSQ== X-Google-Smtp-Source: ABdhPJxZRgTo5oBTB6xChSJb/iElkzIkdPJzP8D0P+aQil2OueSocD8iod/FzFrA7CbbxWv7NK/PaA== X-Received: by 2002:a63:941:0:b0:3c6:8d64:ec01 with SMTP id 62-20020a630941000000b003c68d64ec01mr15724384pgj.322.1652280284455; Wed, 11 May 2022 07:44:44 -0700 (PDT) Received: from [127.0.0.1] (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id o6-20020a17090a420600b001cd498dc153sm2722800pjg.3.2022.05.11.07.44.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 May 2022 07:44:44 -0700 (PDT) Date: Wed, 11 May 2022 07:44:41 -0700 From: Kees Cook To: Mark Rutland CC: Alexander Popov , linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, luto@kernel.org, will@kernel.org Subject: Re: [PATCH v2 03/13] stackleak: remove redundant check User-Agent: K-9 Mail for Android In-Reply-To: References: <20220427173128.2603085-1-mark.rutland@arm.com> <20220427173128.2603085-4-mark.rutland@arm.com> <202205101958.2A33DE20@keescook> Message-ID: <33711C66-BB24-4A75-8756-3CDDA02BC0CD@chromium.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220511_074447_585566_C4B23C2B X-CRM114-Status: GOOD ( 23.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On May 11, 2022 1:02:45 AM PDT, Mark Rutland wrote: >On Tue, May 10, 2022 at 08:00:38PM -0700, Kees Cook wrote: >> On Tue, May 10, 2022 at 12:46:48PM +0100, Mark Rutland wrote: >> > On Sun, May 08, 2022 at 09:17:01PM +0300, Alexander Popov wrote: >> > > On 27.04.2022 20:31, Mark Rutland wrote: >> > > > In __stackleak_erase() we check that the `erase_low` value derived from >> > > > `current->lowest_stack` is above the lowest legitimate stack pointer >> > > > value, but this is already enforced by stackleak_track_stack() when >> > > > recording the lowest stack value. >> > > > >> > > > Remove the redundant check. >> > > > >> > > > There should be no functional change as a result of this patch. >> > > >> > > Mark, I can't agree here. I think this check is important. >> > > The performance profit from dropping it is less than the confidence decrease :) >> > > >> > > With this check, if the 'lowest_stack' value is corrupted, stackleak doesn't >> > > overwrite some wrong kernel memory, but simply clears the whole thread >> > > stack, which is safe behavior. >> > >> > If you feel strongly about it, I can restore the check, but I struggle to >> > believe that it's worthwhile. The `lowest_stack` value lives in the >> > task_struct, and if you have the power to corrupt that you have the power to do >> > much more interesting things. >> > >> > If we do restore it, I'd like to add a big fat comment explaining the >> > rationale (i.e. that it only matter if someone could corrupt >> > `current->lowest_stack`, as otherwise that's guarnateed to be within bounds). >> >> Yeah, let's restore it and add the comment. While I do agree it's likely >> that such an corruption would likely mean an attacker had significant >> control over kernel memory already, it is not uncommon that an attack >> only has a limited index from a given address, etc. Or some manipulation >> is possible via weird gadgets, etc. It's unlikely, but not impossible, >> and a bounds-check for that value is cheap compared to the rest of the >> work happening. :) > >Fair enough; I can go spin a patch restoring this. I'm somewhat unhappy with >silently fixing that up, though -- IMO it'd be better to BUG() or similar in >that case. I share your desires, and this was exactly what Alexander originally proposed, but Linus rejected it violently. :( https://lore.kernel.org/lkml/CA+55aFy6jNLsywVYdGp83AMrXBo_P-pkjkphPGrO=82SPKCpLQ@mail.gmail.com/ -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel