Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File device paths: don't print "File(" or ")" #232

Merged
merged 5 commits into from
Sep 27, 2022

Conversation

vathpela
Copy link
Contributor

@vathpela vathpela commented Sep 27, 2022

ardb poked me about a few efivar device path issues:

  • File device paths are printed wrong
  • IPv4 device paths are printed wrong
  • IPv6 device paths are printed wrong

ardb poked me and said:

<ardb> pjones: were you aware that EDK2 does not actually use File() for
       EFIDP_MEDIA_FILE device path nodes?
<ardb> e.g.,  parsing the following using the text-to-device-path
       protocol
<ardb> HD(1,GPT,400774eb-3297-4c12-906a-f913b4c4de18,0x800,0x100000)/File(\EFI\debian\grubaa64.efi)
<ardb> results in a filename in the  EFIDP_MEDIA_FILE device node that
       includes the characters that make up File( and )

I checked in the spec, and all it has to say about it is in the examples
of printing a DP section, which says:

 +------------------------------+-----------------------------+
 | Type: 4 (Media Device Path)  | String                      |
 | SubType: 4 (File Path)String | The String is the file path |
 |                              | and is a string.            |
 +------------------------------+-----------------------------+

I've seen little evidence of anything ever using the output of efivar
with the EFI Text to Device Path protocol, so I don't think it's a
problem to make the output here consistent with the spec's big
inconsistency.

This patch removes the "File(" and ")" text from the output.

Signed-off-by: Peter Jones <pjones@redhat.com>
format() takes a device path type to print in the error output.
Unfortunately, in several cases format_ipv6_addr_helper() passes in the
/string/ "dp_type" instead of the dp_type that's passed in, which makes
the error output thoroughly useless.

This patch passes through the data instead.

Signed-off-by: Peter Jones <pjones@redhat.com>
IPv6 addresses are supposed to append the port if it's nonzero, but
we've accidentally checked for >= 0, which is all possible values.

This patch fixes the check to be > 0.

Signed-off-by: Peter Jones <pjones@redhat.com>
Unfortunately, the ipv6 address device path type has gateway_ip6_addr
defined as a uint8_t rather than 16 of them.

This patch fixes it to be an array.  While this is theoretically ABI
breaking, it'll only affect things that take a sizeof() on that field or
incorrectly take a sizeof() on the struct, both of which are bad to do
in any case, as anything iterating device paths or taking the size of
the path node should be using the size field in the header.

Signed-off-by: Peter Jones <pjones@redhat.com>
ardb poked me saying:
<ardb> pjones: now that you're fixing stuff:
<ardb> MAC(00001a1bb328,1)/IPv4(0.0.0.00.0.0.0,0,0)

Lo and behold, that is indeed wrong and bad.  This patch fixes it, and
takes the liberty of making the IPv6 formatting also match the spec,
with the caveat that the spec says the last field in IPv6() is a
netmask, but all the examples show the prefix length, which is the field
we actually have in the struct.

Before:
Boot0007* UEFI HTTPv4 (MAC:525400CA2EE0)	MAC(525400ca2ee0,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()
Boot0008* UEFI HTTPv6 (MAC:525400CA2EE0)	MAC(525400ca2ee0,1)/IPv6([::]:<->[::]:,0,0)/Uri()

After:
Boot0007* UEFI HTTPv4 (MAC:525400CA2EE0)	MAC(525400ca2ee0,1)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri()
Boot0008* UEFI HTTPv6 (MAC:525400CA2EE0)	MAC(525400ca2ee0,1)/IPv6([::],0,Static,[::],[::],64)/Uri()

Signed-off-by: Peter Jones <pjones@redhat.com>
@frozencemetery frozencemetery merged commit dd901c1 into rhboot:main Sep 27, 2022
@vathpela vathpela deleted the file-dp-text branch September 27, 2022 21:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants