unexpected behavior with the disk partitioner handler

[Dan Hilgert]

Hi Stefano,

We discovered something unexpected with the disk partitioner handler using SWUpdate v2023.05

• We created an swu image setup as follows:
  
  

• software =

• {

•    version = "1.0";

•    description = "Update Image";

• 
  

•    hardware-compatibility: [ "1.0" ];

• 
  

•    partitions: (

•        {

•            type = "diskpart";

•            device = "/dev/mmcblk0";

•            properties: {

•                    labeltype = "dos";

•                    partition-1 = [ "size=512M", "start=2048", "name=boot", "type=0xC", "flag=boot", "fstype=vfat"];

•            }

•        }

•    );

•    files: (

•        {

•            filename = "BOOT.BIN";

•            path = "/BOOT.BIN";

•            device = "/dev/mmcblk0p1"

•            filesystem = "vfat"

•        }

•    );

• }

• 
  

• Verified newly created filesystem has no errors using dosfsck

• Mounted partition in linux and verified file is present

• Rebooted device and inspected partition while in U-Boot

• I am not able to view any files on the partition using fatls mmc 0:1, however the file is clearly present as the device booted into U-Boot

It appears that the issue has something to do with the way swupdate is creating the FAT file system on the new partition. Ext4 file systems seem to work ok. We also noticed the FAT file system is being created using the fatfs library rather than any native Linux tools like when we run mkfs.

To verify this was a mkfs issue and not partition related, we did the following:

• Ran swupdate with our image creating new partition and filesystem again

• Recreated filesystem manually in Linux

• mkfs.vfat -F 32 -n boot /dev/mmcblk0p1

• Mounted recreated file system and scp BOOT.BIN file into it

• Unmounted file system and rebooted device

• I am now able to see the file on that partition in U-Boot using fatls mmc 0:1

Any insight you can offer into this would be greatly appreciated.

Thanks,

Dan Hilgert | President

Embedded Design Engineering

101 Fairway Dr | Glencoe, MN 55336

Cell: 320-522-0840

www.eemn.io

[Stefano Babic]

Hi Dan,

On 03.11.23 03:08, Dan Hilgert wrote:
> Hi Stefano,
>
> We discovered something unexpected with the disk partitioner handler
> using SWUpdate v2023.05
>

> *

>
> We created an swu image setup as follows:
>

> o
>
> software=
>
> o
>
> {
>
> o
>
> version="1.0";
>
> o
>
> description="Update Image";
>
> o
>
>
> o
>
> hardware-compatibility: [ "1.0"];
>
> o
>
>
> o
>
> partitions: (
>
> o
>
>        {
>
> o
>
> type="diskpart";
>
> o
>
> device="/dev/mmcblk0";
>
> o
>
> properties:{
>
> o
>
> labeltype="dos";
>
> o
>
> partition-1= [ "size=512M", "start=2048", "name=boot",

> "type=0xC", "flag=boot", "fstype=vfat"];
>

> o
>
>            }
>
> o
>
>        }
>
> o
>
>    );
>
> o
>
>    files:(
>
> o
>
>        {
>
> o
>
> filename="BOOT.BIN";
>
> o
>
> path="/BOOT.BIN";
>
> o
>
> device="/dev/mmcblk0p1"
>
> o
>
> filesystem="vfat"
>
> o
>
>        }
>
> o
>
>    );
>
> o
>
> }
>
> o
>
>
> *
>

Ok

> Verified newly created filesystem has no errors using dosfsck
>

Ok

> *

>
> Mounted partition in linux and verified file is present

Ok

>
> *

>
> Rebooted device and inspected partition while in U-Boot
>

> *

>
> I am not able to view any files on the partition using fatls mmc
> 0:1, however the file is clearly present as the device booted into
> U-Boot
>
>
> It appears that the issue has something to do with the way swupdate is
> creating the FAT file system on the new partition.

I am just reading back what you have written, and asking me why we get
to different result. You write:

- FAT was created by SWUpdate
- Filesystem check is ok
- Linux has no issue at all with the filesystem.

Now why the reason should be in SWUpdate and not in U-Boot, and maybe in
the vendor U-Boot because you probably are you using the Vendor's fork
xilinx-uboot instead of U-Boot mainline?

> Ext4 file systems
> seem to work ok. We also noticed the FAT file system is being created
> using the fatfs library rather than any native Linux tools like when we
> run mkfs.

As it should be. Calling external tools is a big security risk. An
attacker can have compromised the shell (or the external tool as well),
and this opens to a range of possible attacks. An Updater must be
self-contained, and then fatfs is used. Code form mkfs.vfat could not be
used due to license incompatibilities (the same happened in U-Boot). But
as Linux has no problem, it does not seems an issue here.

>
>
> To verify this was a mkfs issue and not partition related, we did the
> following:
>

> *

>
> Ran swupdate with our image creating new partition and filesystem again
>

> *

>
> Recreated filesystem manually in Linux
>

> o

>
> mkfs.vfat -F 32 -n boot /dev/mmcblk0p1
>

> *

>
> Mounted recreated file system and scp BOOT.BIN file into it
>

> *

>
> Unmounted file system and rebooted device
>

> *

>
> I am now able to see the file on that partition in U-Boot using
> fatls mmc 0:1

Sure there are some differencies, but it does not mean that the cause is
in SWUpdate and not in U-Boot. You are also saying that board is
booting, and if you have not a copy of BOOT.BIN on a SPI flash as in
many Xilinx's design, the board *really* boots from it. That means the
FAT implementation inside the BootROM can mount the filesystem and read
BOOT.BIN without issue.

So again, whiere should be the cause ?

Best regards,
Stefano Babic

>
>
> Any insight you can offer into this would be greatly appreciated.
>
>
> Thanks,
>

> *Dan Hilgert* | President
> *Embedded Design Engineering*

> 101 Fairway Dr | Glencoe, MN 55336
> Cell: 320-522-0840

> www.eemn.io <http://www.eemn.io>
>
> <https://linkedin.com/in/dan-hilgert-3462b782/>
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/CAO3KV1emuFkCdrCus5rr65%3DEO_7JZAoBd258fMJv8Qjz_o6Mqg%40mail.gmail.com <https://groups.google.com/d/msgid/swupdate/CAO3KV1emuFkCdrCus5rr65%3DEO_7JZAoBd258fMJv8Qjz_o6Mqg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Michael Adler]

Hi Dan,

> I am not able to view any files on the partition using fatls mmc 0:1,
> however the file is clearly present as the device booted into U-Boot

I can answer that: U-Boot's FAT parser has a problem (bug) with partitions
created by SWUpdate's FAT library. This is U-Boot's fault though because the
filesystem created by SWUpdate is indeed spec conform. I am planning to fix
U-Boot's implementation but probably not before December/January (and if
someone else fixes it in the meanwhile I'm not unhappy either ;).

Btw, you've sent an HTML mail to the mailing list. This is hard to read in
mutt.

Kind Regards,
Michael

--
Michael Adler

Siemens AG
Technology
Connectivity & Edge
Smart Embedded Systems
T CED SES-DE
Otto-Hahn-Ring 6
81739 Munich, Germany

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann
Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive
Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese;
Registered offices: Berlin and Munich, Germany; Commercial registries:
Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

[Taedcke, Christian]

Hello Michael,

On 03.11.2023 12:13, 'Michael Adler' via swupdate wrote:
> Hi Dan,
>
>> I am not able to view any files on the partition using fatls mmc 0:1,
>> however the file is clearly present as the device booted into U-Boot
>
> I can answer that: U-Boot's FAT parser has a problem (bug) with partitions
> created by SWUpdate's FAT library. This is U-Boot's fault though because the
> filesystem created by SWUpdate is indeed spec conform. I am planning to fix
> U-Boot's implementation but probably not before December/January (and if
> someone else fixes it in the meanwhile I'm not unhappy either ;).

I have just successfully tested some initial prototype code to fix fat
fs type detection in u-boot according to
http://elm-chan.org/docs/fat_e.html#fat_determination

I plan to send a patch to the U-Boot mailing list in November.

>
> Btw, you've sent an HTML mail to the mailing list. This is hard to read in
> mutt.
>
> Kind Regards,
> Michael
>

Regards,
Christian

[Michael Adler]

Hi Christian,

> I have just successfully tested some initial prototype code to fix fat fs
> type detection in u-boot according to
> http://elm-chan.org/docs/fat_e.html#fat_determination
>
> I plan to send a patch to the U-Boot mailing list in November.

that's great news, thanks for the notice! FWIW, Siemens' efibootguard suffered
from the same issues as U-Boot and I fixed it in August this year [1]. Feel
free to draw some inspiration if you like (it's essentially the same code as
the Linux kernel uses).

Kind Regards,
Michael

[1] https://github.com/siemens/efibootguard/blob/master/tools/fat.c

[Taedcke, Christian]

Hello Michael,

On 06.11.2023 11:04, Michael Adler wrote:
> Hi Christian,
>
>> I have just successfully tested some initial prototype code to fix fat fs
>> type detection in u-boot according to
>> http://elm-chan.org/docs/fat_e.html#fat_determination
>>
>> I plan to send a patch to the U-Boot mailing list in November.

I sent an initial patch series for u-boot, see [1].

>
> that's great news, thanks for the notice! FWIW, Siemens' efibootguard suffered
> from the same issues as U-Boot and I fixed it in August this year [1]. Feel
> free to draw some inspiration if you like (it's essentially the same code as
> the Linux kernel uses).

Great, thanks for the link. I reworked my patch a little bit to use the
same algorithm as the Linux kernel (and efibootguard).

>
> Kind Regards,
> Michael
>
> [1] https://github.com/siemens/efibootguard/blob/master/tools/fat.c
>

Regards,
Christian

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=381309