aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-08-03[efi] Use device path to locate filesystem from which we were loadedissue123Michael Brown2-2/+53
The file:/ URI syntax may be used to refer to local files on the filesystem from which the iPXE binary was loaded. This is currently implemented by directly using the DeviceHandle recorded in our EFI_LOADED_IMAGE_PROTOCOL. This mechanism will fail when a USB-enabled build of iPXE is loaded from USB storage and subsequently installs its own USB host controller drivers, since doing so will disconnect and reconnect the existing USB storage drivers and thereby invalidate the original storage device handle. Fix by recording the device path for the loaded image's DeviceHandle at initialisation time and later using the recorded device path to locate the appropriate device handle. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-08-03[efi] Match EDK2 numbering for USB portsMichael Brown1-1/+1
The various USB specifications all use one-based numbering for ports. This scheme is applied consistently across the various relevant specifications, covering both port numbers that appear on the wire (i.e. downstream hub port numbers) and port numbers that exist only logically (i.e. root hub port numbers). The UEFI specification is ambiguous about the port numbers as used for the ParentPortNumber field within a USB_DEVICE_PATH structure. As of UEFI specification version 2.8 errata B: - section 10.3.4.5 just states "USB Parent Port Number" with no indication of being zero-based or one-based - section 17.1.1 notes that for the EFI_USB2_HC_PROTOCOL, references to PortNumber parameters are zero-based for root hub ports - section 17.1.1 also mentions a TranslatorPortNumber used by EFI_USB2_HC_PROTOCOL, with no indication of being zero-based or one-based - there are no other mentions of USB port numbering schemes. Experimentation and inspection of the EDK2 codebase reveals that at least the EDK2 reference implementation will use zero-based numbering for both root and non-root hub ports when populating a USB_DEVICE_PATH structure (though will inconsistently use one-based numbering for the TranslatorPortNumber parameter). Use zero-based numbering for both root and non-root hub ports when constructing a USB_DEVICE_PATH in order to match the behaviour of the EDK2 implementation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-27[comboot] Fix stack pointer retrieval after COM32 binary returnsDentcho Ludmilov Bankov1-1/+1
This change fixes the offset used when retrieving the iPXE stack pointer after a COM32 binary returns. The iPXE stack pointer is saved at the top of the available memory then the the top of the stack for the COM32 binary is set just below it. However seven more items are pushed on the COM32 stack before the entry point is invoked so when the COM32 binary returns the location of the iPXE stack pointer is 28 (and not 24) bytes above the current stack pointer. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-22[efi] Check the status code from AllocatePool()Ignat Korchagin1-4/+5
According to the latest UEFI specification (Version 2.8 Errata B) p. 7.2: "Buffer: A pointer to a pointer to the allocated buffer if the call succeeds; undefined otherwise." So implementations are obliged neither to return NULL, if the allocation fails, nor to preserve the contents of the pointer. Make the logic more reliable by checking the status code from AllocatePool() instead of checking the returned pointer for NULL Signed-off-by: Ignat Korchagin <ignat@cloudflare.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-22[cmdline] Add "--timeout" parameter to "ifconf" commandJoe Groocock4-5/+14
Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-22[intelx] Added PCI_ROM entry for Intel x553/x557-AT and x553 (SFP+) NICsRob Taglang1-0/+2
Signed-off-by: Rob Taglang <rob@taglang.io> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-22[intel] Set INTEL_NO_PHY_RST on i218vBen Bleything1-1/+1
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-22[intel] Add INTEL_NO_PHY_RST for I218LMAndrew Grasso1-1/+1
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-21[deflate] Fix typo in comment describing length codesDaniel Johnson1-1/+1
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-21[build] Fix a GNUism that FreeBSD's sed(1) cannot deal withTobias Kortkamp1-1/+1
At the moment '\s*' is silently interpreted as just 's*', but in the future it will be an error: sed: 1: "s/\.o\s*:/_DEPS +=/": RE error: trailing backslash (\) cf. https://bugs.freebsd.org/229925 Signed-off-by: Tobias Kortkamp <t@tobik.me> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-21[wpa] Fix erroneous debug message in wpa_derive_ptkMichael Brown1-2/+3
Split debug message since eth_ntoa() uses a static result buffer. Originally-fixed-by: Michael Bazzinotti <bazz@bazz1.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-21[libc] Fix memcmp() to return proper valuesMichael J. Bazzinotti2-1/+2
Fix memcmp() to return proper standard positive/negative values for unequal comparisons. Current implementation is backwards (i.e. the functions are returning negative when should be positive and vice-versa). Currently most consumers of these functions only check the return value for ==0 or !=0 and so we can safely change the implementation without breaking things. However, there is one call that checks the polarity of this function, and that is prf_sha1() for wireless WPA 4-way handshake. Due to the incorrect memcmp() polarity, the WPA handshake creates an incorrect PTK, and the handshake would fail after step 2. Undoubtedly, the AP noticed the supplicant failed the mic check. This commit fixes that issue. Similar to commit 3946aa9 ("[libc] Fix strcmp()/strncmp() to return proper values"). Signed-off-by: Michael Bazzinotti <bazz@bazz1.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-21[pcbios] Take alignment into account when checking for available spaceDavid Decotigny1-4/+4
Signed-off-by: David Decotigny <ddecotig@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-21[pcbios] Fix "out of memory" detection when expanding bottom areaDavid Decotigny1-1/+1
This caused iPXE to reject images even when enough memory was available. Signed-off-by: David Decotigny <ddecotig@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-21[libgcc] Change __divmoddi4 from int64 [unknown] to int64_tBobby Lockwood1-1/+1
Matches the header file libgcc.h and solves __divmoddi4.c:3:56: error: unknown type name ‘int64’ Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-21[build] Fix default target in sdsk imagebit1-1/+1
gensdsk currently creates a syslinux.cfg file that is invalid if the filename ends in lkrn. Fix by setting the default target to label($b) instead of filename($g). Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-15[dns] Use all configured DNS serversMichael Brown1-49/+130
When no response is obtained from the first configured DNS server, fall back to attempting the other configured servers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-15[xfer] Remove address family from definition of a socket openerMichael Brown5-35/+7
All implemented socket openers provide definitions for both IPv4 and IPv6 using exactly the same opener method. Simplify the logic by omitting the address family from the definition. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-15[sfc] Add PCI ID for Solarflare SFC9120 and Solarflare SFC9140LaDerrick H1-0/+2
This patch adds support for 2 Solarflare NICs. Signed-off-by: LaDerrick H <ipxelist243@lacutt.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-15[efi] Claim SNP devices early in efi_download_start()tplMichael Brown1-1/+4
Claiming the SNP devices has the side effect of raising the TPL to iPXE's normal operating level of TPL_CALLBACK (see the commit message for c89a446 ("[efi] Run at TPL_CALLBACK to protect against UEFI timers") for details). This must happen before executing any code that relies upon the TPL having been raised to TPL_CALLBACK. The call to efi_snp_claim() in efi_download_start() currently happens only after the call to xfer_open(). Calling xfer_open() will typically result in a retry timer being started, which will result in a call to currticks() in order to initialise the timer. The call to currticks() will drop to TPL_APPLICATION and restore to TPL_CALLBACK in order to allow a timer tick to occur. Since this call happened before the call to efi_snp_claim(), the restored TPL is incorrect. This in turn results in efi_snp_claim() recording the incorrect original TPL, causing efi_snp_release() to eventually restore the incorrect TPL, causing the system to lock up when ExitBootServices() is called at TPL_CALLBACK. Fix by moving the call to efi_snp_claim() to the start of efi_download_start(). Debugged-by: Jarrod Johnson <jjohnson2@lenovo.com> Debugged-by: He He4 Huang <huanghe4@lenovo.com> Debugged-by: James Wang <jameswang@ami.com.tw> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-09[efi] Ensure NUL byte is at lowest address within stack cookiecookieMichael Brown1-0/+8
The NUL byte included within the stack cookie to act as a string terminator should be placed at the lowest byte address within the stack cookie, in order to avoid potentially including the stack cookie value within an accidentally unterminated string. Suggested-by: Pete Beck <pete.beck@ioactive.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-09[efi] Distribute available entropy within stack cookieMichael Brown1-6/+17
Several of the values used to compute a stack cookie (in the absence of a viable entropy source) will tend to have either all-zeroes or all-ones in the higher order bits. Rotate the values in order to distribute the (minimal) available entropy more evenly. Suggested-by: Pete Beck <pete.beck@ioactive.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-09[libc] Add bit-rotation functions for unsigned long valuesMichael Brown1-8/+26
Generalise the bit rotation implementations to use a common macro, and add roll() and rorl() to handle unsigned long values. Each function will still compile down to a single instruction. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-07[efi] Avoid setting direction flag on EFI platformsMichael Brown2-0/+15
The only remaining use case in iPXE for the CPU direction flag is in __memcpy_reverse() where it is set to allow the use of "rep movsb" to perform the memory copy. This matches the equivalent functionality in the EDK2 codebase, which has functions such as InternalMemCopyMem that also temporarily set the direction flag in order to use "rep movsb". As noted in commit d2fb317 ("[crypto] Avoid temporarily setting direction flag in bigint_is_geq()"), some UEFI implementations are known to have buggy interrupt handlers that may reboot the machine if a timer interrupt happens to occur while the direction flag is set. Work around these buggy UEFI implementations by using the (unoptimised) generic_memcpy_reverse() on i386 or x86_64 UEFI platforms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-07[libc] Provide an unoptimised generic_memcpy_reverse()Michael Brown2-5/+22
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-07[crypto] Avoid temporarily setting direction flag in bigint_is_geq()Michael Brown1-17/+8
The UEFI specification states that the calling convention for IA-32 and x64 includes "Direction flag in EFLAGS is clear". This specification covers only the calling convention used at the point of calling functions annotated with EFIAPI. The specification explicitly states that other functions (such as private functions or static library calls) are not required to follow the UEFI calling conventions. The reference EDK2 implementation follows this specification. In particular, the EDK2 interrupt handlers will clear the direction flag before calling any EFIAPI functions, and will restore the direction flag when returning from the interrupt handler. Some EDK2 private library functions (most notably InternalMemCopyMem) may set the direction flag temporarily in order to make efficient use of CPU string operations. The current implementation of iPXE's bigint_is_geq() for i386 and x86_64 will similarly set the direction flag temporarily in order to make efficient use of CPU string operations. On some UEFI implementations (observed with a Getac RX10 tablet), a timer interrupt that happens to occur while the direction flag is set will reboot the machine. This very strongly indicates that the UEFI timer interrupt handler is failing to clear the direction flag before performing an affected operation (such as copying a block of memory). Work around such buggy UEFI implementations by rewriting bigint_is_geq() to avoid the use of string operations and so obviate the requirement to temporarily set the direction flag. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-04[usb] Leave port enabled after a failed device registrationMichael Brown1-1/+3
A failure in device registration (e.g. due to a device with malformed descriptors) will currently result in the port being disabled as part of the error path. This in turn causes the hardware to detect the device as newly connected, leading to an endless loop of failed device registrations. Fix by leaving the port enabled in the case of a registration failure. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-03[axge] Reapply USB device configuration when opening network deviceMichael Brown2-0/+11
When connected to a USB3 port, the AX88179 seems to have an approximately 50% chance of producing a USB transaction error on each of its three endpoints after being closed and reopened. The root cause is unclear, but rewriting the USB device configuration value seems to clear whatever internal error state has accumulated. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-03[xhci] Increase link state settling delay to 100msMichael Brown1-1/+1
Experimentation shows that the existing 20ms delay is insufficient, and often results in device detection being deferred until after iPXE has completed startup. Fix by increasing the delay to 100ms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-03[usb] Avoid unnecessary calls to usb_hub_set_drvdata()Michael Brown3-25/+8
The driver-private data for root hubs is already set immediately after allocating the USB bus. There seems to be no reason to set it again when opening the root hub. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-03[xhci] Set link state to RxDetect after disabling USB3 root hub portMichael Brown1-0/+13
The "disabled" port states for USB2 and USB3 are not directly equivalent. In particular, a disabled USB3 port will not detect new device connections. The result is that a USB3 device disconnected from and reconnected to an xHCI root hub port will end up reconnecting as a USB2 device. Fix by setting the link state to RxDetect after disabling the port, as is already done during initialisation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-02[usb] Do not attempt to disable USB3 hub portsMichael Brown1-2/+4
The USB3 specification removes PORT_ENABLE from the list of features that may be cleared via a CLEAR_FEATURE request. Experimentation shows that omitting the attempt to clear PORT_ENABLE seems to result in the correct hotplug behaviour. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-02[usb] Add missing usb_recycle() for completed hub interrupt transfersMichael Brown1-0/+4
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-02[usb] Clear device endpoint halt before resetting host endpointMichael Brown1-7/+7
Resetting the host endpoint may immediately restart any pending transfers for that endpoint. If the device endpoint halt has not yet been cleared, then this will probably result in a second failed transfer. This second failure may be detected within usb_endpoint_reset() while waiting for usb_clear_feature() to complete. The endpoint will subsequently be removed from the list of halted endpoints, causing the second failure to be effectively ignored and leaving the host endpoint in a permanently halted state. Fix by deferring the host endpoint reset until after the device endpoint is ready to accept new transfers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-07-01[axge] Handle non-gigabit link speedsMichael Brown2-22/+39
The ASIX USB NICs are capable of autodetecting the Ethernet link speed and reporting it via PLSR but will not automatically update the relevant GM and PS bits in MSR. The result is that a non-gigabit link will fail to send or receive any packets. The interrupt endpoint used to report link state includes the values of the PHY BMSR and LPA registers. These are not sufficient to differentiate between 100Mbps and 1000Mbps, since the LPA_NPAGE bit does not necessarily indicate that the link partner is advertising 1000Mbps. Extend axge_check_link() to write the MSR value based on the link speed read from PLSR, and simplify the interrupt endpoint handler to merely trigger a call to axge_check_link(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-30[efi] Raise TPL during driver entry pointMichael Brown1-0/+9
As per commit c89a446 ("[efi] Run at TPL_CALLBACK to protect against UEFI timers") we expect to run at TPL_CALLBACK almost all of the time. Various code paths rely on this assumption. Code paths that need to temporarily lower the TPL (e.g. for entropy gathering) will restore it to TPL_CALLBACK. The entropy gathering code will be run during DRBG initialisation, which happens during the call to startup(). In the case of iPXE compiled as an EFI application this code will run within the scope of efi_snp_claim() and so will execute at TPL_CALLBACK as expected. In the case of iPXE compiled as an EFI driver the code will incorrectly run at TPL_APPLICATION since there is nothing within the EFI driver entry point that raises (and restores) the TPL. The net effect is that a build that includes the entropy-gathering code (e.g. a build with HTTPS enabled) will return from the driver entry point at TPL_CALLBACK, which causes a system lockup. Fix by raising and restoring the TPL within the EFI driver entry point. Debugged-by: Ignat Korchagin <ignat@cloudflare.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-28[efi] Detect and disable seriously broken EFI_RNG_PROTOCOL implementationsMichael Brown1-0/+12
The EFI_RNG_PROTOCOL on the Microsoft Surface Go does not generate random numbers. Successive calls to GetRNG() without any intervening I/O operations (such as writing to the console) will produce identical results. Successive reboots will produce identical results. It is unclear what the Microsoft Surface Go is attempting to use as an entropy source, but it is demonstrably producing zero bits of entropy. The failure is already detected by the ANS-mandated Repetition Count Test performed as part of our GetEntropy implementation. This currently results in the entropy source being marked as broken, with the result that iPXE refuses to perform any operations that require a working entropy source. We cannot use the existing EFI driver blacklisting mechanism to unload the broken driver, since the RngDxe driver is integrated into the DxeCore image. Work around the broken driver by checking for consecutive identical results returned by EFI_RNG_PROTOCOL and falling back to the original timer-based entropy source. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-27[build] Disable position-independent code for ARM64 EFI buildsMichael Brown1-0/+4
Some versions of gcc (observed with the cross-compiling gcc 9.3.0 in Ubuntu 20.04) default to enabling -fPIE. Experimentation shows that this results in the emission of R_AARCH64_ADR_GOT_PAGE relocation records for __stack_chk_guard. These relocation types are not supported by elf2efi.c. Fix by explicitly disabling position-independent code for ARM64 EFI builds. Debugged-by: Antony Messerli <antony@mes.ser.li> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-27[golan] Add explicit type casts for nodnic_queue_pair_typeMichael Brown1-2/+4
GCC 10 emits warnings for implicit conversions of enumerated types. The flexboot_nodnic code defines nodnic_queue_pair_type with values identical to those of ib_queue_pair_type, and implicitly casts between them. Add an explicit cast to fix the warning. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-27[intel] Avoid spurious compiler warning on GCC 10Michael Brown2-9/+17
GCC 10 produces a spurious warning about an out-of-bounds array access for the unsized raw dword array in union intelvf_msg. Avoid the warning by embedding the zero-length array within a struct. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-27[build] Be explicit about -fcommon compiler directivetempBruce Rogers1-0/+1
gcc10 switched default behavior from -fcommon to -fno-common. Since "__shared" relies on the legacy behavior, explicitly specify it. Signed-off-by: Bruce Rogers <brogers@suse.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-25[ocsp] Accept SHA1 certID responses even if SHA1 is not enabledMichael Brown1-15/+25
Various implementation quirks in OCSP servers make it impractical to use anything other than SHA1 to construct the issuerNameHash and issuerKeyHash identifiers in the request certID. For example: both the OpenCA OCSP responder used by ipxe.org and the Boulder OCSP responder used by LetsEncrypt will fail if SHA256 is used in the request certID. As of commit 6ffe28a ("[ocsp] Accept response certID with missing hashAlgorithm parameters") we rely on asn1_digest_algorithm() to parse the algorithm identifier in the response certID. This will fail if SHA1 is disabled via config/crypto.h. Fix by using a direct ASN.1 object comparison on the OID within the algorithm identifier. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-24[efi] Enable stack protection where possibleMichael Brown6-11/+115
Enable -fstack-protector for EFI builds, where binary size is less critical than for BIOS builds. The stack cookie must be constructed immediately on entry, which prohibits the use of any viable entropy source. Construct a cookie by XORing together various mildly random quantities to produce a value that will at least not be identical on each run. On detecting a stack corruption, attempt to call Exit() with an appropriate error. If that fails, then lock up the machine since there is no other safe action that can be taken. The old conditional check for support of -fno-stack-protector is omitted since this flag dates back to GCC 4.1. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-19[parseopt] Treat empty integer strings in user input as invalidMichael Brown1-1/+1
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-19[util] Treat empty integer strings as invalidMichael Brown2-3/+3
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-19[snp] Retry initialisation if link is reported as downMichael Brown1-7/+49
Some devices (observed with a Getac RX10 tablet and docking station containing an embedded AX88179 USB NIC) seem to be capable of detecting link state only during the call to Initialize(), and will occasionally erroneously report that the link is down for the first few such calls. Work around these devices by retrying the Initialize() call multiple times, terminating early if a link is detected. The eventual absence of a link is treated as a non-fatal error, since it is entirely possible that the link really is down. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-16[crypto] Disable MD5 as an OID-identifiable algorithm by defaultMichael Brown1-1/+1
Disable the use of MD5 as an OID-identifiable algorithm. Note that the MD5 algorithm implementation will still be present in the build, since it is used implicitly by various cryptographic components such as HTTP digest authentication; this commit removes it only from the list of OID-identifiable algorithms. It would be appropriate to similarly disable the use of SHA-1 by default, but doing so would break the use of OCSP since several OCSP responders (including the current version of openca-ocspd) are not capable of interpreting the hashAlgorithm field and so will fail if the client uses any algorithm other than the configured default. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-16[crypto] Ensure that test code drags in required ASN.1 object identifiersMichael Brown2-12/+31
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-16[crypto] Allow algorithms to be included without being OID-identifiableMichael Brown22-122/+433
There are many ways in which the object for a cryptographic algorithm may be included, even if not explicitly enabled in config/crypto.h. For example: the MD5 algorithm is required by TLSv1.1 or earlier, by iSCSI CHAP authentication, by HTTP digest authentication, and by NTLM authentication. In the current implementation, inclusion of an algorithm for any reason will result in the algorithm's ASN.1 object identifier being included in the "asn1_algorithms" table, which consequently allows the algorithm to be used for any ASN1-identified purpose. For example: if the MD5 algorithm is included in order to support HTTP digest authentication, then iPXE would accept a (validly signed) TLS certificate using an MD5 digest. Split the ASN.1 object identifiers into separate files that are required only if explicitly enabled in config/crypto.h. This allows an algorithm to be omitted from the "asn1_algorithms" table even if the algorithm implementation is dragged in for some other purpose. The end result is that only the algorithms that are explicitly enabled in config/crypto.h can be used for ASN1-identified purposes such as signature verification. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2020-06-16[tls] Default to supporting only TLSv1.1 or aboveMichael Brown1-1/+1
Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.1 at 2024-09-09 15:32:15 +0000