summaryrefslogtreecommitdiffstats
path: root/src/include
Commit message (Collapse)AuthorAgeFilesLines
...
* [build] Return const char * from uuid_ntoa()David Decotigny2017-01-221-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Remove queue size limit in legacy virtioLadi Prosek2017-01-222-4/+4
| | | | | | | | | | | | | | | | Virtio 0.9 implementation was limited to the maximum virtqueue size of MAX_QUEUE_NUM and the virtio-net driver would fail to initialize on hosts exceeding this limit. This commit lifts the restriction by allocating the queue memory based on the actual queue size instead of using a fixed maximum. Note that virtio 1.0 still uses the MAX_QUEUE_NUM constant to cap the size (unfortunately this functionality is not available in virtio 0.9). Signed-off-by: Ladi Prosek <lprosek@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Cap queue size to MAX_QUEUE_NUMLadi Prosek2017-01-221-3/+3
| | | | | | | | | | | | | | | vpm_find_vqs incorrectly accepted the host provided queue size with no regard to iPXE's internal limitations. Virtio 1.0 makes it possible for the driver to override the queue size to reduce memory requirements and iPXE is a great use case for this feature. Also removing the extra vq->vring.num assignment which is already handled in vring_init. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Work around temporal anomaly encountered during ExitBootServices()Michael Brown2016-12-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | EFI provides no clean way for device drivers to shut down in preparation for handover to a booted operating system. The platform firmware simply doesn't bother to call the drivers' Stop() methods. Instead, drivers must register an EVT_SIGNAL_EXIT_BOOT_SERVICES event to be signalled when ExitBootServices() is called, and clean up without any reference to the EFI driver model. Unfortunately, all timers silently stop working when ExitBootServices() is called. Even more unfortunately, and for no discernible reason, this happens before any EVT_SIGNAL_EXIT_BOOT_SERVICES events are signalled. The net effect of this entertaining design choice is that any timeout loops on the shutdown path (e.g. for gracefully closing outstanding TCP connections) may wait indefinitely. There is no way to report failure from currticks(), since the API lazily assumes that the host system continues to travel through time in the usual direction. Work around EFI's violation of this assumption by falling back to a simple free-running monotonic counter. Debugged-by: Maor Dickman <maord@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add basic EFI SAN booting capabilityMichael Brown2016-11-173-0/+29
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [interface] Provide intf_reinit() to reinitialise nullified interfacesMichael Brown2016-11-161-0/+18
| | | | | | | Provide an abstraction intf_reinit() to restore the descriptor of a previously nullified interface. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add EFI_BLOCK_IO2_PROTOCOL header and GUID definitionMichael Brown2016-10-172-0/+209
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2016-10-1615-46/+401
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Mark AppleNetBoot.h as a native iPXE headerMichael Brown2016-10-161-3/+3
| | | | | | | | | AppleNetBoot.h is not taken from the EDK2 codebase and so cannot be imported using include/ipxe/efi/import.pl. Mark as a native iPXE header (by changing the include guard) to avoid breaking the import process. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cmdline] Add certificate management commandsMichael Brown2016-08-311-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add certstat() to display basic certificate informationMichael Brown2016-08-311-0/+16
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow certificates to be marked as having been added explicitlyMichael Brown2016-08-311-0/+4
| | | | | | | | Allow certificates to be marked as having been added explicitly at run time. Such certificates will not be discarded via the certificate store cache discarder. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Expose certstore_del() to explicitly remove stored certificatesMichael Brown2016-08-311-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [list] Add list_next_entry() and list_prev_entry()Michael Brown2016-08-311-0/+28
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Generalise X.509 "valid" field to a "flags" fieldMichael Brown2016-08-251-3/+18
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add image_x509() to extract X.509 certificates from imageMichael Brown2016-08-251-0/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pixbuf] Enable PNG format by defaultMichael Brown2016-07-291-0/+1
| | | | | | | Enable IMAGE_PNG (but not IMAGE_PNM) by default, and drag in the relevant objects only when image_pixbuf() is present in the binary. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add PEM image formatMichael Brown2016-07-292-0/+23
| | | | | | | | | | | Add PEM-encoded ASN.1 as an image format. We accept as PEM any image containing a line starting with a "-----BEGIN" boundary marker. We allow for PEM files containing multiple ASN.1 objects, such as a certificate chain produced by concatenating individual certificate files. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add DER image formatMichael Brown2016-07-292-0/+17
| | | | | | | | Add DER-encoded ASN.1 as an image format. There is no fixed signature for DER files. We treat an image as DER if it comprises a single valid SEQUENCE object covering the entire length of the image. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Add image_asn1() to extract ASN.1 objects from imageMichael Brown2016-07-291-0/+16
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow for parsing of partial ASN.1 cursorsMichael Brown2016-07-281-0/+2
| | | | | | | | | Allow code to create a partial ASN.1 cursor containing only the type and length bytes, so that asn1_start() may be used to determine the length of a large ASN.1 blob without first allocating memory to hold the entire blob. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Remove obsolete extern declaration for asn1_invalidate_cursor()Michael Brown2016-07-281-1/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [hyperv] Use instance UUID in device nameMichael Brown2016-07-261-1/+1
| | | | | | | | | | The Windows drivers for VMBus devices are enumerated using the instance UUID rather than the channel number. Include the instance UUID within the iPXE device name to allow an iPXE network device to be more easily associated with the corresponding Windows network device when debugging. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Allow for multiple routersMichael Brown2016-07-252-2/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Select the IPv6 source address and corresponding router (if any) using a very simplified version of the algorithm from RFC6724: - Ignore any source address that has a smaller scope than the destination address. For example, do not use a link-local source address when sending to a global destination address. - If we have a source address which is on the same link as the destination address, then use that source address. - If we are left with multiple possible source addresses, then choose the address with the smallest scope. For example, if we are sending to a site-local destination address and we have both a global source address and a site-local source address, then use the site-local source address. - If we are still left with multiple possible source addresses, then choose the address with the longest matching prefix. For the purposes of this algorithm, we treat RFC4193 Unique Local Addresses as having organisation-local scope. Since we use only link-local scope for our multicast transmissions, this approximation should remain valid in all practical situations. Originally-implemented-by: Thomas Bächler <thomas@archlinux.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Rename ipv6_scope to ipv6_settings_scopeMichael Brown2016-07-211-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Create routing table based on IPv6 settingsMichael Brown2016-07-201-4/+6
| | | | | | | | | | | | | | | | | | | | | | Use the IPv6 settings to construct the routing table, in a matter analogous to the construction of the IPv4 routing table. This allows for manual assignment of IPv6 addresses via e.g. set net0/ip6 2001:ba8:0:1d4::6950:5845 set net0/len6 64 set net0/gateway6 fe80::226:bff:fedd:d3c0 The prefix length ("len6") may be omitted, in which case a default prefix length of 64 will be assumed. Multiple IPv6 addresses may be assigned manually by implicitly creating child settings blocks. For example: set net0/ip6 2001:ba8:0:1d4::6950:5845 set net0.ula/ip6 fda4:2496:e992::6950:5845 Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Match user expectations for IPv6 settings prioritiesMichael Brown2016-07-191-0/+12
| | | | | | | | | | | | | | A reasonable user expectation is that ${net0/ip6} should show the "highest-priority" of the IPv6 addresses, even when multiple IPv6 addresses are active. The expected order of priority is likely to be manually-assigned addresses first, then stateful DHCPv6 addresses, then SLAAC addresses, and lastly link-local addresses. Using ${priority} to enforce an ordering is undesirable since that would affect the priority assigned to each of the net<N> blocks as a whole, so use the sibling ordering capability instead. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Allow settings blocks to specify a sibling orderingMichael Brown2016-07-191-0/+2
| | | | | | | Allow settings blocks to provide an explicit default ordering between siblings, with lower precedence than the existing ${priority} setting. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Expose IPv6 link-local address settingsMichael Brown2016-07-191-0/+3
| | | | | | Originally-implemented-by: Hannes Reinecke <hare@suse.de> Originally-implemented-by: Marin Hannache <git@mareo.fr> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Expose IPv6 settings acquired through NDPMichael Brown2016-07-191-0/+9
| | | | | | | | | Expose the IPv6 address (or prefix) as ${ip6}, the prefix length as ${len6}, and the router address as ${gateway6}. Originally-implemented-by: Hannes Reinecke <hare@suse.de> Originally-implemented-by: Marin Hannache <git@mareo.fr> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Rename ipv6_scope to dhcpv6_scopeMichael Brown2016-07-161-1/+1
| | | | | | | | The settings scope ipv6_scope refers specifically to IPv6 settings that have a corresponding DHCPv6 option. Rename to dhcpv6_scope to more accurately reflect this purpose. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Create space for IPv6 in settings display orderMichael Brown2016-07-151-16/+20
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Add support for ACPI power offMichael Brown2016-07-111-0/+75
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Install the HII config access protocol on a child of the SNP handleLaszlo Ersek2016-07-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In edk2, there are several drivers that associate HII forms (and corresponding config access protocol instances) with each individual network device. (In this context, "network device" means the EFI handle on which the SNP protocol is installed, and on which the device path ending with the MAC() node is installed also.) Such edk2 drivers are, for example: Ip4Dxe, HttpBootDxe, VlanConfigDxe. In UEFI, any given handle can carry at most one instance of a specific protocol (see e.g. the specification of the InstallProtocolInterface() boot service). This implies that the class of drivers mentioned above can't install their EFI_HII_CONFIG_ACCESS_PROTOCOL instances on the SNP handle directly -- they would conflict with each other. Accordingly, each of those edk2 drivers creates a "private" child handle under the SNP handle, and installs its config access protocol (and corresponding HII package list) on its child handle. The device path for the child handle is traditionally derived by appending a Hardware Vendor Device Path node after the MAC() node. The VenHw() nodes in question consist of a GUID (by definition), and no trailing data (by choice). The purpose of these VenHw() nodes is only that all the child nodes can be uniquely identified by device path. At the moment iPXE does not follow this pattern. It doesn't run into a conflict when it installs its EFI_HII_CONFIG_ACCESS_PROTOCOL directly on the SNP handle, but that's only because iPXE is the sole driver not following the pattern. This behavior seems risky (one might call it a "latent bug"); better align iPXE with the edk2 custom. Cc: Michael Brown <mcb30@ipxe.org> Cc: Gary Lin <glin@suse.com> Cc: Ladi Prosek <lprosek@redhat.com> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/13494/focus=13532 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ladi Prosek <lprosek@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [profile] Allow profiling to be globally enabled or disabledMichael Brown2016-07-051-0/+2
| | | | | | | | | | As with assertions, profiling is enabled for objects built with any debug level (including an explicit debug level of zero). Allow profiling to be globally enabled or disabled by adding PROFILE=1 or PROFILE=0 respectively to the build command line. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Allow assertions to be globally enabled or disabledMichael Brown2016-07-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | Assertions are enabled for objects built with any debug level (including an explicit debug level of zero). It is sometimes useful to be able to enable assertions across all objects; this currently requires manually hacking include/assert.h. Allow assertions to be globally enabled by adding ASSERT=1 to the build command line. For example: make bin/8086100e.mrom ASSERT=1 Similarly, allow assertions to be globally disabled by adding ASSERT=0 to the build command line. If no ASSERT=... is specified on the build command line, then only objects mentioned in DEBUG=... will have assertions enabled (as is currently the case). Note than globally enabling assertions imposes a relatively heavy runtime penalty, primarily due to the various sanity checks performed by list_add(), list_for_each_entry(), etc. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [debug] Allow debug messages to be initially disabled at runtimeMichael Brown2016-07-051-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the DEBUG=... syntax to allow debug messages to be compiled in but disabled by default. For example: make bin/undionly.kpxe DEBUG=netdevice:3:1 would compile in the messages as for DEBUG=netdevice:3, but would set the debug level mask so that only the DEBUG=netdevice:1 messages would be displayed. This allows for external code to selectively enable the additional debug messages at runtime, without being overwhelmed by unwanted initial noise. For example, a developer of a new protocol may want to temporarily enable tracing of all packets received: this can be done by building with DEBUG=netdevice:3:1 and using // temporarily enable per-packet messages DBG_ENABLE_OBJECT ( netdevice, DBGLVL_EXTRA ); ... // disable per-packet messages DBG_DISABLE_OBJECT ( netdevice, DBGLVL_EXTRA ); Note that unlike the usual DBG_ENABLE() and DBG_DISABLE() macros, DBG_ENABLE_OBJECT() and DBG_DISABLE_OBJECT() will not be removed via dead code elimination if debugging is disabled in the specified object. In particular, this means that using either of these macros will always result in a symbol reference to the specified object. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [debug] Allow per-object runtime enabling/disabling of debug messagesMichael Brown2016-07-051-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | The DBG_ENABLE() and DBG_DISABLE() macros currently affect the debug level of all objects that were built with debugging enabled. This is undesirable, since it is common to use different debug levels in each object. Make the debug level mask a per-object variable. DBG_ENABLE() and DBG_DISABLE() now control only the debug level for the containing object (which is consistent with the intended usage across the existing codebase). DBG_ENABLE_OBJECT() and DBG_DISABLE_OBJECT() may be used to control the debug level for a specified object. For example: // Enable DBG() messages from tcpip.c DBG_ENABLE_OBJECT ( tcpip, DBGLVL_LOG ); Note that the existence of debug messages continues to be gated by the DEBUG=... list specified on the build command line. If an object was built without the relevant debug level, then DBG_ENABLE_OBJECT() will have no effect on that object at runtime (other than to explicitly drag in the object via a symbol reference). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Automatically generate vendor class identifier stringMichael Brown2016-07-041-0/+23
| | | | | | | | | | | | The vendor class identifier strings in DHCP_ARCH_VENDOR_CLASS_ID are out of sync with the (correct) client architecture values in DHCP_ARCH_CLIENT_ARCHITECTURE. Fix by removing all definitions of DHCP_ARCH_VENDOR_CLASS_ID, and instead generating the vendor class identifier string automatically based on DHCP_ARCH_CLIENT_ARCHITECTURE and DHCP_ARCH_CLIENT_NDI. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcpv6] Include vendor class identifier option in DHCPv6 requestsMichael Brown2016-07-041-11/+32
| | | | | | | | | | | | | | | | | | | | | | | | RFC3315 defines DHCPv6 option 16 (vendor class identifier) but does not define any direct relationship with the roughly equivalent DHCPv4 option 60. The PXE specification predates IPv6, and the UEFI specification is expectedly vague on the subject. Examination of the reference EDK2 codebase suggests that the DHCPv6 vendor class identifier will be formatted in accordance with RFC3315, using a single vendor-class-data item in which the opaque-data field is the string as would appear in DHCPv4 option 60. RFC3315 requires the vendor class identifier to specify an IANA enterprise number, as a way of disambiguating the vendor-class-data namespace. The EDK2 code uses the value 343, described as: // TODO: IANA TBD: temporarily using Intel's Since this "TODO" has been present since at least 2010, it is probably safe to assume that it has now become a de facto standard. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcpv6] Include RFC5970 client architecture options in DHCPv6 requestsMichael Brown2016-07-041-0/+33
| | | | | | | | RFC5970 defines DHCPv6 options 61 (client system architecture type) and 62 (client network interface identifier), with contents equivalent to DHCPv4 options 93 and 94 respectively. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Renumber virtio_pci_region flagsLadi Prosek2016-06-201-3/+3
| | | | | | | | | | | | | Some of the regions may end up being unmapped, either because they are optional or because the attempt to map them has failed. Region types starting at 0 didn't make it easy to test for this condition. This commit bumps all valid region types up by 1 with 0 having the implicit 'unmapped' meaning. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [thunderx] Add driver for Cavium ThunderX SoC NICsMichael Brown2016-06-131-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cmdline] Add "ntp" commandMichael Brown2016-06-131-0/+14
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ntp] Add simple NTP clientMichael Brown2016-06-132-0/+110
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [time] Allow system clock to be adjusted at runtimeMichael Brown2016-06-132-3/+16
| | | | | | | | | | Provide a mechanism to allow an arbitrary adjustment to be applied to all subsequent calls to time(). Note that the underlying clock source (e.g. the RTC clock) will not be changed; only the time as reported within iPXE will be affected. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tcp] Send TCP keepalives on idle established connectionsMichael Brown2016-06-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | In some circumstances, intermediate devices may lose state in a way that temporarily prevents the successful delivery of packets from a TCP peer. For example, a firewall may drop a NAT forwarding table entry. Since iPXE spends most of its time downloading files (and hence purely receiving data, sending only TCP ACKs), this can easily happen in a situation in which there is no reason for iPXE's TCP stack to generate any retransmissions. The temporary loss of connectivity can therefore effectively become permanent. Work around this problem by sending TCP keepalives after a period of inactivity on an established connection. TCP keepalives usually send a single garbage byte in sequence number space that has already been ACKed by the peer. Since we do not need to elicit a response from the peer, we instead send pure ACKs (with no garbage data) in order to keep the transmit code path simple. Originally-implemented-by: Ladi Prosek <lprosek@redhat.com> Debugged-by: Ladi Prosek <lprosek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Support systems with multiple PCI root bridgesMichael Brown2016-06-091-7/+9
| | | | | | | | | Extend the 16-bit PCI bus:dev.fn address to a 32-bit seg:bus:dev.fn address, assuming a segment value of zero in contexts where multiple segments are unsupported by the underlying data structures (e.g. in the iBFT or BOFM tables). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Expose DHCP packets via the Apple NetBoot protocolMichael Brown2016-05-292-0/+47
| | | | | | | | Mac OS X uses non-standard EFI protocols to obtain the DHCP packets from the UEFI firmware. Originally-implemented-by: Michael Kuron <m.kuron@gmx.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Fix definitions for x86_64 and EFI BC client architecturesMichael Brown2016-05-261-4/+4
| | | | | | | | | | | | | | | There has been a longstanding disagreement between RFC4578 and the IANA "Processor Architecture Types" registry. RFC4578 section 2.1 defines type 7 as "EFI BC" and type 9 as "EFI x86-64"; the IANA registry quotes RFC4578 as its source but has these values erroneously swapped. The EDK2 codebase uses the IANA values. As of March 2016, RFC4578 has been modified by an errata to match the values as recorded in the IANA registry. Fix our definitions to match the consensus values. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-09 12:09:02 +0100