Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp574561ybh; Wed, 11 Mar 2020 06:44:15 -0700 (PDT) X-Google-Smtp-Source: ADFU+vubilKwLW97UJNgqlb3/0eQzOanPFzvU9Frb/3mc7r0SlDtbVnFjROx2RwoPqCKFUArw5Aj X-Received: by 2002:aca:ea46:: with SMTP id i67mr1911522oih.149.1583934255636; Wed, 11 Mar 2020 06:44:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583934255; cv=none; d=google.com; s=arc-20160816; b=Mc9Rf5V4liaPV8VKCBqzwAqw6ERswjB996s36Rbz//rrYfOvODPU/bbIT3OeXTpFK6 hAK3oBttyaxR2bgnBMbDz2fUs9LWa0UB10C7kgySjWFhwN0BzzHgb+zdxlTfIGKJBxzm LFE7PyXZc2+el5D6Vt8IxgKRREWdPuGNPHKsNmPC0PqEpWZnagqa+LPD/4PzCDsAqHAD PK7n1VLw7lZtTb6/ELA2QKn34M1eOIB64QTz2GFkF7WrraLAj4QVcvkCJCKyspUFBHds 3N3GZkofW4+OowIcOwekoH216m6yUpDNUhWTDeoPpQd/a5mZloKNxkFDvGCsz9dg+Cqv aHMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=6s04QnXTo1jua31jhS4vhoVg7f+fRODAwSWKaGf2RHs=; b=s2jOmf5XrA6YGK1R0+Bp+m5+NAlqCZBf3GRM598VoML1RceyTd6mE2dth/oSbN7IT+ 0uSv9xn7ILw5sp2Ndd4u9GpSoCIIMS3MgX6y407N24ZChTwAhnz+cfAz3Z0jM76oxiyV aip/gdLXeL9gpJ1UNw5HHotvJD10bx2UqZ+OiX3fR6cnUoifrvNhj0tqSRDWZwqzDEpP 2G67n7ZGyo+scrrdVVaXMNCmngGWIijVPpzHzM2yuoj5yaGnJeWQJez//1W3+tsKuItb GZrJ0eFQ2L0LQzyxDpGhtSZ3yYOxbFUk8JhncLc/kBJeltLVm/FjtUgdz8deKUokrrei NumA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=TplORw08; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e7si1175610otp.110.2020.03.11.06.44.04; Wed, 11 Mar 2020 06:44:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=TplORw08; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729649AbgCKNnW (ORCPT + 99 others); Wed, 11 Mar 2020 09:43:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:60896 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729626AbgCKNnU (ORCPT ); Wed, 11 Mar 2020 09:43:20 -0400 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C22C521D7E for ; Wed, 11 Mar 2020 13:43:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583934200; bh=gNzZd+j72gePWmbyxah3BW9W182jo3x0E2sGNNtTIc8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=TplORw08IqFWEgK3AnZIOyXQ7pqWteCCPUhtZF32ONA3cQBZIRwmYQcMS2kPsP5F7 yKp8kUhNml4BXCmsY3bm4T4H0meLn4aQH4nueJ80/1pwl2ZWzi24+Vxkspm6epxMn6 fi7SaKFkrez7zS+x1Zxe0t2dFZdCe7jVJ2DRitn8= Received: by mail-wm1-f51.google.com with SMTP id e26so2177661wme.5 for ; Wed, 11 Mar 2020 06:43:19 -0700 (PDT) X-Gm-Message-State: ANhLgQ0JbtL6sLjRdKFUdbbSn3PPoRY4zLCi6w4AXAbEXQjoo/bh6/KF JSSY0a85XUC5sVz96UOi4uXItF+S4qLf/V1gEdOU7w== X-Received: by 2002:a05:600c:24b:: with SMTP id 11mr3844796wmj.1.1583934198087; Wed, 11 Mar 2020 06:43:18 -0700 (PDT) MIME-Version: 1.0 References: <20200310124530.808338541@linuxfoundation.org> <20200310124535.409134291@linuxfoundation.org> <20200311130106.GB7285@duo.ucw.cz> <20200311131311.GA3858095@kroah.com> <20200311132845.GA24349@duo.ucw.cz> In-Reply-To: <20200311132845.GA24349@duo.ucw.cz> From: Ard Biesheuvel Date: Wed, 11 Mar 2020 09:43:06 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4.19 84/86] efi/x86: Handle by-ref arguments covering multiple pages in mixed mode To: Pavel Machek Cc: Greg Kroah-Hartman , Linux Kernel Mailing List , stable , Ingo Molnar , linux-efi , Thomas Gleixner Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 11 Mar 2020 at 09:28, Pavel Machek wrote: > > On Wed 2020-03-11 14:13:11, Greg Kroah-Hartman wrote: > > On Wed, Mar 11, 2020 at 02:01:07PM +0100, Pavel Machek wrote: > > > 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? > > > > For some crazy reason you cut out the reason I applied this patch to the > > stable tree. From the changelog text: > > Fixes: f6697df36bdf0bf7 ("x86/efi: Prevent mixed mode boot > >corruption with CONFIG_VMAP_STACK=y") > > I did not notice that, but reviewing f669 does not really help. If > there is some known code that passes unaligned (but guaranteed > not-to-cross-page) buffers here, then yes, but is it? Having > not-page-crossing guarantees is kind of hard without alignment. > > People seem to be adding Fixes: tags even if it is not a bugfix, just > as reminder that this has relation to some other commit... > If you read the commit log until the end, you will find a paragraph that describes how the old code warns about, but then ignores the error condition, and proceeds in a way that may cause data corruption. Also, on x86, the stack alignment is only 8 bytes, so with the introduction of vmapped stacks, most guarantees about alignment of objects in the vmalloc space went out the window, potentially triggering this condition in unanticipated ways. It is not very constructive to comment on 'what people seem to be doing' if you have no clue what the context of the change is. Opinions are welcome but informed ones are preferred. > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany