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 2992BC433EF for ; Fri, 25 Mar 2022 07:51:23 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 670108413F; Fri, 25 Mar 2022 08:51:21 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.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=gmail.com header.i=@gmail.com header.b="We/dLFfc"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id AF77E8414A; Fri, 25 Mar 2022 08:51:18 +0100 (CET) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 A6C898413A for ; Fri, 25 Mar 2022 08:51:15 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=bmeng.cn@gmail.com Received: by mail-yb1-xb2e.google.com with SMTP id v35so12632197ybi.10 for ; Fri, 25 Mar 2022 00:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZHFaI50gzZCoPdHwhCR6ucOvkmIyPpQhJuylnaFYgrg=; b=We/dLFfcoIhM+rwXMHU/bwbdNzDnbNJdb0a66HkO/sqnYRpMOdzEa9g4Fi3qVx8nKX zonBvJjvzjbgm32pvokMOiLJWctln4mecz0cNSPEGpIc3llq8ab8jL6x2Z0t013j8lM7 +wL6NQpqkMx+3GmwafQu4CBNwQL2pmCvdhSWUMevguTL33VRDDEOdk5pJPdJyEoSewbZ SC9Re75JYPfQ0mzxogFaQ5cX6xFrXIvS0jRonVNqJyUsmw80+72cuOzryO9D4b9IJByu i9FLcGKqENkqptjga/T5lwd4Mef21x2gkEdU65d5K6IN6Atwq+ZKGiV9JyjOuYOIkRMh pxxQ== 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=ZHFaI50gzZCoPdHwhCR6ucOvkmIyPpQhJuylnaFYgrg=; b=UB8ceig9XiIeDabkIV7zItN7pmh0NP0UkiKHM+ZWqe1dd381QaHriTmq6fHw637WoE 80GdMnWUlOgt8vgLD9SvHun95BHmFMLvWt0F9YH943c/zuPHP9WJgYtx4MhAnuhBkc0C P2tdiaPxh2QU/VTMVAUaoYuKUeW4GwcE7SzsjU1B4xvbAZwCWccREyFyQ8NlGag+ZT9T PYxxtcMO5szOedURANJfBJrZj1eYTQibowgEfGguq+uY1YUXjJR3paYk7D8UYnHWlX6R wIwJqcllVMHK7JVgnWagY3mHNTxcf/9bci/bkNQBKUJ5frVpZMEGF2BRCRfcCqlBIeRZ 1o0A== X-Gm-Message-State: AOAM530CD+jTCPJrRMQCOXoazN2JbAofu75jSTQ7cf2TEOSNKr5XUruz XD2fGPX0QPkKHnrDBntmLtBW8T2RCFFMnVqEHs0= X-Google-Smtp-Source: ABdhPJyA8vnYarSAveiMg8BmkqRNNxNkg9Isr7sFkFJ1wo1dj0ghrg3w9ryvzJnRUu3p3yX4a7EPasercMXzaxZajdU= X-Received: by 2002:a25:b41:0:b0:633:c68f:4b3 with SMTP id 62-20020a250b41000000b00633c68f04b3mr8205758ybl.643.1648194674566; Fri, 25 Mar 2022 00:51:14 -0700 (PDT) MIME-Version: 1.0 References: <20220320114118.2237795-1-ascull@google.com> <20220320114118.2237795-7-ascull@google.com> In-Reply-To: From: Bin Meng Date: Fri, 25 Mar 2022 15:51:03 +0800 Message-ID: Subject: Re: [PATCH 06/11] virtio: pci: Read entire capability into memory To: Andrew Scull 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, 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? Regards, Bin