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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7BCC4C433FE for ; Mon, 28 Mar 2022 14:28:45 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5322383C07; Mon, 28 Mar 2022 16:28:43 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.b="VX27wtQ9"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A36B083C09; Mon, 28 Mar 2022 16:28:41 +0200 (CEST) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 76F5583B8A for ; Mon, 28 Mar 2022 16:28:38 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ascull@google.com Received: by mail-qv1-xf33.google.com with SMTP id k7so11932586qvc.4 for ; Mon, 28 Mar 2022 07:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q6tavZnGqLeXcs3l8oMYPyVcBNP/EOfwI2Abh+AN8tk=; b=VX27wtQ9Bcox9BduScdFpQwo0jB1hD0QyheaVyxg8kSyy22OshIvuPNu3jtoyJiv2G hW50/J06TDMTBI21I0X9hp+HVuIqeM+5L7Vhpcf1u/Wl1LhhInYJsQBpCw0n7DKQGeFh AT73kbpyXzxuvzfnNxKQBvGuP+ncs0RlkkVAtpJv3zy2wExsVThFeiORAXA9BZdg/lo0 2Xhe7xJlylmOtCn3HV/tIeztd5cArRJ2ibCB8FIPaWbA7eDdijYaQizTR9qZCpHK6/bb +is71WkFP9HL3iisTyL8cV7gY2ygABDA7qzuTygkAG/1utjqHYAukBF61Wm4EGREARv2 UiJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q6tavZnGqLeXcs3l8oMYPyVcBNP/EOfwI2Abh+AN8tk=; b=YaV2ptQEbgeJ998zTfYfTIJXo3aMuejl5yfY+z2l/NZ8aIQPmorEUPbIWEkxfeMgcs 2proEMxgnR2MOkEv0hCbWOuVKXuAF/NQXzG7FIoP9EBHMj1QAptyVS+GmEFQlznzmXdN 0frvjKPn78idoOGX6d54HphMntYy/recRJ9pwgNvuoHltkTAcPLbFBXnMKNRki9muuIb 27QVsUgA+eSw0J9tx7ja1H5oY1k7Vi72fpYnAiVTyDoirhqYmOrdQWiQQZln2oHKBLsj 3emC4s/yqPu15JGbON3RdxidUF9uG8073zXqoq2Yw8m2a689S6xyxXZ5wQP1RAVVtOoz jMSQ== X-Gm-Message-State: AOAM5317Dj7Z7ZcEj1Wwzf8WpmcTSVP9/nWMtD4odGKiC40wsYnilKRT UEJx3xD8tmSQ/6cMGSZg5Qn1G4hiigI0wobn8VPDQg== X-Google-Smtp-Source: ABdhPJxiX8Dq0WCdyd85xnH+JFIECqJKrtaA3a/sOkt6Oxw5hCMWrf7HLAP9RBtmpWYLwCUTa+yU9jNSOIV+zTBR4RI= X-Received: by 2002:a05:6214:4119:b0:441:9eb:d4ba with SMTP id kc25-20020a056214411900b0044109ebd4bamr21388066qvb.54.1648477717126; Mon, 28 Mar 2022 07:28:37 -0700 (PDT) MIME-Version: 1.0 References: <20220320114118.2237795-1-ascull@google.com> <20220320114118.2237795-7-ascull@google.com> In-Reply-To: From: Andrew Scull Date: Mon, 28 Mar 2022 14:28:26 +0000 Message-ID: Subject: Re: [PATCH 06/11] virtio: pci: Read entire capability into memory To: Bin Meng Cc: U-Boot Mailing List , Simon Glass , Alistair Delva , Keir Fraser , =?UTF-8?Q?Pierre=2DCl=C3=A9ment_Tosi?= Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean On Fri, 25 Mar 2022 at 10:26, Bin Meng wrote: > > On Fri, Mar 25, 2022 at 5:18 PM Andrew Scull wrote: > > > > On Fri, 25 Mar 2022 at 07:51, Bin Meng wrote: > > > > > > On Fri, Mar 25, 2022 at 3:03 PM Andrew Scull wrote: > > > > > > > > On Fri, 25 Mar 2022 at 04:31, Bin Meng wrote: > > > > > > > > > > On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > > > > > > > > > > > Read the virtio PCI capability out of the device configuration space to > > > > > > a struct rather than accessing fields directly from the configuration > > > > > > space as they are needed. This both makes access to the fields easier > > > > > > and avoids re-reading fields. > > > > > > > > > > > > Re-reading fields could result in time-of-check to time-of-use problems, > > > > > > should the value in the configuration space change. The range check of > > > > > > the `bar` field and the later call to `dm_pci_read_bar32()` is an > > > > > > example of where this could happen. > > > > > > > > > > I don't see the need to avoid the time-of-check to time-of-use > > > > > problems, as it can only happen with the PCI configuration access > > > > > capability, which U-Boot driver does not touch. > > > > > > > > > > Am I missing something? > > > > > > > > U-Boot doesn't touch the configuration space but the device could > > > > have, whether that be accidently or maliciously. Linux has taken > > > > similar precautions [1] to add more safety checks and I'll be looking > > > > to do the same in other parts of the u-boot virtio drivers. > > > > > > > > [1] -- https://lwn.net/Articles/865216 > > > > > > > > > > Got it. So basically the problem is that we don't trust the host that > > > implements the virtio device :) > > > > > > I am curious that under such a guideline, probably lots of device > > > drivers need to be enhanced to do the sanity check, no? > > > > Absolutely, they do! My focus is going to be primarily on the modern > > PCI driver, vring and block driver. This will lay a foundation for the > > others but they will also need to be checked over carefully before > > being relied on. > > Do you know if the Linux kernel has a plan to apply such a guideline > to some other drivers than virtio, like usb or nvme? There are devices > that can do bad things too so we should not trust them? I don't know about those other subsystems, but I do know that virtio has made assumptions about the other side being necessarily trusted and that those assumptions are being broken by new applications, which is leading to things being reworked.