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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16177C18E5A for ; Wed, 11 Mar 2020 13:01:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ECB5E2082E for ; Wed, 11 Mar 2020 13:01:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729495AbgCKNBK (ORCPT ); Wed, 11 Mar 2020 09:01:10 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:50772 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729358AbgCKNBJ (ORCPT ); Wed, 11 Mar 2020 09:01:09 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 836551C0317; Wed, 11 Mar 2020 14:01:07 +0100 (CET) Date: Wed, 11 Mar 2020 14:01:07 +0100 From: Pavel Machek To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Ard Biesheuvel , Ingo Molnar , linux-efi@vger.kernel.org, Thomas Gleixner Subject: Re: [PATCH 4.19 84/86] efi/x86: Handle by-ref arguments covering multiple pages in mixed mode Message-ID: <20200311130106.GB7285@duo.ucw.cz> References: <20200310124530.808338541@linuxfoundation.org> <20200310124535.409134291@linuxfoundation.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kXdP64Ggrk/fb43R" Content-Disposition: inline In-Reply-To: <20200310124535.409134291@linuxfoundation.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > Currently, the mixed mode runtime service wrappers require that all by-ref > arguments that live in the vmalloc space have a size that is a power of 2, > and are aligned to that same value. While this is a sensible way to > construct an object that is guaranteed not to cross a page boundary, it is > overly strict when it comes to checking whether a given object violates > this requirement, as we can simply take the physical address of the first > and the last byte, and verify that they point into the same physical > page. Dunno. If start passing buffers that _sometime_ cross page boundaries, we'll get hard to debug failures. Maybe original code is better buecause it catches problems earlier? Furthermore, all existing code should pass aligned, 2^n size buffers, so we should not need this in stable? > --- a/arch/x86/platform/efi/efi_64.c > +++ b/arch/x86/platform/efi/efi_64.c > @@ -321,16 +321,13 @@ virt_to_phys_or_null_size(void *va, unsi > if (virt_addr_valid(va)) > return virt_to_phys(va); > =20 > - /* > - * A fully aligned variable on the stack is guaranteed not to > - * cross a page bounary. Try to catch strings on the stack by > - * checking that 'size' is a power of two. > - */ > - bad_size =3D size > PAGE_SIZE || !is_power_of_2(size); > + pa =3D slow_virt_to_phys(va); > =20 > - WARN_ON(!IS_ALIGNED((unsigned long)va, size) || bad_size); > + /* check if the object crosses a page boundary */ > + if (WARN_ON((pa ^ (pa + size - 1)) & PAGE_MASK)) > + return 0; We don't really need to do this computation on pa, it would work on va as well, right? It does not matter much, but old code worked that way. Plus, strictly speaking, pa + size can overflow for huge sizes, and test will return false negatives. Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCXmjhEgAKCRAw5/Bqldv6 8mj+AJ9SlIdfv4wT11lvQQHCHbshsYOwEACgjkW9w1shhVkmNA2Mt7K1kXdu+/w= =b2DV -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R--