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 04E47C001B0 for ; Thu, 10 Aug 2023 20:12:35 +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:In-Reply-To:MIME-Version:References: Message-ID: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=MvF5S2BVb5+qlXU7zI3TjCLIm47AAgoNMt0GlXGHzG0=; b=cEoc6PoSO4SCgt s7SJ80IXYYaXcPSZAsASdLzYUAE2uH090E6odwdXbNtXWjDtS1jZVMgGWIzvZ0gS7/IHSrQesbdEh UraVWczIqObGBiW6B61iVc67M2aWWiti8NhOvj3jYxDCOgFbuOaMD7MvotuqQUBk/yKxJaSuQOTpO 7ptsmXjZPzcyzWLKRV7iJ8xmscTn4aBfob6vtCsnqzTgS9fBCmrMO6aQzGWEb6XfCgXR2/GkOTPHq 37QqSSYxkcHE6nw2Rij2YCWF9hi9dynHAytUqOcSXcYbdtHlOAYSLrTwMGLWckeu8jyRCsrGCyTWD Z6zyHRKHwJuHS2gRVTow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qUC0y-008d92-2B; Thu, 10 Aug 2023 20:12:12 +0000 Received: from mail-pg1-x52f.google.com ([2607:f8b0:4864:20::52f]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qUC0v-008d5M-0h for linux-arm-kernel@lists.infradead.org; Thu, 10 Aug 2023 20:12:10 +0000 Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-54290603887so889460a12.1 for ; Thu, 10 Aug 2023 13:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1691698320; x=1692303120; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=YgXTJGJNIG5brUNilbYvmAufJFTfjCt86nj6wBgTVtw=; b=fyUQ4xBfwdZ9Y1ncwPWe8KTy87SugAY04QbysuNfCKESxljSeA//xKB0ll7SV9MfBn Qolk9WYlCPFGiQVFIlruea5ANAIMyj2MFfbdlKAdMKJ07nVHWugx38DTOanRdd2Cvm89 JEkZdTPYMsehHWh3x07+sxbrflynbDh3hIrFU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691698320; x=1692303120; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YgXTJGJNIG5brUNilbYvmAufJFTfjCt86nj6wBgTVtw=; b=jMAPVsBMimG72GMvKrJa2ntP/1yDV07zA9qWgZsyKf+IKsGB775DY0WsVyteyJC4Sp z3pvlcZppQh5PRPxqSrDcj8C5T3dBQq970v8vhq2eSbTbmboQ4ekcYR9MOG3VFjMafD3 oYer3nd2qr4d63t6ckQqm7TtTtGdvIfrsSFG4a2TJGmQ3bT9b1q33VhKpF41BoWn7kr5 AswcqjSwdLu1hCSXinw5XI+qT+fUWWdQFpXHzusR9vzgExAdjEmHAMSMMIQhboqQ3cig 6p/OxigIbEvgNOKldZBisN4GRsyun6NGw0cfNaA/saC1Gn9Xzq2RxL/0D73hEh3KlBGR BoYQ== X-Gm-Message-State: AOJu0Yyw1eYaMPXs/MNS1zweEBDGPqUt94p53W5GnEZhw28gPQxiq1cK uiOm306OcQpjWNtqLC4aFerj+Q== X-Google-Smtp-Source: AGHT+IFPUbfQ62us+66kx+c9LMghiGBoteLeh6oMSfQPptLuZm4cxwBZSfUhKnCZaZrURJ2FlP0dLA== X-Received: by 2002:a17:90a:5d91:b0:262:f09c:e73d with SMTP id t17-20020a17090a5d9100b00262f09ce73dmr2794613pji.34.1691698320688; Thu, 10 Aug 2023 13:12:00 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id 5-20020a17090a1a4500b00263f446d432sm4004127pjl.43.2023.08.10.13.11.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Aug 2023 13:11:59 -0700 (PDT) Date: Thu, 10 Aug 2023 13:11:58 -0700 From: Kees Cook To: Marco Elver Cc: Steven Rostedt , Andrew Morton , Guenter Roeck , Peter Zijlstra , Mark Rutland , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Nathan Chancellor , Nick Desaulniers , Tom Rix , Miguel Ojeda , Sami Tolvanen , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, Dmitry Vyukov , Alexander Potapenko , kasan-dev@googlegroups.com, linux-toolchains@vger.kernel.org Subject: Re: [PATCH v3 3/3] list_debug: Introduce CONFIG_DEBUG_LIST_MINIMAL Message-ID: <202308101259.D2C4C72F8@keescook> References: <20230808102049.465864-1-elver@google.com> <20230808102049.465864-3-elver@google.com> <202308081424.1DC7AA4AE3@keescook> <20230809113021.63e5ef66@gandalf.local.home> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230810_131209_253767_1647D300 X-CRM114-Status: GOOD ( 26.79 ) 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 Wed, Aug 09, 2023 at 06:32:37PM +0200, Marco Elver wrote: > On Wed, Aug 09, 2023 at 11:30AM -0400, Steven Rostedt wrote: > [...] > > > > I would actually prefer DEBUG_LIST to select HARDEN_LIST and not the other > > way around. It logically doesn't make sense that HARDEN_LIST would select > > DEBUG_LIST. That is, I could by default want HARDEN_LIST always on, but not > > DEBUG_LIST (because who knows, it may add other features I don't want). But > > then, I may have stumbled over something and want more info, and enable > > DEBUG_LIST (while still having HARDEN_LIST) enabled. > > > > I think you are looking at this from an implementation perspective and not > > the normal developer one. > > > [...] > > > > That is, if DEBUG_LIST is enabled, we always call the > > __list_add_valid_or_report(), but if only HARDEN_LIST is enabled, then we > > do the shortcut. > > Good point - I think this is better. See below tentative v4. > > Kees: Does that also look more like what you had in mind? Yeah, this looks good. My only nit would be a naming one. All the other hardening features are named "HARDENED", but perhaps the "ED" is redundant in the others. Still, consistency seems nicer. What do you think of CONFIG_LIST_HARDENED ? (The modern trend for Kconfig naming tends to keep the subsystem name first and then apply optional elements after.) One note: do the LKDTM list hardening tests still pass? i.e. CORRUPT_LIST_ADD CORRUPT_LIST_DEL > [...] > + /* > + * With the hardening version, elide checking if next and prev > + * are NULL, LIST_POISON1 or LIST_POISON2, since the immediate > + * dereference of them below would result in a fault. > + */ > + if (likely(prev->next == entry && next->prev == entry)) > + return true; I'm not super excited about skipping those checks, since they are values that can be reached through kernel list management confusion. If an attacker is using a system where the zero-page has been mapped and is accessible (i.e. lacking SMAP etc), then attacks could still be constructed. However, I do recognize this chain of exploitation prerequisites is getting rather long, so probably this is a reasonable trade off on modern systems. -Kees -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel