According to UEFI spec,for ACPI Expanded Device Path
when HID=PNP0A03 or CID=PNP0A03 and HID != PNP0A08,
the device path node can be displayed as: PciRoot(UID|UIDSTR)
When HID=PNP0A08 or CID=PNP0A08, the device path node can be
displayed as: PcieRoot(UID|UIDSTR). But current code miss the
code logic.
This commit is to do the enhancement.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1228
Obtained from: 78af0984b4
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
According to UEFI Spec, for ACPI Expanded Device Path,
when HIDSTR=empty, CIDSTR=empty, UID STR!=empty,
the ACPI Expanded Device Path node can be displayed as
AcpiExp(HID,CID,UIDSTR) format.
And if UID is 0 and UIDSTR is empty, then use AcpiEx format.
This patch is to correct the condition check to follow UEFI
Spec when convert the device path node to the AcpiExp text
format.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1226
Obtained from: fb4bea551e
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
1. Do not use tab characters
2. No trailing white space in one line
3. All files must end with CRLF
Adapted according to FreeBSD-update instructions, with the sole purpose
of reducing the differences with upstream sources.
Obtained from: 9095d37b8f
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
Per UEFI spec, iSCSI.Lun is a 8-byte array with byte #0 in the left.
It means "0102030405060708" should be converted to:
UINT8[8] = {01, 02, 03, 04, 05, 06, 07, 08}
or UINT64 = {0807060504030201}
Today's implementation wrongly uses the reversed order.
Obtained from: d0196be1e3
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
For the following two functions:
DevPathFromTextBluetooth()
DevPathToTextBluetooth()
The Bluetooth device address "UINT8 Address[6]" is displayed with the
order from Address[5] to Address[0]. This commit reverses the order.
Obtained from: 4fc8277133
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
For current iSCSI protocol parsing, UINT16 truncation may be happened. Since
the Spec already have declaimed that 0 is TCP Protocol and 1+ is reserved, the
parsing can be refined as below:
if (StrCmp (ProtocolStr, L"TCP") == 0) {
ISCSIDevPath->NetworkProtocol = 0;
} else {
//
// Undefined and reserved.
//
ISCSIDevPath->NetworkProtocol = 1;
}
Obtained from: 7571a1c191
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
UefiDevicePathLibConvertTextToDevicePath correctly detects when it
has hit a ',' splicing together multiple paths. However, the code
that tries to cope with it:
{code}
if (IsInstanceEnd) {
DeviceNode = (EFI_DEVICE_PATH_PROTOCOL *) AllocatePool (
END_DEVICE_PATH_LENGTH);
ASSERT (DeviceNode != NULL);
SetDevicePathEndNode (DeviceNode);
NewDevicePath = AppendDevicePathNode (DevicePath, DeviceNode);
FreePool (DevicePath);
FreePool (DeviceNode);
DevicePath = NewDevicePath;
}
{code}
causes a problem. The END node that's appended it the node for the
entire list. So when the node is appended in AppendDevicePathNode,
it winds up disappearing. This leads to the path
'PciRoot(0x0),PciRoot(0x0)' parsing as if 'PciRoot(0x0)/PciRoot(0x0)'
were specified. These are two very different things.
NOTE:
This fix was already committed. It has been included with the sole
intention of reducing diffs with upstream.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=419
Obtained from: 647636e175
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
Network interface type should be checked before the conversion between
text device path node and MAC device path. Otherwise, the MAC text string
can't be converted to the representation of a device node, which leads to
the series failure of network HII configuration(e.g. IP, VLAN, HTTP Boot
configuration in Network Device List).
Obtained from: 2d67f2bae3
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
There is no need to set -Wno-unused-parameter twice, and instead of
appending to CFLAGS, append to CWARNFLAGS instead. While here, add
-Wno-unused-but-set-variable for the sake of clang 13.0.0.
MFC after: 3 days
Update a bunch of Makefile.depend files as
a result of adding Makefile.depend.options files
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22494
Use recent best practices for Copyright form at the top of
the license:
1. Remove all the All Rights Reserved clauses on our stuff. Where we
piggybacked others, use a separate line to make things clear.
2. Use "Netflix, Inc." everywhere.
3. Use a single line for the copyright for grep friendliness.
4. Use date ranges in all places for our stuff.
Approved by: Netflix Legal (who gave me the form), adrian@ (pmc files)
- Fix some typos.
- Remove redundant semicolons from the synopsis section.
- Stylize variable names and types with Vt and Va respectively.
- Use a list to present non-implemented functions.
- Sort the order of the sections.
- Add a history section.
- Use Nm when "libefivar" is mentioned.
PR: 232626
Reported by: Tiwei Bie <btw@mail.ustc.edu.cn>
Reviewed by: bcr, imp
Approved by: krion (mentor, implicit), mat (mentor, implicit)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D17686
Document efidev(4), provider of userland access to EFI Runtime Services. A link is created to efirtc(4), which handles the time-of-day clock side.
efirt(9) is the kernel side of this.
Reviewed by: imp, kib (earlier version)
Differential Revision: https://reviews.freebsd.org/D16696
len % 1 is always true. Fix StrHexToBytes to do a proper odd length
check. This was only called by DevPathFromTextGenericPath,
ConvertFromTextVendor and DevPathFromTextMAC, which we've not had
a need to actually use just yet.
Submitted by: David Binderman
PR: 229718
would be filesystem type dependent, but that's difficult to accomplish
and it's unclear how the UEFI firmware will cope. Be conservative and
make boot loaders cope instead.
Sponsored by: Netflix
condition. This should prevent a double free. In addition, prevent a
leak by freeing dp each loop and when we're done.
CID: 1383577
Sponsored by: Netflix
efivar_device_path_to_unix_path translates from UEFI to Unix
efivar_unix_path_to_device_path translates from Unix to UEFI
At present, only HD() device types are supported (both GPT and
MBR). CdRom and floppy devices aren't supported. ZFS isn't supported
because there's no way in the UEFI standard to specify a ZFS datastore.
Network devices aren't supported either.
Three forms of Unix path are accepted: /path/to/file (for a mounted
filesystem), //path/to/file (uses the EFI partition on the same disk
as /), and dev:/path/to/file (for unmounted filesystem). Two forms are
produced (the first and last).
Sponsored by: Netflix
We started out having Linux compatible libefivar interfaces. This was
in anticipation of porting the GPL'd efibootmgr to FreeBSD via a
port. However, since we need that functionality in the base, that port
isn't going to happened. It also appears that efivar is a private
library that's not used much outside a command line util and
efibootmgr. Reduce compatibility with the Linux version a little by
removing the mode parameter to efi_set_variable (which was unused on
FreeBSD, and not set to something useful in the code we'd
written). Also remove some efi error routines that were never
implemented and existed only to placate early GPL efibootmgr porting
experiments.
Suggested by: Matt Williams
Sponsored by: Netflix
Fix allocating more memory for the names (unlikely to be needed, but
still best to get right) to ask for the length the kernel told use we
needed, not the old length of the variable. Mind the proper NUL that
we add in the space we allocate. Free the old name string before we
allcoate a new one to limit what we leak to the last one (free passed
in name for the last one in the list), and detect the last one by rv
!= 0 and errno == ENOENT, rather then just the former to avoid false
positives if errno happens to be ENOENT on entry.
Sponsored by: Netflix
efidp_size will return the size, in bytes, of a EFI device path
structure. This is a convenience wrapper in the same style as the
other linux routines. It's implemented by GetDevicePathSize from EDK2
we already needed for other things.
Sponsored by: Netflix
Avoid dealing with some code that uses type-punned pointers.
See D12210 and D12211 for more background.
Reviewed by: imp
Approved by: markj (mentor)
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12219
o Add File to the mUefiDevicePathLibDevPathFromTextTable table so we
don't include 'File()' in the supposed path name. This happens because
of a possible misfeature in the EDK2 code where any path that's not
recognized is treated as a File() node.
o Convert utf8 input into ucs2 output rather than just copying the
utf8 and hoping for the best (no good comes from that).
o Remove bogus comment about needing to add 1. The dummy array already
is length 1, so that's included in sizeof the struct, so there's no
need to add it.
Sponsored by: Netflix
Device paths encoded into the FILEPATH_DEVICE_PATH are UCS2 not
ASCII/UTF8. Convert to utf8 and print that when printing File
paths. Also, since File may be at the end of a long device path,
output File() around the path so it doesn't just show up as random
nodes that might accidentally match real node paths names and cause
errors.
*** CID 1372598: Null pointer dereferences (FORWARD_NULL)
/lib/libefivar/efivar-dp-parse.c: 3612 in UefiDevicePathLibConvertTextToDeviceNode()
Dereferencing null pointer "FromText".
When ported from Tiano core, I commented this out with an ifdef. That
was in error because we're supposed to fallback to a filepath when
nothing else patches. Instead, restore the original code, but fix
DevPathFromTextFilePath to cope with the conversion to narrow
strings. Also, fix the off-by-one error in the size of the memory it
allocates.
The off by one error is documented in Tiano core bug
https://bugzilla.tianocore.org/show_bug.cgi?id=441
CID: 1372598
Sponsored by: Netflix
Paper over a coverity issue:
*** CID 1372592: API usage errors (BAD_COMPARE)
/lib/libefivar/efivar-dp-parse.c: 2723 in DevPathFromTextiSCSI()
Truncating the result of "strcmp" to "unsigned short" may cause it
to be misinterpreted as 0. Note that "strcmp" may return an integer
besides -1, 0, or 1.
We do this by making StrCmp return either 0 or 1 for equal or
not-equal. There's a bug in the DevPathFromTextiSCSI cast of the
return value and this workaround will fix it without breaking other
users of StrCmp (all of which test for == 0).
https://bugzilla.tianocore.org/show_bug.cgi?id=440 has been filed
upstream to log this issue.
CID: 1372592
Sponsored by: Netflix
This commit implements the (mostly?) Linux compatible
efidp_format_device_path and efidp_parse_device_path APIs. These are
the only APIs exposed through this library. However, they are built on
code from Tianocore's EDK2 MdePkg. They are brought in as new files
here for reasons described in FreeBSD-update.
Symbol versioning will be introduced to control what's exported from
the EDK2 code.
Some structural changes may be necessary when we move to sharing with
sys/boot/efi.
Sponsored by: Netflix
