source code, document behavior

[orangecms]

Please provide the source code for and document the header that the tools generate.
The VisionFive 2 is advertised as open source, and here, sources are missing.

Here is what I have reverse engineered. Given a file with the following contents:

$ echo toaster > toaster
$ xxd toaster
00000000: 746f 6173 7465 720a                      toaster.

This is the output of ./create_sbl toaster 1234 (toaster.normal.out):

$ hexdump toaster.normal.out
0000000 0240 0000 0000 0020 0000 0000 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
*
0000280 0000 0000 04d2 0000 0008 0000 0400 0000
0000290 f685 1a81 0000 0000 0000 0000 0000 0000
00002a0 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400 6f74 7361 6574 0a72
0000408

Note: all entries are little endian

The first two bytes seem to be fixed; I've run the tool over a few other files: 0240. Same for the 0020 at 0x007.

Then come many more zero-bytes.

The 04d2 0000 (at 0x0284) is the hex representation of the version passed, 1234. I noticed that passing longer numbers gets truncated and only the lowest 32 bits (4 bytes) are preserved.

The 0008 0000 appears to be the file size in bytes.

The 0400 0000 seems to be fixed.

The f685 1a81 is the CRC32 checksum of the file.

At 0x0400, the actual file starts.

[MichaelZhuxx]

It is not open source for now since this is related to security boot

[orangecms]

It is not open source for now since this is related to security boot

If it's for security, then it needs to be open. Obscurity is proven not to work.
Anyone could reverse the binaries; it just takes a bit of time. I can do that now, too. However, it would be great for your reputation to publish your own sources. Security requires trust and auditability after all, which is enabled by openness. Thank you.

[rpx99]

What does security boot mean?
A verification that nothing was changed before allowing to boot?

[orangecms]

What does security boot mean? A verification that nothing was changed before allowing to boot?

There is no clear definition of "Secure Boot" besides that of the UEFI Forum, which is their view and mostly marketing.

For reference, see also:
https://github.com/tpm2dev/tpm.dev.tutorials/blob/master/Boot-with-TPM/README.md#verified-vs-measured-boot
https://igor-blue.github.io/2021/02/04/secure-boot.html

However, the generic term as a loose concept includes the following:

• verified boot: only boot if hashes match, signatures are valid, policies are fulfilled, etc; see Intel BootGuard for comparison
• measured boot: the boot chain is accompanied by measurements - think hashing - in every stage, and the OS may read them back for checking, some agent (service) may report them to a remote party, etc; the evaluation is called local/remote attestation, respectively

The key point is to build up a trust chain, similar to the hierarchical PKI you may know from HTTPS, and so you end up with a root, which is then called RTM, Root of Trust for Measurement, categorized into DRTM (dynamic) and SRTM (static). Static RTM is implemented e.g. with keys fused into the hardware. Look for "efuse" in SoC documentation.

[strlcat]

Please provide the source code for and document the header that the tools generate. The VisionFive 2 is advertised as open source, and here, sources are missing.

Here is what I have reverse engineered. Given a file with the following contents:

$ echo toaster > toaster
$ xxd toaster
00000000: 746f 6173 7465 720a                      toaster.

This is the output of ./create_sbl toaster 1234 (toaster.normal.out):

$ hexdump toaster.normal.out
0000000 0240 0000 0000 0020 0000 0000 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
*
0000280 0000 0000 04d2 0000 0008 0000 0400 0000
0000290 f685 1a81 0000 0000 0000 0000 0000 0000
00002a0 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400 6f74 7361 6574 0a72
0000408

Note: all entries are little endian

The first two bytes seem to be fixed; I've run the tool over a few other files: 0240. Same for the 0020 at 0x007.

Then come many more zero-bytes.

The 04d2 0000 (at 0x0284) is the hex representation of the version passed, 1234. I noticed that passing longer numbers gets truncated and only the lowest 32 bits (4 bytes) are preserved.

The 0008 0000 appears to be the file size in bytes.

The 0400 0000 seems to be fixed.

The f685 1a81 is the CRC32 checksum of the file.

At 0x0400, the actual file starts.

Hi,
Based on your description I quickly coded a program which does this conversion, check it out: https://github.com/electrorys/jh7110_uboot_spl
It produced exactly same image byte-to-byte as I have in my /dev/mtd0ro on my VF2 board for an U-Boot SPL image located in it at offset 0x400.
Feel free to open an issue if something goes wrong.
UPD: it worked fine for me.

[MichaelZhuxx]

we will refactor the code and open source it soon. thank you all of your comments and suggestion.

[strlcat]

This issue can be now closed thanks to StarFive team upstreamed my code and extended it. <3

[orangecms]

Thank you so much! I'm already using this now, works just fine :)