linux-kernel - Re: Cache coherency bug: stale reads on /dev/sda1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9ee5affc-54b3-4b27-9311-4ed3bb73afc9@suse.de>
Date:   Wed, 6 Sep 2023 09:42:27 +0200
From:   Hannes Reinecke <hare@...e.de>
To:     Joshua Hudson <joshudson@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>
Cc:     Bagas Sanjaya <bagasdotme@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux IDE and libata <linux-ide@...r.kernel.org>,
        Hans de Goede <hdegoede@...hat.com>,
        Jens Axboe <axboe@...nel.dk>,
        Damien Le Moal <dlemoal@...nel.org>,
        OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Subject: Re: Cache coherency bug: stale reads on /dev/sda1

On 8/27/23 20:33, Joshua Hudson wrote:
> On Sun, Aug 27, 2023 at 9:30 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>>
>> On Sun, Aug 27, 2023 at 07:39:03AM -0700, Joshua Hudson wrote:
>>> Offset 0x1C into the FAT filesystem is defined as "Count of hidden
>>> sectors preceding
>>> the partition that contains this FAT volume." It's been there since
>>> DOS 3.0. The Linux
>>> Kernel does not care what's in this field, but I have tools that have
>>> a hard time of it
>>> not being there. One example of a tool is BootDuet.
>>>
>>> The rationale is to reduce the number of tools that have to walk the
>>> partition table, the
>>> most obvious one being the boot sector itself which doesn't have room.
>>
>> ???
>>
>> That makes no sense whatsoever; "boot sector" here is the first sector
>> of _partition_, not that of the entire disk (that would be MBR).
>>
>> To quote the same wikipedia,
>> ----
>> A volume boot record (VBR) (also known as a volume boot sector,
>> a partition boot record or a partition boot sector) is a type of boot
>> sector introduced by the IBM Personal Computer. It may be found on a
>> partitioned data storage device, such as a hard disk, or an unpartitioned
>> device, such as a floppy disk, and contains machine code for bootstrapping
>> programs (usually, but not necessarily, operating systems) stored in other
>> parts of the device. On non-partitioned storage devices, it is the first
>> sector of the device. On partitioned devices, it is the first sector of
>> an individual partition on the device, with the first sector of the entire
>> device being a Master Boot Record (MBR) containing the partition table.
>> ----
>>
>> So your rationale doesn't work - you need to know where the partition is
>> just to read the sector that contains that field.  Or have access to
>> something that can be asked to read from partition, as opposed to the
>> entire disk (kernel, for example), but that something can usually be
>> asked where the hell does partition start.
> 
> The MBR doesn't look at the BPB. It looks at the first four bytes of the
> partition table entry, loads that sector (which is the VBR), and jumps to
> it. In the late 90s it became a thing to pass DL all the way through to
> enable booting from ZIP disks, but nothing else is passed from the MBR
> to the VBR. Thus, the BPB is in the VBR and describes the filesystem
> and knows its own offset (otherwise the disk would not boot).
> 
> https://github.com/FDOS/kernel/blob/132a0a9f94d23f13c90319bb0e0232a5f33164d8/boot/boot.asm#L203
> 
> Almost everybody depended on this exact behavior for dual booting. Each
> OS was defined in the boot menu as a path to a 512 byte file, which was
> that OS's boot sector. They don't access disk relative to their own position,
> but rather what their position should be.
> 
> So what I did: unmounted /boot/efi, started a virtual machine with /dev/sda
> as the disk, booted a different OS than the host OS, shut it down, and got
> very confused when changes to /boot/efi via the guest OS were not reflected
> in the host OS.
> 
>>
>> On anything with UEFI the first sector of the entire disk is likely to be
>> the "protective MBR" in the beginning of GPT.
>>
> 
> # dd if=/dev/sda bs=c skip=446 count=66 | hexdump -C
> 00000000  00 00 02 00 ee ff ff ff  01 00 00 00 af 88 e0 e8  |....îÿÿÿ....¯.àè|
> 00000010  80 20 21 00 06 df 13 0c  00 08 00 00 00 20 03 00  |. !..ß....... ..|
> 00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 00000040  55 aa                                             |Uª|
> 00000042
> 
> I wouldn't be too sure of that. And yes, the second line corresponds
> exactly to the EFI partition's entry in GPT.

Weelll ... if you already know that there's something in the FAT 
documentation which isn't implemented in Linux, why are you surprised 
that things don't work if you modify it?
And if you know that tools are relying on that specific field, why not 
implement support for that feature in linux?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@...e.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman