From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE2F1313293 for ; Sun, 29 Mar 2026 17:51:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774806720; cv=none; b=byl6qDwKMhZf2Om5QrCXcdT9veLN3F02Yb4hZxNLVEonEBRtNwGj597bJom6X6Q3bTG8Ok6yeanfkrSOQsJwLRTB8pO9EAfdrdUtcoyciL1PV+sCLH7RXrrEznZsAfr3chg59hExzdxUNrLPXOq8tlB41WVxg3cOjcdHEHw2Jug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774806720; c=relaxed/simple; bh=2e+M2+2Bg9MqmfrQeh6rX+OFqRZkGEQinf9Q5RZUktU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MXgOvc0kJFewv+Qy/7YVY3fOzMNeQ09T5FIm34lTNQGOdpJ7kzqTcWynXHoUjYw/5ii8JNli/zAnRjQFhXZHC0zqtG5ZIlWCMUPDVc6kNKZBcYp2mNQsDGT+z2oa6GfDwg+FPFQ0mnpK6XGa1NvA195C97mxXG+o/gO6a+GFVbs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=Yd2ZMgJH; arc=none smtp.client-ip=209.85.222.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="Yd2ZMgJH" Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-8cfbfdabf3fso377279385a.3 for ; Sun, 29 Mar 2026 10:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1774806718; x=1775411518; darn=vger.kernel.org; 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=CGnGKhV5zb489dStMiQgEbxuhffvfA5BGbsg9GGuJkc=; b=Yd2ZMgJH2HgbyoJ2TkfgP48RWQ8JCSfijAv2zBbG/AJSnXuSpUZ2DINkfNEP/s6p11 A9bOm/681oEpyptP/uKpd9LoB+Ipl7XbQ5QSvUJ7QkWjW82TQiTRwgheNvFrpNUG/wKN jPDEm6wIRCtt/p3I7J1wNGEae4vPlsi6hAa0WDdwHu9cHBllpdnCvChxfnh6RHuXG+ND laOOdN754XBzArmq9UcvIMJ36JAfkVH8V5MIjfKjElbEufGUni6DuijDJoBvI59QQy3k 9W+2rV6TBCylbzWCOPyvbzkGSf+hiYD8JCbWo7z0jLyT1KBmHkh3OzzHJzhjxfCDdBNp Um1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774806718; x=1775411518; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CGnGKhV5zb489dStMiQgEbxuhffvfA5BGbsg9GGuJkc=; b=tLL/Err06lN20XU0q5k/gS0VwshEpvGGv+rE3uLUdoE/jqi1qVc86ux/LomEh2dGJh 7ExwINPqWwSF2i2NA1RX5w3Oughs4sBmJht80cdHEnROtveoftKh2nLmIAteMLECwUjD Nk/gA8Ibbz+fs4VMuIENXDCgDt8ie1HvhKloP/k/6v5BeBAM+rWGDRTjpQ6QCjLnTOEG LglIgesZyp7PbFw71/g2jEd0Yj3gDvd42cN08ifNtohwkJLG2fUFImwjWGCBvQ3QD0qT Yyr50hhYfi8KCxh/tdXzCHyx9Uebj1Q/p0WjYQhDyAUneJIldaUxYwlMt8iHxQa17Adb S1gQ== X-Forwarded-Encrypted: i=1; AJvYcCX5BQOXYvL1XaFNv/JtMaazEbFKgAHSwRZ6nF0+aXYEv1mrGMd8s8PVmd4WTOv2swdDSLK2tiOF2drIPTQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzmQYbDa4zvhBWlmfqBQIfQER25gf2tUIBTQ77xfd7IzENEsK+x QoAAIZOpuBletuimzFuOYWYxwSTGzSHnDsGx/1Et/XkJcQEbM0ob7R00KLvYz2YAscU= X-Gm-Gg: ATEYQzxZehvGeTzX7KhG2VS4UTczt/V6ZGL3kPsEvFVkpku6WNTJo7Vh8Nl4Mfr+qt+ UZ2vHuTgcLBRDlbgmjWA7c9+4f7VAVPYurKjrr3xIZOrNra0nBnEy2Jy0/U2QAgjdPinTwYXnWu EcDzw19rIqyUIaVA2SnEo4VyIpd0tCNRkfLfc6p2DYv1VspUFFFTjOB8+sApQiwDcdIjtox2lzi RtmKel9tWK41JGhFOOOAGBRc402SNFJoI8ok33ePorVsU5iL21ccZbE21FP0o218NlemfbdGhqE 0UNmrnDYxDVGDOJ6uiLsvbYFEGHVvek4TtDrsnS0e94+cQx8MbFJY1ZBq6jbJvAofS9Z15ECwyD 63kITcVhRFA8deAenIGKyFZqtqJbjWqevX16ByQIk2Z7LffY+EDCbBQhKrER1XDbeWd/wDcOC9C A+ODli/q48xbFqksRLQADSnJElYC7bDECocXdXPb4kL2zEb4NiQvA1R0epBF5hPbtOMWR6KbZ4t yRikgc= X-Received: by 2002:a05:620a:4145:b0:8cf:e32e:89dc with SMTP id af79cd13be357-8d01c314588mr1318827285a.0.1774806717634; Sun, 29 Mar 2026 10:51:57 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-173-79-68-72.washdc.fios.verizon.net. [173.79.68.72]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8d02806a37bsm407108985a.34.2026.03.29.10.51.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 Mar 2026 10:51:56 -0700 (PDT) Date: Sun, 29 Mar 2026 13:51:54 -0400 From: Gregory Price To: Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, Ard Biesheuvel , Dave Young , Usama Arif , Jiri Slaby , Breno Leitao Subject: Re: [PATCH 1/5] efi/memattr: Fix thinko in table size sanity check Message-ID: References: <20260326132655.1733873-7-ardb+git@google.com> <20260326132655.1733873-8-ardb+git@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260326132655.1733873-8-ardb+git@google.com> On Thu, Mar 26, 2026 at 02:26:57PM +0100, Ard Biesheuvel wrote: > From: Ard Biesheuvel > > While it is true that each PE/COFF runtime driver in memory can > generally be split into 3 different regions (the header, the code/rodata > region and the data/bss region), each with different permissions, it > does not mean that 3x the size of the memory map is a suitable upper > bound. This is due to the fact that all runtime drivers could be > coalesced into a single EFI runtime code region by the firmware, and if > the firmware does a good job of keeping the fragmentation down, it is > conceivable that the memory attributes table has more entries than the > EFI memory map itself. > > So instead, base the sanity check on whether the descriptor size matches > the EFI memory map's descriptor size (which is not mandated by the spec > but extremely unlikely to differ in practice), and whether the size of > the whole table does not exceed 2 MiB. > > Signed-off-by: Ard Biesheuvel The 2MB limit is a bit odd to me - but then i don't see a legitimate reason to need 50k+ entries here unless the system is doing something absolutely nutty - it would mean a wildly fragmented system and most likely an indicator of a bug rather than a legitimately intended configuration. Otherwise, this does seem like a better check regardless. Reviewed-by: Gregory Price