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 C0C5EC46CD2 for ; Tue, 30 Jan 2024 19:54:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2A5CA6B0075; Tue, 30 Jan 2024 14:54:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 22DEA6B0089; Tue, 30 Jan 2024 14:54:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0CF7A6B0085; Tue, 30 Jan 2024 14:54:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EABF76B0089 for ; Tue, 30 Jan 2024 14:54:07 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9E43740131 for ; Tue, 30 Jan 2024 19:54:07 +0000 (UTC) X-FDA: 81737028534.16.70D593A Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf28.hostedemail.com (Postfix) with ESMTP id AF207C000D for ; Tue, 30 Jan 2024 19:54:05 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TyattJLG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706644445; a=rsa-sha256; cv=none; b=TOkuZ/XYkUVyM/DzNRMJXFQQTIdhkCEHCf4j7WxeM0OcPHNFGgy2TXeZGDQf59CSh/IeQa Iv3F+C2//5Lv42v2EC5XDEFL/vYOKO+g5ePQjaOaAc7SG2QtGJF6XNv3Bu/LhGeT1cMfl+ Cm/0oQOkx0cDeQtJdNIYX2p7pjOlLB0= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TyattJLG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706644445; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=D3wO7BFSthurTRKjqrvhcV7JSVxdDru5aDJKbt2OZqE=; b=P4XlG23FpVeNwxQKnYFwp4esW8/iNY3kkOcyzJiHJ2DG397CPZSA5qXpcK21Hy3hDejTwE WD1BadNM/DYvy3EjGsSvBIEpmZtQPwpsyhBOM03NZnC6Spr6x2mWUyNC8KvhajZsJa8+fa ipgxdeIR9Z583rSKmmtuivQGVam5x0I= Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-51109060d6aso4118084e87.2 for ; Tue, 30 Jan 2024 11:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706644444; x=1707249244; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=D3wO7BFSthurTRKjqrvhcV7JSVxdDru5aDJKbt2OZqE=; b=TyattJLGQryq+DE+p+4So2V7P2HVFQv7gYRXMW5voi5KPKGmSXNi5I1Z1fncY5+vbY ShZkJ2xT9mmkuLsghw23vCuldmH6luj48rMA9stXWsahtOlJB6cFTZYHWLkGZ1pz+vXr Nc2rBfoRU4Gc706uetSnOkP3Vm9ziycSFy2OHk4nTlz66uW6aYTP1qNPnrAtj65Ss2wy KoN79tZ9zEhGl7bKRs1YqgEFCkDp0XyL413l/BHMvV5WYYp10u833QFClpT35VmAeN5y 2M+vKdxaEFeDz89Pnsvj2nW6A4iuzQ7SGCeAUALuj6YTfb/gqe9669udyHOKMsDffNAf 9oPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706644444; x=1707249244; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=D3wO7BFSthurTRKjqrvhcV7JSVxdDru5aDJKbt2OZqE=; b=lfn2s96/RfQ6NScmI7HXdwspcW93fpfiajBI2dLHq6qa3ATw5xCDFgMsNujs6+++cV zQEBqX8w4inpGZMBfGBNgH9kAMF9XbWA+IiUeftgIDi5FhqIlktRZ2T9K1lPIkDsUe2p KEUnVZO2ux2ck0vs25T5Khbmm3klfyRJzyIgnCn0Uofqi8tnM0nzJZHqE4UEBzfa8Ghh FVymf0CFQb6wg8d8YnwtaN0MiyJIzkc5nIwgbwZ+8F4Av70zdv9AFaPb3ylEDriWs2Hx p7+ZDHVSqbkMQ41YYQPJkXV+4CWD3OjGUHHMup5Boatiixj3EZjtflR49VBKUb8pbU6K Hdpw== X-Gm-Message-State: AOJu0YwyDoXT6FtwmS5aNdSxQ2Nt+LXt67Jmz8MvHGZ6Z7xSZeKP3tXB YvjSqw6vBNLnBlFdHy/UvUZtPz+si3L2Mo13+uvdhGXJzkSgykP5 X-Google-Smtp-Source: AGHT+IFEQrZhBM8T+DeRxci0XROcHTplnv/b6ZUuxFUOtUSJIq+cU8fmycOszrb5TMPUF77QkIkzjg== X-Received: by 2002:ac2:55a8:0:b0:510:27a7:cccd with SMTP id y8-20020ac255a8000000b0051027a7cccdmr7129548lfg.2.1706644443488; Tue, 30 Jan 2024 11:54:03 -0800 (PST) Received: from pc636 (host-185-121-47-193.sydskane.nu. [185.121.47.193]) by smtp.gmail.com with ESMTPSA id h5-20020a197005000000b0051120a8eb3fsm148533lfc.10.2024.01.30.11.54.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 11:54:03 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 30 Jan 2024 20:54:00 +0100 To: Lorenzo Stoakes , Kees Cook Cc: Kees Cook , linux-hardening@vger.kernel.org, Andrew Morton , Uladzislau Rezki , Christoph Hellwig , linux-mm@kvack.org, "Gustavo A. R. Silva" , Bill Wendling , Justin Stitt , linux-kernel@vger.kernel.org Subject: Re: [PATCH 33/82] mm/vmalloc: Refactor intentional wrap-around calculation Message-ID: References: <20240122235208.work.748-kees@kernel.org> <20240123002814.1396804-33-keescook@chromium.org> <24526e13-2df6-47ea-865f-b5a5594bc024@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24526e13-2df6-47ea-865f-b5a5594bc024@lucifer.local> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: AF207C000D X-Stat-Signature: hu7qskmxywa1gff3x81oepo1xtnbpch9 X-HE-Tag: 1706644445-972085 X-HE-Meta: U2FsdGVkX184qeP4y1VXswCUD2kr0TdbIxkketGuUX/OAjeGpmPqbKlZDcsgpNhlnUBexe3SEG0u3QZRManiWOcR6ImE9bm5SQhFkoZSJ/6ZwiKx5OnQrJIB8r8YMgJr8c7p26t6YgbervdG5NQrnLZ7NB6d7Uvp3augb9+QIX0LUdF1DErDz8yOv4rLbyxz//kLADuonxU3iqr6ivsU2aFzciJCt9Eg5mRKU8dNW1fU+M6rYhEQevmUKeSOYGjwMCAghdafY7nD5KFo1lCEv0CMLTcu2k2e3e8CXbrj2d7grsEuzLdx5szrUYYDwzbrIdOU9Gyoo4C7umxj+A2XPVj1hAxMFPfxkhklrE5Hv43Dh6oVX2YEUsbgEFMnXRErKkUJK0u8zzkZJmEo1x1ptBjHk1YTpt+dawXx+FU0vuZZCZYDH2sy0xAEshs0FQV669dfeTGtn/v6rpFBYxZBV0T1VlPiDf7kbvFxM2SqcziKn1wfeIyNyHRg2d0UwlsO7d0lb+2JnpCUgfWSRPKIMHYOyEptkZEXQwOL9NROEGkAocm30EZ1v3QJUwINWm0ONNeYLCreSoWFnfg5lXti7DJCkDyKkS4uwIQyw2Iya9sby5DWURkjGwlcwSYuoeA6YOU3SxVXSV5zCbQ+UXszkXipbANVLaeOjWS+UrUX+8jClwRSL1vdBWroyR2eo9gq0r0J2z7COgU/f9GxGe2jFWpRsiMsUOmtnpMgCeJZklt+swWVChquKjhC6NL1YQM5hGPBGUvKMlpEp29SRH8IqSl5Z+xy4CENCdjSoIO9PMztlpZUnY4TiOOE4J00NPgEDHU4AwfXtTiK3THBDbDk1ftyfA2zgyTlgKPBOqhu+g9qkwsiwH3VT9X5Cw+I15Gfy2FjTtCgw8WCG0UIp/17/x6a/6iNoOro/aq4pk95UU5kOeT3HPYeZkqRoaYpu/5tm1ri+E9+ectlEMuVAb2 bIde2mM2 ILS5gKlSFT13NdhWfT7k7jpz5szmFNXAMK4OxlD1l2RSfMSy2Atl53nuiuLv0M163VfVwTkrg/8vlZVBNxwduMWjbOO1injLRevELK6/XmgNJQ1aLuZIrIt/ZQgAlBW9XHMljSfevgAXS1enKrOOOQLe9avJM0k2uIm66R6IG6V2iZLIy3xWpmS6d5fj4qRC3lHvJFABz5XghR7iwN28yj6FWPdf4adOSpZpKQQ1Ist3oCrB5FgW1fSNP2HyAdPBDrsMbjmDUhv7leqgMpivD4xUZFLpCLRWzmjbGnMfqhV5P7ZeGmnOsLUBYf2b2NV3b9nXUgEm3p+imRNq3TeEQ+BdERfTCwikf/xkK1bmTOpfNObuc5CllKrTdlyymPl5wHOPNBLW7Ey9IFFgHDxFHP5AaCCpqkK4jbVFs2QphVWgfemLqSgZnuctj8J3SN7PD8NY8WFPsSRJv/6dIoO824hqGWIy1jfNMzCYK18h+E069twUZMTTbJAsx5WjTLM+GEeIlGpWxslenZmZj5nEgRwDSfPcskH9KCvU0hQEwx2ofCzG1p7YRXniHAoKVbFss/A6EvK7BZqnVDdrcMJRadtxUIpAeax1Td5BD2WcrCn78vpVfeUOcRSeLOSKgeF7DSCIWBsRePif2E37EPrr6tGGTAjx0arQlezItjuYSPvKNcaYDgNewE7ZM9vbpeZQu86BbjRQbIBf0bsh8YGgFY9dfsTME+ogOwAR9L8Vw14XiUFA= 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 Tue, Jan 30, 2024 at 06:55:57PM +0000, Lorenzo Stoakes wrote: > On Mon, Jan 22, 2024 at 04:27:08PM -0800, Kees Cook wrote: > > In an effort to separate intentional arithmetic wrap-around from > > unexpected wrap-around, we need to refactor places that depend on this > > kind of math. One of the most common code patterns of this is: > > > > VAR + value < VAR > > > > Notably, this is considered "undefined behavior" for signed and pointer > > types, which the kernel works around by using the -fno-strict-overflow > > option in the build[1] (which used to just be -fwrapv). Regardless, we > > want to get the kernel source to the position where we can meaningfully > > instrument arithmetic wrap-around conditions and catch them when they > > are unexpected, regardless of whether they are signed[2], unsigned[3], > > or pointer[4] types. > > > > Refactor open-coded unsigned wrap-around addition test to use > > check_add_overflow(), retaining the result for later usage (which removes > > the redundant open-coded addition). This paves the way to enabling the > > unsigned wrap-around sanitizer[2] in the future. > > > > Link: https://git.kernel.org/linus/68df3755e383e6fecf2354a67b08f92f18536594 [1] > > Link: https://github.com/KSPP/linux/issues/26 [2] > > Link: https://github.com/KSPP/linux/issues/27 [3] > > Link: https://github.com/KSPP/linux/issues/344 [4] > > Cc: Andrew Morton > > Cc: Uladzislau Rezki > > Cc: Christoph Hellwig > > Cc: Lorenzo Stoakes > > Cc: linux-mm@kvack.org > > Signed-off-by: Kees Cook > > --- > > mm/vmalloc.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index d12a17fc0c17..7932ac99e9d3 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -1223,6 +1223,7 @@ is_within_this_va(struct vmap_area *va, unsigned long size, > > unsigned long align, unsigned long vstart) > > { > > unsigned long nva_start_addr; > > + unsigned long sum; > > > > if (va->va_start > vstart) > > nva_start_addr = ALIGN(va->va_start, align); > > @@ -1230,11 +1231,11 @@ is_within_this_va(struct vmap_area *va, unsigned long size, > > nva_start_addr = ALIGN(vstart, align); > > > > /* Can be overflowed due to big size or alignment. */ > > - if (nva_start_addr + size < nva_start_addr || > > + if (check_add_overflow(nva_start_addr, size, &sum) || > > nva_start_addr < vstart) > > return false; > > > > - return (nva_start_addr + size <= va->va_end); > > + return (sum <= va->va_end); > > } > > > > /* > > -- > > 2.34.1 > > > > Looks good to me, > > Reviewed-by: Lorenzo Stoakes > Same here. One small nit though. The "sum" variable is not something that it suits for. IMO, we should use a better name and replace it: "nva_offset"? -- Uladzislau Rezki