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 92C7B9415D2 for ; Fri, 29 Sep 2023 09:48:03 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=OQzYVrkl3ctUhC71TY06R+6GLyMGufll+ddPSSpIv54=; c=relaxed/simple; d=groups.io; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20140610; t=1695980882; v=1; b=daBB+vKfDZAGeOcaTJ0Vpr/cjAiyAxQvTYCp1tzNJOAyai3ZzIIB7icyUhaofGrmPcqGqJmX IoUe6RghrtRvnEcauig2tdlVjfySdUY7JxwhHZaOaO9oGtae3auV+LA9orzusZlwkvKyEbYQ63G ZNWiajyNMXjivePOgtwTyiLE= X-Received: by 127.0.0.2 with SMTP id dJ4uYY7687511xGhM0eF52BV; Fri, 29 Sep 2023 02:48:02 -0700 X-Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by mx.groups.io with SMTP id smtpd.web11.13773.1695980881171651004 for ; Fri, 29 Sep 2023 02:48:01 -0700 X-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 6F627240104 for ; Fri, 29 Sep 2023 11:47:58 +0200 (CEST) X-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Rxlrr6wnmz6v0q; Fri, 29 Sep 2023 11:47:56 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\)) Subject: Re: [edk2-devel] efi and ext4 and case sensitive file names From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= In-Reply-To: Date: Fri, 29 Sep 2023 09:47:46 +0000 Cc: Gerd Hoffmann , edk2-devel-groups-io , Laszlo Ersek Message-Id: <944EB976-23EA-4921-AAF4-23435772C65A@posteo.de> References: <6odzwzflo4id7ra3cphgk3rhfpr7iqojsfqkbu4tutapcyhk2v@njifptgxmw5n> To: Pedro Falcato 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,mhaeuser@posteo.de List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 1rsJRI0UPqE02AkMYpdcoxtHx7686176AA= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=daBB+vKf; dmarc=fail reason="SPF not aligned (strict), DKIM not aligned (strict)" header.from=posteo.de (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io > On Sep 28, 2023, at 19:57, Pedro Falcato wrote: >=20 > On Wed, Sep 27, 2023 at 1:09=E2=80=AFPM Gerd Hoffmann = wrote: >>=20 >> Hi, >>=20 >> I've noticed that the edk2 ext4 driver does case-insensitive filename >> matching. I know the fat filesystem is case-insensitive, and the uefi >> spec describing the fat filesystem also explicitly says it is >> case-insensitive. On a quick scan I can't find anything in the uefi >> spec requiring *all* filesystem drivers being case-insensitive though. >>=20 >> So I'm wondering whenever the ext4 driver behavior is correct. It >> certainly is different than the linux kernel's behavior which is (by >> default) case-sensitive. Maybe when Linux starts adhering the spec for file names (the spec clearly = defines e.g. BOOTx64.EFI, while at least some distros/images use bootx64.ef= i), this can be discussed. :) Let's not break various GRUB setups... >=20 > Ok, so this is a funny problem. When I was originally writing it, I > noticed a good few consumers would expect case insensitiveness, so I > ended up needing case insensitive string comparison. >=20 > As an example, in my current system: > Boot0001* ARCHLINUX > HD(1,GPT,7e1b2e20-3013-4683-b8ab-bef1f9bfb1c8,0x800,0x32000)/File(\EFI\AR= CHLINUX\GRUBX64.EFI) > whereas the GRUB tooling installed itself as: > /boot/efi/EFI/ARCHLINUX/grubx64.efi >=20 > I treated some good bits of the filesystem driver as "should remain > similar to FAT" due to compatibility reasons. Definitely must keep it that way. I think true user-facing case-sensitivity= is mostly a Linux thing, even recent macOS APFS is still only case-preserv= ing (UX-wise). There certainly is no real use-case for UEFI itself beyond t= hings like Linux interoperability. > I really really wouldn't > be surprised if lots of EFI code out there relied on case > insensitiveness or other FAT-ish stuff, instead of UNIX semantics. > (funnily enough, EFI also has the restriction where every filename > must be valid unicode, which is not the case on most UNIX systems out > there, that take the file name as "bag of bytes - '/'") >=20 >>=20 >> Also note that the linux kernel ext4 driver recently got support for >> case-insensitive file names, which must be explicitly enabled for both >> filesystems (EXT4_FEATURE_INCOMPAT_CASEFOLD) and directories >> (EXT4_CASEFOLD_FL). >=20 > Ugh, this is annoying, they didn't even bother documenting it... > (https://www.kernel.org/doc/html/latest/filesystems/ext4/globals.html#sup= er-incompat) > This leaves me in the awkward spot where figuring the behavior out > would require me to read the fs/ext4 code and thus be legally dubious, > yay :^) All hail GPL... >=20 >>=20 >> On practical terms I've ran into actual problems due to Fedora mounting >> the ESP at /boot/efi[1] and UKIs (unified kernel images) should be >> placed in EFI/Linux on either ESP or XBOOTLDR partition, which on fedora >> translates to /boot/efi/EFI/Linux (ESP) or /boot/EFI/Linux (XBOOTLDR). >> So I have both /boot/efi and /boot/EFI ... >=20 > Oh boy, that seems fun. So Ext4Dxe can only open one of the two dirs, rig= ht? > Now that I think of it, there should be fun behavior when doing an EFI > readdir, where you could find two dirents with "different" names but > then opening both will lead to the same dirent being open twice... > yuck Yes, but this often is not a concern due to case-preservation. There also i= sn't much of a "right or wrong", as supporting case-insensitivity here coul= d change the semantics of existing desync'd sensitivity setups. However, ca= se-insensitivity would at least be more predictable. The only real options are: 1) We assume the host OS understands that UEFI is inherently case-sensitive= and doesn't do weird things, then the current behaviour makes sense. It's = efficient, doesn't touch unnecessary data, but it's not so predictable. 2) We assume the host OS understands this, but we consider this a risk to s= ecurity. Then it might make sense to reject FSes that feature this. Obvious= ly Secure Boot and such should be taking care of only invoking trusted bina= ries, but someone might be trying to invoke ambiguous FS driver behaviour b= ecause they are aware of an exploit vector. Nevertheless, this seems unnece= ssary and overkill, also it doesn't fix the broken UX. It will actually com= pletely break that Linux use-case, which might be a bug or a feature. :) Bu= t it's predictable! 3) We assume the host OS does not do its job, but we are being nice anyway.= Then it might make sense to have opportunistic case-sensitivity, where equ= ality is preferred, but insensitive-equality is used as a fallback. This fi= xes the issue when the OS is at least consistent in its insensitivity-viola= tion. However, as Pedro showed an example of a desync'd device path and FS = name, there is yet another loophole to (accidentally) abuse the ambiguity. = Not even some obviously crazy stuff like ranking by editing distances can s= ave you here. And it's also limited in predictability when there is no exac= t match. I don't think any option is particularly nice, but 1) is the easiest. :) Best regards, Marvin >=20 > --=20 > Pedro -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#109190): https://edk2.groups.io/g/devel/message/109190 Mute This Topic: https://groups.io/mt/101615699/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-