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 A0DDCC5475B for ; Sat, 2 Mar 2024 01:51:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D31DB6B009B; Fri, 1 Mar 2024 20:51:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CE20D6B009C; Fri, 1 Mar 2024 20:51:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B81DA6B009D; Fri, 1 Mar 2024 20:51:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A8F766B009B for ; Fri, 1 Mar 2024 20:51:12 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4812FC068D for ; Sat, 2 Mar 2024 01:51:12 +0000 (UTC) X-FDA: 81850421184.29.3F59B13 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by imf02.hostedemail.com (Postfix) with ESMTP id 8357F80004 for ; Sat, 2 Mar 2024 01:51:10 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=auCWnUmi; spf=pass (imf02.hostedemail.com: domain of keescook@chromium.org designates 209.85.215.170 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709344270; a=rsa-sha256; cv=none; b=K42hcpQ56kH/AN2p80YHB986zMsrLDQa2lWVWZCdmWBISdifVpS+UCqk/gLCDfbLA51GIN ltMTY3FkmzGeF11PxDrj+ckrI50DyDOqXiu0Tj2ObsJ6d2UQPfPVr3PSHimp8r9jJcDqqo DsJr9gEMTkXdUmAKrWeWs60218J7t1c= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=auCWnUmi; spf=pass (imf02.hostedemail.com: domain of keescook@chromium.org designates 209.85.215.170 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709344270; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1JOHRODJmattJBY3YtQ+51tfBSOEI55kux6+SckPNNk=; b=g7uHRSLo3nAd95By5x55m6foJ+p7//yxDg9sthzdPtfkQe2zlUfO9JPm1BU3vU4ZgjHYFF iZDbbH80Nm4K8ZZGPMfA4ZfZltMcBkVvBola0l6gxj20HT9/9imbuGw821ZfqCmqY0O93q CHl1sy1L9j5jydOr+Lk8uDiwhtNIHLQ= Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-517ab9a4a13so2219411a12.1 for ; Fri, 01 Mar 2024 17:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1709344269; x=1709949069; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=1JOHRODJmattJBY3YtQ+51tfBSOEI55kux6+SckPNNk=; b=auCWnUmicdUOQQp1hhAqdYGvyCLZLinarA5dhLSR/PFijKsctQKsQKPGma7DAtODKG WYbIEF4XitMDCA/GrquY87fDyEvdW3aqjzAhNJEfmzWKpYDjhPZfjqbwo2QJfKx6s80k SlL7pVnneAv771pAfuANSUw/jklWS7J+ZHDGM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709344269; x=1709949069; h=in-reply-to:content-transfer-encoding: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=1JOHRODJmattJBY3YtQ+51tfBSOEI55kux6+SckPNNk=; b=TQJJH+c40tw1XCgpkXKUNVkkNrvI+nK5XYgtl9rq+BM7lW3NyAz3hHHskfzz09auRX Ob+Q7dC+qoU7h3PW5uABqz1x33jkorEoFj/Ab/g8MfOpOwU8ECifzKwG7Gu2IcFIDKlZ SNOgHOm116apTs8J56ewNufVaOUZTO3FB+IwvpqhPECr0qzGsskvOFaYFULMdA465NDl PE8vI8INj8rTsKqH1ft7aj2MciwDG8G5dlUXkYxI0FHEkqYFYl4IfPLQ4PnOloKXv5bj l1SbvwJwoZJMcGnMcTXRkZree463x5YxLLvshl+2xqGzeAbRBDOJpRRflptwyPNo1yBm Vh6A== X-Forwarded-Encrypted: i=1; AJvYcCWMBt8h2QUt/VDXWjeDatOMwPVRX8tN4lmznWLYI7Vh3+QQXBW3CcQfa5FrQnbHwFrcURpcZqHR11FfZkin+YL3By4= X-Gm-Message-State: AOJu0YwUqZ2oeDLfy4UYfGTH06hfxo3SD3Jq5tR/qiT1pP+MoTsQOx/T YP03/OE1J8Vf/ebiv51JyviJubTLZsqdTEdLrN5CEnGy3nQcf168pGSHedVULw== X-Google-Smtp-Source: AGHT+IHRDk8dRy87orC5sOO0fLYLW475IUp9U1sSARPtPvgR8uAOkuMFjfqikjpTM+PGmCnZ+zOW8Q== X-Received: by 2002:a05:6a20:e11f:b0:1a0:ef1e:a5a7 with SMTP id kr31-20020a056a20e11f00b001a0ef1ea5a7mr3447528pzb.4.1709344269211; Fri, 01 Mar 2024 17:51:09 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id rm12-20020a17090b3ecc00b002993f72ed02sm3845854pjb.34.2024.03.01.17.51.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 17:51:08 -0800 (PST) Date: Fri, 1 Mar 2024 17:51:08 -0800 From: Kees Cook To: "Edgecombe, Rick P" Cc: "christophe.leroy@csgroup.eu" , "linux-kernel@vger.kernel.org" , "x86@kernel.org" , "luto@kernel.org" , "dave.hansen@linux.intel.com" , "debug@rivosinc.com" , "akpm@linux-foundation.org" , "linux-sh@vger.kernel.org" , "linux-csky@vger.kernel.org" , "mingo@redhat.com" , "kirill.shutemov@linux.intel.com" , "tglx@linutronix.de" , "linux-parisc@vger.kernel.org" , "loongarch@lists.linux.dev" , "linux-mm@kvack.org" , "linux-snps-arc@lists.infradead.org" , "Liam.Howlett@oracle.com" , "hpa@zytor.com" , "peterz@infradead.org" , "linuxppc-dev@lists.ozlabs.org" , "bp@alien8.de" , "linux-s390@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mips@vger.kernel.org" , "sparclinux@vger.kernel.org" , "broonie@kernel.org" Subject: Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info Message-ID: <202403011747.9ECFAD060B@keescook> References: <20240226190951.3240433-1-rick.p.edgecombe@intel.com> <20240226190951.3240433-6-rick.p.edgecombe@intel.com> <94a2b919-e03b-4ade-b13e-7774849dc02b@csgroup.eu> <202402271004.7145FDB53F@keescook> <8265f804-4540-4858-adc3-a09c11a677eb@csgroup.eu> <91384b505cb78b9d9b71ad58e037c1ed8dfb10d1.camel@intel.com> <202402280912.33AEE7A9CF@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 8357F80004 X-Stat-Signature: wqhensew68mq9jiek7fb1a7bmxjdqauw X-Rspam-User: X-HE-Tag: 1709344270-197145 X-HE-Meta: U2FsdGVkX191zcs/XZocDkwFeimTYF4U/nX0MQaUTmAudymmwKcHwQ5RCCgl6nZfVgpyfYMo/0jPVCilBcw9Bug1CScEHysFL+Pg2ZOxmZsJe2h29IMviJsM+NvD8/QjVrhDHRFzT7g/cu2jARgvcN5UOhX3cWvm/g51rAkkpeALkrDFIsrmxuWS23TKj0lptu98gnSRFk9id27OhLz+zDAk7dx0kxU+QA5HSDlNCXI0bdegC0ZZpLUsAJ4E8TfIteVSYuNVGAxvY7pcS2cohINp/KvUAgIwuuBQmTyKb2i7B0X1jOSsNqJV2TTDGdtAQ9wOKLeumOE0m67ekuJh3azbP9okQ8vinMbjvbekdUh07ngiGp7gaSO0gshBbIEqfl2/Mg5CiMh8nE0OYI/vCJPYt1lf3Um4bwbxVwzKBoeI6DaCulKsKDNDiV8zaETDjiL9KAxRL/Z6+t9lWNthWV2vIUGAi2BmzCbqBkoJEjYVlR+XbBNKiTuu8bXpSFCkAqcYVwUmrSug0w6b2jsdBpW1g2alVykZKQZtLb5O7BxYSHBMcs+PHY932OaFq4RVr11lBnMtisjCqo+PIdUcsIYtM0tGBDt591F005p65r6CeiyClW5ilQhLzcb92VRKBG0oNTNRSleS5vkw9LNditicOyDd0wICfWw7wlk1ipZJR7ytwJMqmsXPSwNJecFMgN5IcHpwaQFgzfEQFDECz7Rd3KNQ1EHGYMvjWIzrwM2ZYT3IZKgTJnyQa5vmYvQcb4E4hvEf1O6VguaqvqfJR/3/vOIMrF9jY89IH5ndhOd2CnWJiWbYXNxeU/FI1cA18HvDTRin/U39ovNDvnvYtbkWC4jAjXBZ5E4j9UmQT35SkUlnuZ7QWrdVHXP5ih5LujSyfn6riydEpDo6eT3T/PY6+uuCyjqifyp+Vby14fcpFlZh45ebdlfjdNgJwLJXAsQb5ynfW5mF/lAahWG KcE+mPz4 BIE18Z6TO8ahqVTJtnC3/VxyrsVkutGvnBnJPXs9f1/I/jwyVAVceMsVxP2HsjNBzZsqovmBFJwVmjx6M5F1mFiB2nVD0BnSfL4L+wv7HXwGt/N15s3RasfSocHr2Ur4HdgNJbctPfexR1i6mQ12GHe0TBcFv+qzG8nDcOTaGNYVOxwU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, Mar 02, 2024 at 12:47:08AM +0000, Edgecombe, Rick P wrote: > On Wed, 2024-02-28 at 09:21 -0800, Kees Cook wrote: > > I totally understand. If the "uninitialized" warnings were actually > > reliable, I would agree. I look at it this way: > > > > - initializations can be missed either in static initializers or via > >   run time initializers. (So the risk of mistake here is matched -- > >   though I'd argue it's easier to *find* static initializers when > > adding > >   new struct members.) > > - uninitialized warnings are inconsistent (this becomes an unknown > > risk) > > - when a run time initializer is missed, the contents are whatever > > was > >   on the stack (high risk) > > - what a static initializer is missed, the content is 0 (low risk) > > > > I think unambiguous state (always 0) is significantly more important > > for > > the safety of the system as a whole. Yes, individual cases maybe bad > > ("what uid should this be? root?!") but from a general memory safety > > perspective the value doesn't become potentially influenced by order > > of > > operations, leftover stack memory, etc. > > > > I'd agree, lifting everything into a static initializer does seem > > cleanest of all the choices. > > Hi Kees, > > Well, I just gave this a try. It is giving me flashbacks of when I last > had to do a tree wide change that I couldn't fully test and the > breakage was caught by Linus. Yeah, testing isn't fun for these kinds of things. This is traditionally why the "obviously correct" changes tend to have an easier time landing (i.e. adding "= {}" to all of them). > Could you let me know if you think this is additionally worthwhile > cleanup outside of the guard gap improvements of this series? Because I > was thinking a more cowardly approach could be a new vm_unmapped_area() > variant that takes the new start gap member as a separate argument > outside of struct vm_unmapped_area_info. It would be kind of strange to > keep them separate, but it would be less likely to bump something. I think you want a new member -- AIUI, that's what that struct is for. Looking at this resulting set of patches, I do kinda think just adding the "= {}" in a single patch is more sensible. Having to split things that are know at the top of the function from the stuff known at the existing initialization time is rather awkward. Personally, I think a single patch that sets "= {}" for all of them and drop the all the "= 0" or "= NULL" assignments would be the cleanest way to go. -Kees -- Kees Cook