From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id B001FD8108F for ; Wed, 18 Oct 2023 13:13:33 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=Hoaff3uFPOgA+r2ihwYoeTvxJLDAMw5Mg9f+DYkU48M=; c=relaxed/simple; d=groups.io; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition; s=20140610; t=1697634812; v=1; b=iTBeJSjNpDTqVC9GzSc8+YE/WdJ25/vVzymDZ7myWfoZI0j65HSnSwRbr+1ujqRWyMsUf416 G4YiM+fWHm/v16HzRP9BXiaFLh8+eYRouu2zNzXX0KNYsrP6K6jPYNp6xWVL2KhNSKy9KlXemqp e8XUYZR4JhWuA56yQmsF2Kcc= X-Received: by 127.0.0.2 with SMTP id bncTYY7687511xZ5PvinrBp8; Wed, 18 Oct 2023 06:13:32 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web10.281298.1697634811827899866 for ; Wed, 18 Oct 2023 06:13:32 -0700 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-635-s7okjohcOxGh80tzvHaD9w-1; Wed, 18 Oct 2023 09:13:27 -0400 X-MC-Unique: s7okjohcOxGh80tzvHaD9w-1 X-Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4A832381BE92; Wed, 18 Oct 2023 13:13:27 +0000 (UTC) X-Received: from sirius.home.kraxel.org (unknown [10.39.192.243]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EBB4C20268C8; Wed, 18 Oct 2023 13:13:26 +0000 (UTC) X-Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 6C4FC18000A6; Wed, 18 Oct 2023 15:13:25 +0200 (CEST) Date: Wed, 18 Oct 2023 15:13:25 +0200 From: "Gerd Hoffmann" To: Laszlo Ersek Cc: devel@edk2.groups.io, Jordan Justen , Ard Biesheuvel , Oliver Steffen , Jiewen Yao Subject: Re: [edk2-devel] [PATCH 1/1] OvmfPkg/VirtioFsDxe: fix SimpleFileOpen Message-ID: References: <20231018103328.91093-1-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: Yn9MFujCzTrng1J6kKmsynGpx7686176AA= Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=iTBeJSjN; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none) Hi, > > - if (!VirtioFsFile->IsDirectory) { > > + if (!VirtioFsFile->IsDirectory && FileName[0] != '\\') { > It's nice to see this topic pop up on edk2-devel; apparently you started > testing shim on top of virtio-fs. :) Indeed. For starters just passed the host /boot/efi into the guest to see how far it goes. Amazingly ranking virtiofs first in bootorder JustWorks[tm]. Next was shim trapping into this when trying to read BOOTX64.CSV (i.e. probably it actually was fallback.efi) and a boot loop. > > strictly since the beginning, and a few months ago I reported USWG Mantis > > ticket #2367 [1] too, for clearing up the related confusion in the UEFI > > spec. I have to admit I didn't check the what the spec says yet. Looking ... Hmm, EFI_FILE_PROTOCOL.Open() description says "This would typically be an open handle to a directory". I don't read that as "MUST be a directory". With an absolute path the only thing we need from the Handle passed in is the reference to the Filesystem root, the actual file/directory is not needed, so accepting anything and not only directories makes sense to me. And most existing implementations apparently agree, otherwise we would see much more fallout from this. Updating the spec to clearly document expected behavior in that corner case would be good. > (2) With this modification in place, shim is happy, but grub isn't. When > I realized that, I looked relatively deeply into making grub work on top > of virtio-fs as well -- and my findings were horrendous. > > I wrote up my findings in a private email to some colleagues; you were > among the recipients. Yes, I remember. Didn't try anything in grub yet. It boots to the grub shell prompt, but there is no kernel on the host ESP anyway. And no real grub.cfg either, only a stub pointing to the real grub.cfg on a different filesystem. But, yes, that is probably a dead end. IIRC grub completely ignores the efi filesystem drivers and uses its own exclusively (using its own interfaces, not registering them in efi). Trying to fix that opens the can of worms where you can have both grub and efi filesystem drivers being active and stomping on each others feet. > If you have a use case where you rely on shim but *not* on Grub > (UKIs?), then I'm OK relaxing the strictness of VirtioFsDxe. No concrete plans yet. There are ideas/plans to allow booting container images as VM. In that case the root fileystem would be virtiofs, and given that OVMF has a driver it IMHO makes sense to use that to boot the system. And, yes, using UKIs for that makes sense, although the exact workflow is far from being clear. I think one possible option would be to simply have an /EFI subdirectory on the root filesystem, place the files you would have on the ESP there, so the rootfs becomes EFI-bootable. No need to have a boot filesystem or directory, given that EFI can read the complete filesystem anyway you can slurp the UKIs directly from /lib/modules/$kernel/vmlinuz-virt.efi. > In that case, I'd prefer upstreaming my above patch, from April, > rather than taking yours. What do you think about that? Fine with me. The UEFI spec is not clear and I don't feel like bikeshedding whenever shim behavior is a bug or not. Once the UEFI spec has been fixed the one way or other we can revisit this. > Here's a further (independent) caveat: if you are using VirtioFsDxe with > the rust language virtiofsd, then you might experience hangs in > VirtioFsInit. For fixing that, you need the following *qemu* patch set: > > [PATCH v3 0/7] vhost-user: call VHOST_USER_SET_VRING_ENABLE synchronously > https://patchew.org/QEMU/20231002203221.17241-1-lersek@redhat.com/ > > (This patch set has been on qemu-devel for nearly 2 months now, counting > from v1; I'm going to ping MST again. It's been ready for merging for > weeks now!) Good to know, I think I tapped into this when I tried to pass the complete host filesystem into the guest. IIRC mst tends to do large pulls in large intervals, I wouldn't worry too much yet. Pinging doesn't hurt though. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#109746): https://edk2.groups.io/g/devel/message/109746 Mute This Topic: https://groups.io/mt/102036263/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-