Specify that the .sbat section is ASCII not UTF-8 #413
Conversation
The SBAT variable is defined as ASCII, but the SBAT section in a binary was defined as UTF-8. These should match. Use ASCII rather than UTF-8, because naive parsing of UTF-8 could lead to unexpected results. For example the character 'ä' can be encoded as 0xe4 or as 0x61 0x0308, and these should be considered equivalent. The shim is not smart enough to do this. This could lead to missed verifications, if the variable and section use different encodings. Define everything as ASCII. It's sad not to be able to have 🦀 in our bootloader names, and potentially annoying for vendor names as well, but oh well.
|
I don't think that's really necessary, UTF-8 is fine outside the component name, it's not used for verification purposes. But why are they not UCS-2 encoded like everything else anyway? |
That's something I asked a while back.myself. It's easier for us to work with UTF-8 generally, but... |
Making the SBAT variable be ASCII (or UTF-8) makes the data considerably smaller where it really matters, and I'd rather not have to compare mixed encodings. |
The SBAT variable is defined as ASCII, but the SBAT section in a binary was defined as UTF-8. These should match.
Use ASCII rather than UTF-8, because naive parsing of UTF-8 could lead to unexpected results. For example the character 'ä' can be encoded as 0xe4 or as 0x61 0x0308, and these should be considered equivalent. The shim is not smart enough to do this. This could lead to missed verifications, if the variable and section use different encodings.
Define everything as ASCII. It's sad not to be able to have 🦀 in our bootloader names, and potentially annoying for vendor names as well, but oh well.