)]}' { "log": [ { "commit": "4b7e1df9c513d43e9e79c63463aa2470f34de7e3", "tree": "a61acee958bbf5967005f1186054e9ffa14837c8", "parents": [ "70f39d5b0dcf427d0dd143bf5f55c82df401c486" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sat Oct 24 17:39:16 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sat Oct 24 17:39:16 2026 +0100" }, "message": "[cloud] Use Fedora vmlinuz for repeated download test\n\nDrop the 1MB pseudorandom test file and instead use the ~15MB Fedora\nvmlinuz for the repeated download test, since this file is available\nwithin the in-region mirror.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "70f39d5b0dcf427d0dd143bf5f55c82df401c486", "tree": "16ca6fac9bb5b13ca35e831f0a35dd704f869225", "parents": [ "a03f9eda42e6271bc9c4fab20602b0a764b443ce" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Oct 23 17:55:18 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Oct 23 17:55:18 2026 +0100" }, "message": "[cloud] Default to using an in-region mirror for Fedora test files\n\nSpeed up automated tests by downloading the relatively large (~250MB)\nFedora kernel and initrd from an in-region partial mirror (that\ncontains only those files).\n\nUse a templated URL since other approaches (such as a multi-region\naccess point, or CloudFront) either require signed requests or are\nsignificantly slower than direct S3 access.\n\nThe partial mirror is configured using cross-region replication to\nmirror the required test files (i.e. the vmlinuz and initrd.img files\nfor both x86_64 and aarch64), with an S3 gateway configured within\neach region to grant access to the mirrored files.\n\nThe default mirrors are not directly accessible from the outside\nworld, or by other users. Since the path structure matches the\nstandard Fedora repository, users can specify a public mirror using\ne.g.\n\n ../contrib/cloud/aws-test \\\n --mirror http://download.fedoraproject.org/pub/fedora/linux/releases/44 \\\n ...instance type list...\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "a03f9eda42e6271bc9c4fab20602b0a764b443ce", "tree": "1b3bc4aebcd290476a0b43731a4be8c1b2716dd7", "parents": [ "582852868c6a68db138cd5c99719b8395ce24686" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 22 15:27:34 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 22 15:35:52 2026 +0100" }, "message": "[peerdist] Use separate discovery probe message IDs for IPv4 and IPv6\n\nThe SOAP-over-UDP specification states that for each retransmission\nthe value of the message ID property must be the same. We currently\nuse a single (weakly) random message ID for all transmissions used to\ndiscover a given segment.\n\nExperiments suggest that Windows performs some deduplication of probe\nmessages and will respond to either the IPv4 or the IPv6 probe but not\nto both, if they arrive with the same message ID in quick succession.\nThis undermines our attempt to prefer IPv4 peers: we can quite easily\nend up receiving only IPv6 discovery responses.\n\nTreat the IPv4 and IPv6 discovery probes as separate messages: use a\n(trivially) different message ID for each address family but then\nretain that message ID for each retransmission as per the spec.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "582852868c6a68db138cd5c99719b8395ce24686", "tree": "56983d10416b0bc21b4d2b2f24ce0e4ab5b3e24e", "parents": [ "305947bc3e2a7ee2be5bdb629646acf3fab348be" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 22 14:17:45 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 22 14:20:39 2026 +0100" }, "message": "[peerdist] Use segment count to report download progress\n\nPeerDist individual block downloads may complete out of order, causing\nthe download progress indicator to occasionally jump backwards.\n\nUse the block multiplexer\u0027s current segment index and the total number\nof segments to construct the job progress indicator, since this is\nguaranteed to increase monotonically.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "305947bc3e2a7ee2be5bdb629646acf3fab348be", "tree": "96ca516b9df41143d152951b51eb12d6f2fe488d", "parents": [ "a5eed98d964bc48790041aed41a8876fa0b7eba5" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 21 20:00:02 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 22 14:04:17 2026 +0100" }, "message": "[peerdist] Add \"peerstat\" command for reporting peer statistics\n\nEach PeerDist-encoded downloaded file typically results in several\nthousand individual block downloads, each of which may end up being\nattempted as a classic retrieval from a discovered peer, a retrieval\nfrom an optimistically assumed peer, a retrieval from a hosted cache\nserver, a read from a local filesystem cache, and/or a raw range\nrequest from the origin server.\n\nThe sheer volume of activity and the number of errors expected in\nnormal operation (e.g. for blocks missing from a particular peer) make\nit difficult to use debug messages to gain insights into behaviour,\nsince per-event debug messages are either too rare to be informative\nor so frequent that the overhead of printing the messages alters the\noverall behaviour.\n\nGather error statistics separately for each category of individual\nblock download and for each discovery address family, along with the\nmost useful summary counts (e.g. for total blocks, total number of\ndiscovery attempts, etc).\n\nEstimate the total number of peers as being the highest number of\npeers ever discovered for a segment within a single address family.\n(We count per address family to avoid double-counting a single peer\nthat advertises itself using both IPv4 and IPv6 addresses.)\n\nReport the number of discovery attempts independent of address family\n(i.e. one discovery attempt means N transmitted packets, one sent via\neach of the N supported address families), since that number is then\nmeaningfully comparable against the total number of blocks.\n\nReport second and subsequent discovery attempts separately from\ninitial discovery attempts, so that the number of discovery attempts\ncan be compared against the number of blocks to determine how many\ndiscoveries were elided completely.\n\nSeparate the discovery reply statistics by address family, not because\nthere is anything useful in knowing whether a particular error\nhappened for IPv4 versus IPv6, but because it avoids the need to\nreason about whether or not a displayed result needs to be mentally\nhalved in order to be compared against the corresponding discovery\nattempt statistic.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "a5eed98d964bc48790041aed41a8876fa0b7eba5", "tree": "75f086526369ecdbf51bf0c0308cc1c56aa1fb1d", "parents": [ "ea3255b59ca7d34cd7858aad80918f6913e32769" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 21 19:52:37 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 21 20:40:29 2026 +0100" }, "message": "[peerdist] Remove obsolete statistics mechanism\n\nThe peer count reported via the job progress message has been largely\nmeaningless ever since commit 9b6ad2d (\"[peerdist] Assume that most\nrecently discovered peer can be reused\").\n\nRemove this obsolete and misleading mechanism for reporting peer\nstatistics.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "ea3255b59ca7d34cd7858aad80918f6913e32769", "tree": "9c49c1c7c15d20ff78b363ab762a0d3bd5af10b8", "parents": [ "2fa08affe9a1a1422766f54b2fb045234b571f06" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Oct 20 17:32:32 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 21 20:40:20 2026 +0100" }, "message": "[netdevice] Generalise the error statistics counter mechanism\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "2fa08affe9a1a1422766f54b2fb045234b571f06", "tree": "ac5b40b3d0541d0a40e562eb206e43eca3e17f72", "parents": [ "fe159d0910cac1cd49bab8d4b9296dbe2d9d3cc2" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Oct 20 12:34:39 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Oct 20 12:34:39 2026 +0100" }, "message": "[pci] Check device presence before checking for multi-function device\n\nThere are two checks that we perform to see whether a PCI device\nexists at a given bus:dev.fn address. We check to see if the vendor\nand device IDs read as either all-zeros or all-ones, and for a\nnon-zero function number we also check that the device is actually a\nmulti-function device by reading the header type from the device\u0027s\nfunction zero.\n\nFor historical reasons, the multi-function header type check is\ncurrently performed before the existence check. (The code originally\nsupported only a one-time linear enumeration of the PCI bus, and so\nthe header type for function zero was already known: checking the\nheader type first therefore used to allow the read of the vendor and\ndevice IDs to be elided completely.)\n\nOn some UEFI systems (observed on an AWS a1.metal instance in\neu-central-1), attempting to read the vendor and device IDs for a\nnon-existent device will work as expected, but attempting to read the\nheader type will lock up the system. (No further diagnostics are\navailable: the a1.metal instance type has no serial port and does not\nsupport taking a screenshot, and so the only available output is from\nthe iPXE disk log console.)\n\nWork around this curious defect by swapping the order of the existence\nand header type checks.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "fe159d0910cac1cd49bab8d4b9296dbe2d9d3cc2", "tree": "21789d1374c0c6fb11fc163a8f11cec32c443f1f", "parents": [ "1573f8c084ffd9e763992a6a739f308a9edd95a1" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Oct 19 13:15:49 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Oct 19 14:24:30 2026 +0100" }, "message": "[cloud] Use an explicit Fedora mirror for instance type tests\n\nThe top-level download.fedoraproject.org server seems to have been\nreconfigured to be unable to redirect requests for individual files to\nan appropriate mirror.\n\nWork around this reconfiguration by using an explicit mirror.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "1573f8c084ffd9e763992a6a739f308a9edd95a1", "tree": "cd095d0277177f5d93192cd2746bf4786fae0033", "parents": [ "c51ca76a6e56c5627aea6dc32da4c18d5e6cf394" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Oct 18 22:00:45 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Oct 18 22:56:06 2026 +0100" }, "message": "[intel] Do not zero descriptor ring head/tail pointers on close\n\nThe externally contributed commit 1d04900 (\"[intel] Reset all virtual\nfunction settings\") seems to break the 82599 virtual function NICs as\nfound within some older AWS instance types (observed on a c3.large\ninstance in eu-central-1). If the transmit ring tail (VFTDT[0]) has a\nnon-zero value (i.e. if any packets have been transmitted), then\nwriting a zero to the transmit ring tail after the ring has been\ndisabled will permanently lock up the transmit datapath in a way that\nsurvives even a VF reset.\n\nZeroing the head and tail registers when the interface is closed\nappears to be completely redundant: they will be cleared anyway by the\nvirtual function reset (VFCTRL.RST), and they will also be explicitly\nzeroed when the interface is reopened. The Linux ixgbevf driver does\nnot include any equivalent code to explicitly zero these registers\nwhen the interface is closed.\n\nFix by leaving the head and tail registers untouched when the\ninterface is closed.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "c51ca76a6e56c5627aea6dc32da4c18d5e6cf394", "tree": "2dac6d17ad80f985c70a28806de5267becc94d2b", "parents": [ "f887b5d62b8acd5158265dfab153e3d88224f82d" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 15 14:43:39 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 15 15:10:46 2026 +0100" }, "message": "[intel] Poll descriptor rings without waiting for interrupts\n\nSome of the Intel NIC drivers poll the transmit and receive rings only\nwhen the interrupt status indicates that a completion ought to be\navailable.\n\nWhen interrupt moderation is enabled, this can cause us to run out of\ndescriptors since both rings have only a small fill level. For the\nvirtual function driver, there may be no way to disable interrupt\nmoderation since this is at the discretion of the PF driver.\n\nPolling the descriptor rings is a very cheap operation. Poll both\nrings unconditionally, so that we continue to make progress even when\ninterrupts are not being delivered as expected.\n\nWith this change, the VMware-specific errata workaround (to force\nunconditional polling of the receive ring) becomes redundant. Remove\nthis workaround.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "f887b5d62b8acd5158265dfab153e3d88224f82d", "tree": "57329527f2624df70860a97b74782cbce91b1e4c", "parents": [ "a89ccdbbfcb7ddea8d2f3d9c4450e62c6216624b" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 15 14:29:04 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 15 15:10:46 2026 +0100" }, "message": "[intel] Use advanced format receive descriptors for 10GigE VF driver\n\nAt some unknown point, the Intel 82599 PF driver has ceased to support\nthe use of \"legacy\" format receive descriptors by the VF driver, and\nwill unconditionally write back \"advanced\" format descriptors despite\nthe SRRCTL.DESCTYPE value indicating otherwise.\n\nAdd an abstraction to allow for parsing the length and status from an\nadvanced format descriptor, and use this in the intelxvf driver.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "a89ccdbbfcb7ddea8d2f3d9c4450e62c6216624b", "tree": "db231c246cf0c2762d53138fc2ea45965d0f3c56", "parents": [ "4cd87232ede874bf8bec1d341da0fddd2663835a" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 15 11:09:17 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 15 11:58:50 2026 +0100" }, "message": "[xen] Fix MMIO BAR usage in 64-bit builds\n\nThe HVM MMIO BAR contains no actual MMIO registers, and exists only to\nprovide a chunk of guest physical address space that can be mapped via\nxenmem_add_to_physmap().\n\nThe existing code relies on virt_to_phys() to calculate the physical\nframe numbers (PFNs) to be mapped. This fails on platforms such as\nx86_64 BIOS where virt_to_phys() is undefined for MMIO space.\n\nFix by mapping the whole MMIO BAR once at probe time, allowing a\nvirtual address within the mapping to be used to determine the\nunderlying physical address.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "4cd87232ede874bf8bec1d341da0fddd2663835a", "tree": "ff3ea794ee86a3acd4cdd94924bcd1ac9fffcb79", "parents": [ "8f41e794db07fbf01e614dcf940454dce995a3b8" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 14 16:49:49 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 14 16:49:49 2026 +0100" }, "message": "[int13con] Preserve all registers across real-mode calls\n\nThe BIOS on some older AWS instance types (observed with c3.large in\neu-central-1) does not correctly preserve the upper halves of the\n32-bit general-purpose registers. In particular, calling INT13,42 or\nINT13,43 will zero the high half of %ebx. If the compiled code has a\nlive value in %ebx then this will result in undefined behaviour.\n\nThe defect appears to be AWS-specific: it does not exist in the\nupstream Bochs BIOS code from which this BIOS is derived.\n\nThe iPXE disk log console is not performance-sensitive but must be as\nreliable as possible, since it exists to be the debug log mechanism of\nlast resort. We therefore choose the path of maximum paranoia: we\nwork around this and other potential BIOS bugs by preserving all\nnon-output registers across all real-mode calls.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "8f41e794db07fbf01e614dcf940454dce995a3b8", "tree": "01ff716cc661d6ea7549909e981dbc412885ddd1", "parents": [ "e9ffd2a88051d1c50cfb6f0660f24f4448a73c3d" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 14 16:44:29 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 14 16:44:29 2026 +0100" }, "message": "[int13con] Check %ah rather than %al for error code\n\nThe error code (if any) from INT13,42 and INT13,43 is returned in %ah.\nThe code currently erroneously checks the value in %al, which happens\nto work only because BIOSes will leave %al unmodified (i.e. containing\nzero) and the operation is extremely unlikely to ever actually fail.\n\nFix by reading the error code from %ah instead of %al.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "e9ffd2a88051d1c50cfb6f0660f24f4448a73c3d", "tree": "8cadfc03b84685af49fa10992999798021668060", "parents": [ "ea4194e6d94130c0e7a67c56f1506625e3997941" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Oct 12 16:31:06 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Oct 12 16:31:06 2026 +0100" }, "message": "[cloud] Ignore old CPU architectures when selecting a compatible image\n\nSome older AWS instance types are listed as supporting both i386 and\nx86_64. Ignore i386 when identifying a compatible image, since the\nimported images are marked as being for x86_64 only.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "ea4194e6d94130c0e7a67c56f1506625e3997941", "tree": "51bd8e8bda9feac7ab26298a2be4f4e2084ece1d", "parents": [ "a57eaae286d099a0b69497f2f88a43416e7541c6" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Oct 12 14:56:44 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Oct 12 15:50:22 2026 +0100" }, "message": "[cloud] Add utility to check AWS instance type coverage\n\nRunning tests across every instance type would be prohibitively\nexpensive and mostly redundant: it is unlikely that two instance types\nthat differ only in their vCPU or memory allocations will behave\ndifferently.\n\nAdd a utility that can be used to verify that a predefined list of\ninstance types (matching those for which tests will be run) represents\na comprehensive subset of all instance types available within AWS.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "a57eaae286d099a0b69497f2f88a43416e7541c6", "tree": "e6a0a52eb89b943863d0710e1a551d8be276ed99", "parents": [ "bfa70055cebda3833996aac81f358918ba3b21f2" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Oct 11 15:33:45 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Oct 11 15:43:22 2026 +0100" }, "message": "[fbcon] Validate requested geometry and other configuration\n\nResponsibility for validating the requested geometry currently lies\nwith the caller of fbcon_init(), which makes it non-obvious that (for\nexample) the pixel width is guaranteed to be large enough for the\nrequested width.\n\nValidate all console configuration parameters against the pixel\ngeometry within fbcon_init(), since this is the function that performs\ncalculations based on them.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "bfa70055cebda3833996aac81f358918ba3b21f2", "tree": "b7e04a18c959d2d78f67689cdf1126227a8b1108", "parents": [ "c86730a30547823e73a363d903a1510a4664a9b1" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Oct 11 14:43:00 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Oct 11 15:43:08 2026 +0100" }, "message": "[iscsi] Defer redirection until RX state machine is idle\n\nWait for the full login response PDU (including any padding) to arrive\nbefore closing and reopening the connection for a redirection.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "c86730a30547823e73a363d903a1510a4664a9b1", "tree": "9bf3810c4b89b3338df43277ec59dbcd915dc74c", "parents": [ "719a85cfccb1f71cd18c7825e42ebbc322e6eaff" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sat Oct 10 20:38:51 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sat Oct 10 20:38:51 2026 +0100" }, "message": "[cloud] Extend AWS automated testing to include a Linux kernel boot\n\nInclude a test that boots into the Fedora live installer kernel and\ninitramfs, with a small control script injected into the initramfs\nthat uploads a zero-length flag file to S3 and then powers down the\ninstance.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "719a85cfccb1f71cd18c7825e42ebbc322e6eaff", "tree": "84499bcd56991543c3add9dcc0944650f97a3f1f", "parents": [ "d1a6f66d38e8f00b3a046bba953b9f3a0eb7ef09" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Oct 09 14:17:25 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Oct 09 14:17:25 2026 +0100" }, "message": "[build] Switch default build architecture to x86_64\n\nSupport for 32-bit i386 is gradually fading away across the ecosystem.\nIt is reasonably common to encounter devices with 64-bit MMIO BARs in\nsystems that place these BARs above the 32-bit address space. These\ndevices cannot be used by a 32-bit build of iPXE.\n\nThe default binaries published in both the rolling release and the\ntagged releases are already x86_64 rather than i386. The only\nremaining trace of the 32-bit default is the unadorned \"bin/\" build\ndirectory prefix, which is currently interpreted as being equivalent\nto \"bin-i386-pcbios/\".\n\nSwitch the default build architecture from i386 to x86_64.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "d1a6f66d38e8f00b3a046bba953b9f3a0eb7ef09", "tree": "b4a749fc9b1bc0f9740ffcd54354d4eb14a1afb9", "parents": [ "b54689abd6f88460954954993835399dd816dc39" ], "author": { "name": "Dario Faggioli", "email": "dfaggioli@suse.com", "time": "Fri Sep 18 10:13:46 2026 +0200" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Oct 09 12:22:37 2026 +0100" }, "message": "[virtio] Fix MSI-X control register offset in legacy mode\n\nIn legacy mode when checking if MSI-X is enabled to calculate the\ndevice-specific region offset, the code accesses the base of the MSI-X\ncapability structure instead of the Message Control register and, if\nthe Next Pointer value exceeds 0x80, the subsequent check of\nPCI_MSIX_CTRL_ENABLE mask incorrectly evaluates to true.\n\nThis false positive forces an erroneous 24-byte base offset, shifting\nsubsequent configuration reads by 4 bytes. This manifests as a\nmangled MAC address during device probe (e.g. 34:56:01:00:ff:ff).\n\nFix the read offset to target the Message Control register.\n\nReported-by: Kent Konishi \u003ckonishi.kento@fujitsu.com\u003e\nSigned-off-by: Dario Faggioli \u003cdfaggioli@suse.com\u003e\nModified-by: Michael Brown \u003cmcb30@ipxe.org\u003e\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "b54689abd6f88460954954993835399dd816dc39", "tree": "062c8b54f1e27c2f2d6811e1e0ecfab5b255702a", "parents": [ "c2c1abc16a7d40df31dd73d7997fca028f01829b" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 15:52:23 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 15:52:23 2026 +0100" }, "message": "[cloud] Add utility to perform automated tests of AWS instance types\n\nAdd a utility that can be used to perform a fully automated test of a\nlist of AWS instance types.\n\nSuitable regions and AMIs are identified automatically. Results are\nreported by using iPXE to upload zero-length flag files to an S3\nbucket using pre-signed URIs passed in the userdata script.\n\nWe use single-instance fleets rather than standalone instances. This\nallows us to specify an expiry time after which any instances will be\nterminated automatically, even if the test script itself crashes.\n\nThis initial version of the test script verifies the ability to\ndownload a 1MB test file (created by the test itself and placed in the\nsame S3 bucket), and verifies that the interface survives being closed\nand reopened.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "c2c1abc16a7d40df31dd73d7997fca028f01829b", "tree": "f39c61c768ded68fa8c4b634e13a8b2f0ade3e56", "parents": [ "3e92a8ece06cd1fae8802df1a87762a03010938d" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 15:50:49 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 15:50:49 2026 +0100" }, "message": "[cloud] Enable digest commands in cloud boot images\n\nThe digest commands are useful for performing automated tests, and\ncloud boot images are not size-constrained.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "3e92a8ece06cd1fae8802df1a87762a03010938d", "tree": "902c806bd21bd93b8c98ec09142639deddda04e7", "parents": [ "000a4be30aafe7557a441b0a0e5c1e8b4a5364e4" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 15:41:05 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 15:41:05 2026 +0100" }, "message": "[cloud] Tag imported AWS images with commit ID\n\nThe imported AMI displays its commit ID as part of the startup banner,\nbut there is currently no sensible way to retrieve this information\nwithout booting the image.\n\nAdd a \"commit\" tag to hold the commit ID from which an imported AMI\nwas built, to allow automated tests to unambiguously identify the\ncommit being tested.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "000a4be30aafe7557a441b0a0e5c1e8b4a5364e4", "tree": "51e728150b4e3ef03400fe7e67ea014bbdb3a449", "parents": [ "9178834eda316cdf2449e7d21fe7468b19d8ffc0" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 15:17:26 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 15:23:15 2026 +0100" }, "message": "[build] Remove explicit section declarations for .note.GNU-stack\n\nThe .note.GNU-stack section is an irritant that we include only to\nsilence spurious warnings from the linker.\n\nGNU binutils 2.47 changes the type of this section from \"progbits\" to\nthe arguably more correct \"note\", which causes build failures due to\nthe existing explicit \"progbits\" declarations.\n\nRemove the section type declaration, allowing the toolchain to set the\nsection type to whatever it will later insist upon having.\n\nReported-by: Russ Kubes \u003crkubes@users.noreply.github.com\u003e\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "9178834eda316cdf2449e7d21fe7468b19d8ffc0", "tree": "90eb7cac6e6c2f21311a1367a791f47430c43191", "parents": [ "e5abb335ce39f9b43ce1de08612bf803da88a158" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 13:45:01 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 14:37:35 2026 +0100" }, "message": "[peerdist] Prefer peers discovered via IPv4\n\nExperiments show that Windows peers will randomly and erroneously fail\nretrieval protocol requests made over IPv6, reporting that the block\nis not present (by setting SizeOfBlock\u003d0 in the MSG_BLK response).\nThe exact same request made over IPv4 succeeds 100% of the time.\n\nRecord the most recently discovered peer separately for each discovery\nsocket, and attempt retrieval from the most recently discovered IPv4\npeer before attempting retrieval from the most recently discovered\nIPv6 peer. (In theory, an IPv6 address could be reported via the IPv4\ndiscovery socket (or vice versa), but experiments show that Windows\nwill report only addresses within the discovery socket family.)\n\nClear the most recently discovered peer when the discovery socket is\nclosed, since this is now a natural point at which to do so.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "e5abb335ce39f9b43ce1de08612bf803da88a158", "tree": "befe4c7c783cfd7d4f5b9532343446e32ed0599a", "parents": [ "3b29aa5d6d51dcf87c1c28273027a616458701be" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 14:28:34 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 14:28:34 2026 +0100" }, "message": "[peerdist] Avoid stack allocation for peer retrieval URIs\n\nThe peer location strings (i.e. the peer address for HTTP POST, or the\nbase URI for HTTP GET or local filesystem) are theoretically unbounded\nin size. Allocate these on the heap rather than on the stack.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "3b29aa5d6d51dcf87c1c28273027a616458701be", "tree": "eed6d6cd6dbdb20779b1a989e9981ea595036879", "parents": [ "11910d30d16953c890a032347ae700cc66c500cc" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 12:23:16 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 12:23:16 2026 +0100" }, "message": "[peerdist] Split peer and local filesystem cache download profilers\n\nSeparate the profilers used to record retrieval protocol downloads\nusing HTTP POST (i.e. downloads from a real peer, or from a hosted\ncache server) from retrieval protocol downloads using HTTP GET or\nequivalent (i.e. most likely coming from a local filesystem cache).\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "11910d30d16953c890a032347ae700cc66c500cc", "tree": "4f47e14c3833746a4813d202fd939a138a58be1d", "parents": [ "a5b48086254b1d0993bc50c64295575823236149" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 07 17:20:51 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 11:56:18 2026 +0100" }, "message": "[peerdist] Elide most discovery attempts\n\nIn theory, a PeerDist client should perform discovery for each\nsegment, and then attempt retrieval from any discovered peers.\n\nIn practice, the segment sizes chosen by the origin server are much\ntoo small for this theoretically correct approach to be viable. With\nthe typically observed PeerDist v2 segment size of around 64kB, the\ntotal time to retrieve a segment from a peer on a gigabit LAN is\naround 0.6ms. This is almost two orders of magnitude less than the\naverage peer discovery response delay of ~30ms recommended by the\nMS-PCCRD specification. This peer discovery response delay becomes\nthe dominant limiting factor in the overall download speed.\n\nIf a peer is already known to have one segment of a file, then there\nis an extremely high probability that it will have other segments of\nthe same file. We therefore optimistically attempt to retrieve a new\nsegment from whichever peer happens to have most recently responded to\na discovery request for any other segment, while simultaneously\nsending out a discovery request for the new segment. This allows the\noverall download to progress without being limited by the peer\ndiscovery response delay.\n\nThis introduces a new problem: we end up sending out a large volume of\ndiscovery requests that will end up being ignored because the segment\nhas already been fully retrieved before any peer sends a discovery\nresponse. Each discovery attempt generates around 1-10 network\npackets (depending on the number of peers): this would be negligible\nfor sensibly sized segments of around 2MB but represents an increase\nin traffic of up to 25% for the absurdly small 64kB segments typically\nobserved from a PeerDist v2 server.\n\nDiscovery requests are multicast XML documents, and impose a\nnon-negligible processing burden on each listening peer. With a 64kB\nsegment size, the amount of processing required to parse and respond\nto a discovery request vastly exceeds the amount of processing\nrequired to just send the segment via the retrieval protocol.\n\nFix by adding a delay before sending the initial discovery request for\neach new segment, in order to elide the sending of almost all\ndiscovery requests.\n\nWhen discovery is redundant (i.e. when we will have optimistically\nretrieved the whole segment before any discovery responses might\narrive), this initial delay is long enough to allow the pending\ndiscovery request to be cancelled before it is ever sent.\n\nWhen discovery is genuinely valuable (i.e. when our optimistic\nassumption that the most recently discovered peer also has the new\nsegment turns out to be incorrect), this initial delay still allows\nplenty of time for discovery to take place before we time out and\nattempt an origin server request.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "a5b48086254b1d0993bc50c64295575823236149", "tree": "63b1ff49bb6e5cb1e8104eba7dd7d4c4adf532f7", "parents": [ "bf16ea60140038323c3b1da8223cbc617db5492e" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 11:24:54 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 08 11:24:54 2026 +0100" }, "message": "[http] Avoid stack allocation for \"user:password\" string\n\nThe temporary \"user:password\" string constructed for HTTP Basic\nauthentication is theoretically unbounded in size. Allocate this on\nthe heap rather than on the stack.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "bf16ea60140038323c3b1da8223cbc617db5492e", "tree": "70c9c2a5a30ddd779b15dc32c240bb1bab423288", "parents": [ "9441e24e9eea7d0da5b05dba3fa3ea3cb3b22185" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 07 17:24:34 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 07 17:42:02 2026 +0100" }, "message": "[peerdist] Profile discovery attempts\n\nProfile the overall duration of each discovery attempt and the time\nuntil the first peer response, to provide some visibility into the\noverall discovery behaviour.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "9441e24e9eea7d0da5b05dba3fa3ea3cb3b22185", "tree": "1d2d5d436202011a0df973914e5c71e57f71a4ab", "parents": [ "e4c4826b5dbc47332de7de141ead7e20231ae157" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 07 17:41:33 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 07 17:41:33 2026 +0100" }, "message": "[peerdist] Add some timing jitter to discovery attempts\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "e4c4826b5dbc47332de7de141ead7e20231ae157", "tree": "bcaf52d8fe00776bc27d2e4c4edcdc887915c16b", "parents": [ "333316ba1d4098f1b899f8529c48659cd264fbb5" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 07 17:29:20 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 07 17:35:34 2026 +0100" }, "message": "[peerdist] Count number of discovery replies received\n\nThe emptiness or otherwise of the list of peers has not been a\nmeaningful test for whether or not discovery replies were received\never since commit 9b6ad2d (\"[peerdist] Assume that most recently\ndiscovered peer can be reused\").\n\nRecord the number of discovery replies received, and use this as the\ntest when deciding whether or not to reduce the discovery timeout.\n\nIgnore any errors arising when reporting a discovered peer: the return\nstatus from peerdisc_discovered() is relevant only when adding the\nhosted cache server (since if a hosted cached server is defined then\nno discovery will ever take place).\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "333316ba1d4098f1b899f8529c48659cd264fbb5", "tree": "40041e18e7254dffbba6b842756281ecbcecd648", "parents": [ "8865571f707388265e642dd4019cf8b735f4fb64" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 07 16:19:00 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Wed Oct 07 16:19:00 2026 +0100" }, "message": "[peerdist] Split retrieval protocol and raw block download profilers\n\nSeparate the profilers used to record retrieval protocol downloads\nfrom the profilers used to record raw block downloads from the origin\nserver.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "8865571f707388265e642dd4019cf8b735f4fb64", "tree": "7a2dd78224d7bff978faebf29881fce0a08d1893", "parents": [ "6262f1081fe185564e8ec8365a1d23597ec6e6f5" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Oct 04 16:56:51 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Oct 05 15:33:23 2026 +0100" }, "message": "[http] Include a zero request content length when applicable\n\nWe currently send a Content-Length request header only when the\ncontent length is non-zero. This breaks some use cases for a PUT\nrequest, such as uploading a zero-length file to AWS S3.\n\nFix by choosing whether or not to include a Content-Length request\nheader based on the request method.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "6262f1081fe185564e8ec8365a1d23597ec6e6f5", "tree": "3246efa91df1648e8b03738980634cd19ae95965", "parents": [ "0e98032adbd265c16fe49446eb99b21f13a6504e" ], "author": { "name": "David Yeske", "email": "dyeske@gmail.com", "time": "Wed Sep 30 17:49:15 2026 -0400" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Thu Oct 01 13:24:19 2026 +0100" }, "message": "[build] Add FreeBSD syslinux mbr.bin search path\n\nModified-by: Michael Brown \u003cmcb30@ipxe.org\u003e\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "0e98032adbd265c16fe49446eb99b21f13a6504e", "tree": "b179c3b29eea7bff3f98914ddcbd61cf8a337c25", "parents": [ "629e28b56c8d61f5c9251114c4d5b390b61857d1" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 29 14:49:10 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 29 15:18:31 2026 +0100" }, "message": "[efi] Place debug directory within .rodata section\n\nSome strict PE parsers will refuse a debug directory that lies within\nthe file headers (rather than within a defined section), and will fail\nto load the binary.\n\nPlace the debug directory at the start of the .rodata section for\niPXE, and at the start of the .data section for wimboot.\n\nThe debug directory irritatingly includes an RVA and a file offset,\nneither of which can be calculated by the linker. Update these fields\nat the time of running elf2efi, after having calculated the file\noffsets for each section.\n\nDebugged-by: Kansu Dincer \u003ckdincer@microsoft.com\u003e\nDebugged-by: Christian Nilsson \u003cnikize@gmail.com\u003e\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "629e28b56c8d61f5c9251114c4d5b390b61857d1", "tree": "0ec9e7ecbf960327e2e9f66cca5af4886ca0dc91", "parents": [ "744cdb451ef28bc894df72b6b40fdf1fda04acfc" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 27 16:52:23 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 27 17:41:57 2026 +0100" }, "message": "[peerdist] Allow for retrieving blocks from a local filesystem cache\n\nThe MS-PCCRR specification defines an HTTP POST request/response pair\nfor retrieving an encrypted block from a peer (with the decryption\nkeys provided separately via the content information).\n\nThe HTTP POST request parameters serve only to identify the block: the\nactual response body is effectively a static encrypted blob.\n\nDefine an additional (non-standard) retrieval protocol in which the\nblock is identified solely using the request URI, with the response\nbeing the same content that would be returned as the HTTP POST\nresponse body. This allows for encrypted blocks to be retrieved from\na static source such as AWS S3 or a local FAT filesystem, without\nrequiring a peer that can understand the retrieval protocol HTTP POST\nrequest format.\n\nDefine the static request URI format as:\n\n \u003cbase\u003e/xx/xxyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy-b.blk\n\nwhere\n\n - `xxyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy` is the segment ID (HoHoDK)\n as a lower-case hexadecimal string\n\n - `xx` is the first two characters (i.e. the first byte) of the\n segment ID\n\n - `b` is the block index within the segment (which will always\n be zero when using MS-PCCRC version 2 content information), as\n an unpadded decimal string\n\n - the extension `.blk` represents a block file\n\nThis path format is designed to allow for efficient storage in a local\nFAT filesystem (by limiting both the number of directories and the\nnumber of entries within each directory).\n\nAllow a base cache directory to be specified via the ${peerpath}\nsetting, e.g.\n\n set peerpath file:/peercache\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "744cdb451ef28bc894df72b6b40fdf1fda04acfc", "tree": "0bbafb335224fb1dbfc28a8cbad3216a17c67aee", "parents": [ "f35f5977c65d5adcdc6b187e0a3a7ac802e625c8" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 16:17:41 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 22:37:11 2026 +0100" }, "message": "[tls] Add support for TLS version 1.3 HelloRetryRequest\n\nWhen the server does not want to use the key exchange algorithm\noffered in our ClientHello, it may respond with a HelloRetryRequest\nthat specifies a new key exchange algorithm.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "f35f5977c65d5adcdc6b187e0a3a7ac802e625c8", "tree": "b2e385fff1fe7ed89b844c1028f464abd40cedef", "parents": [ "b49d0492494d9ca906fbe2d1fc49fe9a7640a4ef" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 16:11:45 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 22:36:54 2026 +0100" }, "message": "[tls] Refuse to change selected protocol version or cipher suite\n\nHandling a TLS version 1.3 HelloRetryRequest will require processing\ntwo ServerHello messages, the second of which must not reset the\nrunning transcript digest (and is not permitted to change the selected\ncipher suite).\n\nMove the responsibility for setting the protocol version alongside the\nresponsibility for setting the cipher suite in tls_select_cipher(),\nand refuse to change either protocol version or cipher suite if they\nhave already been selected.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "b49d0492494d9ca906fbe2d1fc49fe9a7640a4ef", "tree": "38a7f82188186b990ff689f7169cbb7de86c17db", "parents": [ "23d6038c7ab5e7a4114d5eb8a61aaa56d1723e51" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 18:37:40 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 18:41:41 2026 +0100" }, "message": "[tls] Record verification length separately from cipher suite\n\nFor a renegotiation, we currently rely on the previously selected\ncipher suite to determine the length of the verification data. This\nis the only context in which the recorded cipher suite does not\nrepresent the selected cipher suite for the current connection.\n\nRecord the verification length separately as part of the verification\ndata structure, allowing the selected cipher suite to be cleared when\nrestarting the connection so that it unambiguously represents the\ncurrently selected cipher suite at all times.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "23d6038c7ab5e7a4114d5eb8a61aaa56d1723e51", "tree": "0b8d4567d8c55309f2a2260362c6fc3bf8b6c36d", "parents": [ "d2a9fbe7b9b4182868808d52fee3f986a057ae34" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 14:39:04 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 16:30:59 2026 +0100" }, "message": "[tls] Generalise mechanism for duplicating a TLS cursor\n\nGeneralise the mechanism used for storing a session ticket to allow\nfor storing copies of arbitrary TLS cursors.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "d2a9fbe7b9b4182868808d52fee3f986a057ae34", "tree": "c085ffdd5b84e21af542029a2f1753f9198c8215", "parents": [ "4aabb077efa48fdbca90fe6bd833a7a20ab937aa" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 13:01:17 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 16:30:59 2026 +0100" }, "message": "[tls] Always use zfree() rather than free()\n\nTLS currently uses free() instead of zfree() where the memory being\nfreed contains no secrets. The cost of using zfree() everywhere is\nnegligible (no code size increase, and used only in non-fast-path\noperations), and avoids the need to reason about whether or not the\nmemory contains secrets.\n\nSwitch to using zfree() unconditionally throughout the TLS code.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "4aabb077efa48fdbca90fe6bd833a7a20ab937aa", "tree": "a5031831cd69fdf65448653fe5fecb472b41939d", "parents": [ "21d972d7415a08c94156021fec4f4b80614e8b66" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 15:57:38 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 16:30:56 2026 +0100" }, "message": "[crypto] Add support for the TLS \"message_hash\" synthetic record\n\nOn receiving a HelloRetryRequest, the running transcript hash gets\nreplaced with a synthetic message of type \"message_hash\" containing\nthe current value of the running transcript hash (which at that point\ncovers only the initial ClientHello).\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "21d972d7415a08c94156021fec4f4b80614e8b66", "tree": "b6d0160b6f0a7d4ac7e6798c6dee717ad185ae69", "parents": [ "0367d099261fc4abec8076ff3e9e0109cc0969ec" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 12:03:31 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 12:10:48 2026 +0100" }, "message": "[crypto] Check length before decrypting data\n\nUsing a CBC-mode cipher with a length that is not a multiple of the\nblock size will cause an uncontrollable out-of-bounds write of the\nentire address space, resulting in a guaranteed crash. There is no\nway to cause the CBC cipher to return before overwriting the entire\naddress space with pseudorandom data, and so this could only be used\nas a denial-of-service attack.\n\nAlmost all cipher call sites already validate the length against the\nblock size. Add the relevant checks to the two call sites that do not\nalready do so.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "0367d099261fc4abec8076ff3e9e0109cc0969ec", "tree": "7bc68e1f9daac675b8a85753e0e2dba91bb9b128", "parents": [ "2b6bd7660bf85315cacc84254fb0096b83bfc2b2" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 10:18:51 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 10:35:08 2026 +0100" }, "message": "[test] Ensure that all TLS structure descriptor mappings are valid\n\nConstructing exhaustive standalone tests for all TLS structures is\ntime-consuming and of limited value, since there would be no guarantee\nthat the construction logic used in the test case matched the\nconstruction logic matched in the real TLS protocol engine.\n\nWe already exercise each failure path that can be triggered by genuine\nruntime errors (e.g. malformed received data, or transmit data that is\ntoo large to fit within the relevant length field). This leaves\nuntested the other major class of errors: an invalid structure\ndescriptor mapping (e.g. a missing field description) that would\nrender the structure impossible to parse or build.\n\nExercise the parser and builder for every structure type by creating\nan all-zero descriptor (which is always permitted), sizing and\nbuilding the empty structure, and then parsing that structure. This\nensures that the parser and builder are both satisfied that the\ndescriptor mapping is valid, since the validity of the mapping is\nindependent of the data being built or parsed.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "2b6bd7660bf85315cacc84254fb0096b83bfc2b2", "tree": "dc6c802986e22a8809c94c07f331cefbd7f7831b", "parents": [ "1037cf358fa1f9be298342ff6645cf940fdf6853" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 10:03:45 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Tue Sep 22 10:15:01 2026 +0100" }, "message": "[tls] Remove redundant null pointer check\n\nThe recorded key exchange group is selected at initialisation and can\nnever be set to NULL, in the same way that the cipher suite can never\nbe set to NULL (and is therefore not checked at the points of use).\n\nRemove the redundant null pointer check, since it simply serves to\nconfuse readers of the code.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "1037cf358fa1f9be298342ff6645cf940fdf6853", "tree": "d2cf1dad242ec2c0d24598e87a140a466f5203d2", "parents": [ "194306d45771e1abbf5a4567ae5a543f9d3de45d" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 21 23:02:04 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 21 23:02:04 2026 +0100" }, "message": "[tls] Allow session to be saved multiple times\n\nTLS version 1.3 defers the NewSessionTicket until after the handshake\nhas completed, and allows the server to send multiple NewSessionTicket\nmessages (e.g. to refresh short-lived tickets).\n\nThe default session ID generated in tls_save() will currently end up\nwith the same value on each invocation. While session IDs are unused\nin TLS version 1.3, this could lead to confusing debug messages and\npacket captures.\n\nAdd a function tls_random() to generate random nonces using the\nchannel ephemeral secret, a label, and a 64-bit counter, and this\nfunction to generate unique session IDs.\n\nNon-sequential record IVs are also generated using channel ephemeral\nsecrets. Simplify this code by using tls_random() instead of a direct\ncall to channel_ephemeral().\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "194306d45771e1abbf5a4567ae5a543f9d3de45d", "tree": "f95db2e9c077b7bca5e11e4e317a9aae57e0259e", "parents": [ "ed4a9b2e673718c04f9d7ab1f523aff150f4376a" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 21 18:09:05 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 21 18:16:19 2026 +0100" }, "message": "[crypto] Ignore any data digested before TLS key schedule is started\n\nThe initial ClientHello is sent and digested before the key schedule\nhas been started (since the digest algorithm is not known until the\nServerHello arrives).\n\nA server that sends a premature ServerHello with an all-zero nonce\nbefore the ClientHello is sent can currently cause the key schedule\u0027s\n\"nonced\" flag to become set. The flag will be reset when the key\nschedule is started and so this is unclean but harmless.\n\nFix by ignoring any data that arrives before the digest algorithm has\nbeen set (i.e. before the key schedule has been started), since the\nnull digest algorithm cannot meaningfully incorporate anything into a\nrunning transcript digest.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "ed4a9b2e673718c04f9d7ab1f523aff150f4376a", "tree": "055c8eba39ed5e0e727c04de7d656605eda97abc", "parents": [ "b36e8472d4ba661db1608e8fe211bc30031a28ba" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 21 12:53:18 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 21 17:48:06 2026 +0100" }, "message": "[tls] Clear any saved state when saving a new session\n\nIf the server switches from providing stateless session tickets to\nproviding stateful session IDs, then we will currently end up with a\nstored session that retains the old session ticket along with the new\nsession ID. (This behaviour has been observed when connecting to an\nApache server that requires per-directory client authentication or\nper-directory cipher suites: the server originally provides a\nstateless session ticket but then, after renegotiation to request the\nclient certificate, provides a stateful session ID instead.)\n\nReset both the session ID and the session ticket whenever a new\nsession is saved (i.e. if the server provides either a new session ID\nor a new session ticket), so that we do not retain stale credentials.\n\nIf no new session ID is provided, then create a new random session ID\n(rather than leaving the session with an empty session ID) since we\nrely on the echoed non-empty session ID to determine whether or not\nthe server is choosing to resume, even for stateless sessions.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "b36e8472d4ba661db1608e8fe211bc30031a28ba", "tree": "e8bd63594aa54dae885f963637dd1d33fc704a2c", "parents": [ "2e549711c2bc406e3ebc72eeb503458cbd5d2e7b" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 10:03:52 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 21 00:23:03 2026 +0100" }, "message": "[tls] Use standalone TLS data structure builder\n\nDefine structure descriptors and mappings for every data structure\ncurrently sent by the TLS protocol engine, and use the standalone data\nstructure builder to remove a large amount of open-coded layout and\nassembly logic.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "2e549711c2bc406e3ebc72eeb503458cbd5d2e7b", "tree": "30bcb5dc02e7607bc9692d102e85563f1804f87c", "parents": [ "69c5cbea7741eaac5670315d5e56f4c50465733c" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 20:18:50 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 20:33:15 2026 +0100" }, "message": "[tls] Use server certificate\u0027s own public key algorithm for verification\n\nFor TLS version 1.1 (without explicit signature hash algorithm\nidentifiers), we currently use the cipher suite\u0027s public key algorithm\nwhen verifying the ServerKeyExchange signature. This is indirectly\nguaranteed to match the server certificate\u0027s own public key algorithm.\n\nUse the server certificate\u0027s own public key algorithm directly, to be\nconsistent with the behaviour for client certificates. The signed\ncertificate is, by definition, the authoritative source for its own\nchoice of public key algorithm.\n\nThis leaves the public key algorithm aspect of the cipher suite as\nbeing unused outside of debug messages. We do not enforce the\nspecification that the certificate\u0027s public key algorithm must match\nthe cipher suite\u0027s public key algorithm (if any) because doing so\nserves no cryptographic purpose. For TLS version 1.2 and later, the\nexplicit signature hash algorithm identifiers override the cipher\nsuite, and in TLS version 1.3 the whole concept of a public key\nalgorithm is removed from the scope of the cipher suite.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "69c5cbea7741eaac5670315d5e56f4c50465733c", "tree": "4605883ed3832cbcdc69ada253927c4667089b3e", "parents": [ "76f7b88f93dde7880b274bc0691b8d9d5763f627" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 15:11:50 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 15:11:50 2026 +0100" }, "message": "[tls] Use client certificate\u0027s own public key algorithm for signing\n\nMirroring commit cbdb572 (\"[crypto] Use certificate\u0027s own public key\nalgorithm for key matching\"), the client CertificateVerify is also\ncurrently constructed using the certificate\u0027s signature algorithm\n(i.e. the public key algorithm of the issuer\u0027s key) rather than the\ncertificate\u0027s own public key algorithm.\n\nFix by using the certificate\u0027s own public key algorithm.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "76f7b88f93dde7880b274bc0691b8d9d5763f627", "tree": "cb1bc8427f35ecfc2bf977543fcd7794b7b46768", "parents": [ "cbdb57278df01e2410ffe7ec0ca78f238342fe2c" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 13:54:45 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 14:39:41 2026 +0100" }, "message": "[crypto] Allow for signable MD5 or SHA-1 digests with TLS version 1.1\n\nFor TLS version 1.1, non-RSA signed digests use SHA-1 instead of\nMD5+SHA1. Commit f095adb (\"[tls] Use SHA-1 for TLS version 1.1 ECDSA\nsignatures\") selected the correct digest algorithm for both server and\nclient authentication.\n\nHowever, the key schedule currently refuses to generate client\nCertificateVerify digests for any digest algorithm other than\nMD5+SHA1, on the basis that only the MD5+SHA1 running transcript\ndigest value is available.\n\nAn MD5+SHA1 digest value is just the concatenation of an MD5 digest\nvalue with a SHA-1 digest value, and so the SHA-1 digest value can be\nprovided for use with ECDSA client certificates.\n\nFix by special-casing the SHA-1 (and MD5) algorithms when generating a\nsignable digest value from the TLS version 1.1 key schedule.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "cbdb57278df01e2410ffe7ec0ca78f238342fe2c", "tree": "61c728d243aa94a25d6861fa0e355c858e254171", "parents": [ "cff60d28d6908ff0b8e350472e0842596a6391b2" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 14:24:32 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 14:39:41 2026 +0100" }, "message": "[crypto] Use certificate\u0027s own public key algorithm for key matching\n\nWhen finding the certificate corresponding to a private key, the match\nis currently performed using the certificate\u0027s signature algorithm\n(i.e. the public key algorithm of the issuer\u0027s key) rather than the\ncertificate\u0027s own public key algorithm. This breaks key matching for\nheterogenous certificate chains (e.g. an ECDSA client certificate\nissued by an RSA intermediate certificate).\n\nFix by using the certificate\u0027s own public key algorithm.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "cff60d28d6908ff0b8e350472e0842596a6391b2", "tree": "1af7b8ae4e78034a140045a6935a3b151b372c0c", "parents": [ "b4d9949db1565a968d4f153fa499c2d926564c1a" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 14:09:28 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 14:39:41 2026 +0100" }, "message": "[build] Allow for non-RSA private keys\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "b4d9949db1565a968d4f153fa499c2d926564c1a", "tree": "b1578ff2fd661b7a4a582b5f749547e4c7c9206f", "parents": [ "65450656e502c2456b9b32b9dff09152f2a754b8" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 09:54:00 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 20 14:39:41 2026 +0100" }, "message": "[tls] Propagate sizing errors to containing data structures\n\nThe existing ad hoc code that builds TLS data structures generally\nperforms a single length calculation and a single allocation, and if\nthe allocation succeeds then the data structure will be filled in with\nno possible further errors arising.\n\nAllow this pattern to be replicated when using the generic builder, by\nensuring that an error in calculating the length of a contained data\nstructure (e.g. an extension) will automatically propagate that error\nto the calculation of the length of the containing structure (e.g. a\nClientHello that contains the extension).\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "65450656e502c2456b9b32b9dff09152f2a754b8", "tree": "e3dca96051ccb7afb72d74eaa13b55d5f47eacd4", "parents": [ "05fa85324108b3241fc3317289b9e4c92ddb0e58" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sat Sep 19 11:53:36 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sat Sep 19 12:48:31 2026 +0100" }, "message": "[tls] Add a standalone TLS data structure builder\n\nProvide a generic builder that can construct an arbitrary TLS data\nstructure based upon the same descriptors and binary-encoded mappings\nas used for the generic parser.\n\nThe design allows for the caller to either provide data in advance or\nto write through the descriptor pointers after building the data\nstructure. For example: this will allow the public key within a\nClientHello to be populated in situ within the key_share extension,\nrather than requiring the caller to allocate and populate a temporary\nbuffer before building the ClientHello.\n\nThis necessitates removing the \"const\" from all pointers within the\ndescriptors, which is a worthwhile tradeoff for the sake of avoiding a\nlarge number of temporary allocations.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "05fa85324108b3241fc3317289b9e4c92ddb0e58", "tree": "cdf7d91b3bc377e6a101dcf3b5b9378303774217", "parents": [ "42826fa9d9b8e37605427ec6cbd50f9e1167afca" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 21:55:17 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 22:52:19 2026 +0100" }, "message": "[tls] Allow for an empty list of extensions of interest\n\nThe binary encoding used by the TLS data structure parser currently\ncannot correctly express the concept of an extensions field unless\nthere is at least one extension of interest. An extensions field that\nhas zero extensions of interest ends up being encoded as just a\nstandard variable-length field.\n\nThis effectively makes any such extensions fields non-optional, since\nthe test for optionality can only detect fields with a non-zero number\nof extensions of interest. (This is a somewhat hypothetical issue,\nsince the only optional extension fields are found in ClientHello and\nServerHello, both of which have extensions of interest.)\n\nAdjust the encoding to allow extensions fields to be identified even\nif there are no extensions of interest therein.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "42826fa9d9b8e37605427ec6cbd50f9e1167afca", "tree": "cad49f6b7a639d1e79a7e6061ef6be8eb1dd65b4", "parents": [ "f095adbed2c5d2e4e0a178b2f604344f30dd2513" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 17:05:11 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 19:24:00 2026 +0100" }, "message": "[build] Allow MD5+SHA1 algorithm to be discarded at link time\n\nAll symbol references to the MD5+SHA1 algorithm will be eliminated if\nTLS_VERSION_MIN is set to a version greater than TLS version 1.1.\n\nHowever, the dummy RSA digestInfo prefix is retained since it is a\nlinker table entry. This dummy prefix object holds a pointer to the\nMD5+SHA1 algorithm and so prevents it from being garbage collected by\nthe linker.\n\nRemove the dummy empty RSA digestInfo prefix and instead allow a\ndigest to be encoded without any prefix for the MD5+SHA1 digest\nalgorithm.\n\nUse a custom test to allow the MD5+SHA1 algorithm to be identified\nwithout using a symbol reference to md5_sha1_algorithm, since even a\nweak reference would suffice to cause the symbol to be retained once\nsome other object drags it in to the build, and this is essentially\nguaranteed to happen: tlskey_md5_sha1 drags in md5_sha1_algorithm,\nwhich causes any existing weak references to be promoted to strong\nreferences, and those strong references remain even if tlskey_md5_sha1\nis later garbage collected.\n\nThe custom test uses a one-byte sentinel in .bss to give us a unique\nvalue to place in digest-\u003epriv: this can then be used to identify\nMD5+SHA1 without any symbol reference to md5_sha1_algorithm.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "f095adbed2c5d2e4e0a178b2f604344f30dd2513", "tree": "35e4e7d4253ca1a31faa7053880cdd55d15e347a", "parents": [ "6deb51d66c9f279e46553b6e67a090027a173c0a" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 16:19:02 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 16:38:24 2026 +0100" }, "message": "[tls] Use SHA-1 for TLS version 1.1 ECDSA signatures\n\nWe currently use the MD5+SHA1 algorithm for all signatures when using\nTLS version 1.1. This is incorrect for ECDSA (or for any non-RSA\npublic-key algorithm): these should instead use SHA-1.\n\nFix by using SHA-1 for any non-RSA public-key algorithm for TLS\nversion 1.1.\n\nProvide a weak rsa_algorithm symbol to use in the comparison, to avoid\nunconditionally dragging in RSA support.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "6deb51d66c9f279e46553b6e67a090027a173c0a", "tree": "260c66b8c272d37452330cdc9b6875669f10e742", "parents": [ "8402079a17ea0b415b590640d7d75755b812eee0" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 16:04:14 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 16:17:15 2026 +0100" }, "message": "[tls] Avoid dragging in MD5+SHA1 algorithm unconditionally\n\nUse a version check to gate the selection of md5_sha1_algorithm as the\nsignature digest algorithm, since this can be optimised out at build\ntime if the minimum version has been configured to be higher than TLS\nversion 1.1.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "8402079a17ea0b415b590640d7d75755b812eee0", "tree": "5c64574474e247dd5c3f87b70462a8d8cbe146c3", "parents": [ "89cfb681a45fefb68ce63ea240c88a6e2ad81728" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 14:18:58 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 15:02:38 2026 +0100" }, "message": "[tls] Use standalone TLS data structure parser\n\nUse the standalone data structure parser to remove a large amount of\nopen-coded parsing and bounds checking logic.\n\nWe retain the simple open-coded check for the handshake data structure\nitself, since tls_new_handshake() needs to be able to treat partially\nreceived data as valid (and defer processing until enough data is\navailable to cover a complete handshake).\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "89cfb681a45fefb68ce63ea240c88a6e2ad81728", "tree": "bbe23b0c0c9fae690b826083af42e561283caaca", "parents": [ "1135b796609a7713916d8b1e26bbd2312bd9404d" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 13:51:49 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 15:01:14 2026 +0100" }, "message": "[tls] Add a standalone TLS data structure parser\n\niPXE originally supported only TLS version 1.0, which uses mostly\nfixed-size data structures and required only a few mostly simple\nbounds checks.\n\nOver the years, the amount of open-coded parsing and bounds checking\ncode has grown gradually to the point that it comprises a substantial\nportion of the overall TLS implementation. This makes the code\ndifficult to read, and requires careful review to ensure that all of\nthe different parsing and bounds checking code is correct.\n\nDefine an abstraction for decomposing the component parts of a TLS\ndata structure into a descriptor structure comprising a sequence of\nfield data pointers and lengths, along with an efficient binary\nencoding that can describe the mapping between the decomposition and\nthe raw data structure.\n\nProvide a generic parser that can interpret the binary-encoded mapping\nand populate the descriptor structure, along with mappings for every\ndata structure currently interpreted by the TLS protocol engine.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "1135b796609a7713916d8b1e26bbd2312bd9404d", "tree": "fce0eca36a79d03151601b662e5bb303e6f141cf", "parents": [ "01081fd9111d0098e49b213cb39a21aaa5c7b319" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 14:49:45 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 15:01:12 2026 +0100" }, "message": "[tls] Fix building with TLS_VERSION_MAX set to TLS version 1.1\n\nCommit 356bb14 (\"[tls] Detect version downgrade attacks\") introduced a\nbuild failure under -Werror and -Wtype-limits when TLS_VERSION_MAX is\nset to TLS_VERSION_TLS_1_1 due to the constructed test that checks if\nan unsigned integer is less than zero.\n\nDowngrade attack detection is impossible anyway when the maximum\nversion offered is TLS version 1.1, and so this always-false test is\nperfectly correct: the desired outcome is that the downgrade detection\nis optimised out at build time.\n\nFix the build error by adjusting the comparison to be performed using\nsigned integers to avoid the -Wtype-limits check. Add a separate\ncheck that the maximum version is higher than TLS_VERSION_TLS_1_1 to\nensure that the whole downgrade detection code block is optimised out\nas dead code if it cannot ever be reached.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "01081fd9111d0098e49b213cb39a21aaa5c7b319", "tree": "e6fc78b1451c6a708dc33619a900b44da16cc516", "parents": [ "7cd92e01d6514b2c8091999f9bce8aef22a1d586" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 12:43:21 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Fri Sep 18 12:52:57 2026 +0100" }, "message": "[libc] Set return type for byte-swapping macros regardless of endianness\n\nWhen the byte-swapping macros are no-ops (i.e. when they match the\nplatform\u0027s native endianness), the type of the parameter is used\ndirectly as the type of the expression. This can result in the type\nof the expression differing between little-endian and big-endian\nplatforms.\n\nFix by including a cast within the no-op variants, so that the type of\nthe expression is consistent across all platforms.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "7cd92e01d6514b2c8091999f9bce8aef22a1d586", "tree": "65b985a162ab346a7e43657811aacf10528805b1", "parents": [ "267445294af9d9146ac9a916e5e846983ff1ad92" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 22:47:45 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 22:47:45 2026 +0100" }, "message": "[tls] Handle TLS version 1.3 client Finished\n\nThe TLS version 1.3 client Finished is somewhat messy to handle: its\nverify_data must be calculated with the key schedule still holding the\nclient handshake traffic secret, the application traffic secret must\nbe calculated before the client Finished is added to the transcript\ndigest, and the application traffic keys must be activated only after\nsending the client Finished. Since the action of sending the client\nFinished also adds the client Finished to the transcript digest, this\nnecessitates an awkward sequence of events. (A cleaner protocol\ndesign might have chosen to derive the client application traffic\nsecret from the transcript digest up to and including the client\nFinished.)\n\nPerform the various necessary contortions to construct the client\nFinished and to transition to using the application traffic secrets.\n\nWith this commit, TLS version 1.3 is functional for the first time.\nIt is not yet enabled by default, since there are still some missing\nfeatures such as session resumption.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "267445294af9d9146ac9a916e5e846983ff1ad92", "tree": "27fef134ec0aeafcd1116f320dae257b1990d43d", "parents": [ "ba64f5d2fb218f263c0a24eb04a42fc9a5c39cf8" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 22:37:42 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 22:42:55 2026 +0100" }, "message": "[tls] Do not schedule sending of unused records in TLS version 1.3\n\nThe ClientKeyExchange record does not exist in TLS version 1.3 (since\nkey exchange happens instead via ClientHello).\n\nThe Change Cipher record does not exist in TLS version 1.3, at least\nnot in the form of something that can be transmitted via the normal\nactive cipher.\n\nSkip scheduling both of these records for transmission.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "ba64f5d2fb218f263c0a24eb04a42fc9a5c39cf8", "tree": "1696802aae04fa733b9172952d2df8fb6de5ac9f", "parents": [ "78851666b3e9e88b4d2fe578c55df84a5dfe7ff8" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 22:34:44 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 22:34:44 2026 +0100" }, "message": "[tls] Ignore TLS version 1.3 NewSessionTicket\n\nSession resumption in TLS version 1.3 is structurally different from\nTLS version 1.2, and will not initially be supported.\n\nIgnore any NewSessionTicket records for now, since they will otherwise\ncause the connection to be aborted.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "78851666b3e9e88b4d2fe578c55df84a5dfe7ff8", "tree": "57a563c206004c8f05f130eae8505a8efd037ef7", "parents": [ "8087d6ac2296a400afc8f0f81da04e5ca72329ce" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 22:29:41 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 22:31:20 2026 +0100" }, "message": "[tls] Handle TLS version 1.3 server Finished\n\nWhen a certificate chain is provided, the TLS version 1.3 server\nFinished provides the point at which we can start validating the\ncertificate chain, equivalent to the ServerHelloDone in TLS version\n1.2 and earlier.\n\nThe TLS version 1.3 server Finished also provides a convenient point\nat which we can calculate the master secret, and defines the point at\nwhich we must schedule the receive cipher to transition to using the\napplication traffic key.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "8087d6ac2296a400afc8f0f81da04e5ca72329ce", "tree": "99808d2cb65ea38c531d907ddd0c1f2121c41386", "parents": [ "9077d45852e82db96e282e45cae09af21b3f6d60" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 22:26:03 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 22:26:03 2026 +0100" }, "message": "[tls] Transition to handshake traffic keys after receiving ServerHello\n\nThe ServerHello provides the earliest point at which the handshake\ntraffic keys can be generated, and the defined point at which the\nreceive cipher must transition to using the handshake traffic key.\n\nWe do not intend to support sending early data, and so this also\nprovides a convenient point at which to transition the tranmit cipher\nto using the handshake traffic key.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "9077d45852e82db96e282e45cae09af21b3f6d60", "tree": "96a3425cc87b432d634a49955e554a82f0a7eaea", "parents": [ "7655629db0b015066ee3bb18b90162503c745f8b" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 22:12:00 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 22:22:21 2026 +0100" }, "message": "[tls] Allow for scheduled traffic phase changes\n\nThere are several point within the TLS version 1.3 handshake sequence\nat which a handshake message handler needs to transition one or both\nciphers to a new traffic phase, but the new cipher keys cannot be\ncalculated by the key schedule until the triggering handshake message\nhas been added to the transcript digest.\n\nHandshake messages are added to the transcript digest only after the\nmessage handler returns, to accommodate the fact that the transcript\ndigest algorithm cannot be known until the initial ServerHello has\nbeen processed.\n\nAllow a new traffic phase to be recorded in the cipher specification,\nwhich will be activated after the handshake message handlers have\nreturned.\n\nChanging traffic phase requires changing the cipher in use, and so is\npermitted only for the last handshake message in a handshake record.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "7655629db0b015066ee3bb18b90162503c745f8b", "tree": "9028d84bc6ddcd6d5cdeffd10a16eea723d44660", "parents": [ "c2e9bd951a4273df22610b19f8d20963ea42fb42" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 19:00:13 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 19:57:17 2026 +0100" }, "message": "[tls] Allow for variable-length verification data\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "c2e9bd951a4273df22610b19f8d20963ea42fb42", "tree": "a154bd2b569cf9ecb1c4fffdb10533bf5380556f", "parents": [ "14c23c5bb89fa0da44e840e3a821daf136c6b928" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 16:55:11 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 18:22:49 2026 +0100" }, "message": "[tls] Add support for binding via a CertificateVerify record\n\nThe format of the signature found within a CertificateVerify is\nidentical to the format of the signature within a ServerKeyExchange.\n\nAbstract out the logic for verifying a ServerKeyExchange and use it to\nverify the signature for both ServerKeyExchange and CertificateVerify.\n\nNote that a CertificateVerify that is erroneously received under TLS\nversion 1.2 will always fail verification because the key schedule is\nnot able to generate a signable digest for the server endpoint.\n\nA ServerKeyExchange that is erroneously received under TLS version 1.3\nwill fail validation because the TLS version 1.3 cipher suites provide\nno way to parse the ServerKeyExchange parameters. (An interestingly\ndeviant server that chooses to negotiate TLS version 1.3 with a TLS\nversion 1.2 cipher suite would be able to send a ServerKeyExchange\nwith a valid signature and have that key contribute accumulatively to\nthe key schedule: this would not conform to the protocol, but does not\nactually weaken any of the security properties required to establish\nthe secure channel.)\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "14c23c5bb89fa0da44e840e3a821daf136c6b928", "tree": "5180d168637c8939fee3921904988cd24b0a9af7", "parents": [ "d646c9257447e94878cb64ac0837ffdc02949040" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 15:49:47 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 16:23:11 2026 +0100" }, "message": "[tls] Add support for parsing TLS version 1.3 Certificate record\n\nThe TLS version 1.3 Certificate record includes a certificate request\ncontext and an arbitrary list of extensions, both of which we ignore.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "d646c9257447e94878cb64ac0837ffdc02949040", "tree": "8a3daeb7fcbaee3c307579bd2bfa9b5225efbaa8", "parents": [ "47b934676a28afb2be2775b1819e6f8ddf15c56f" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 15:31:31 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 16:16:46 2026 +0100" }, "message": "[tls] Handle inner plaintext for TLS version 1.3\n\nTLS version 1.3 masquerades as TLS version 1.2 on the wire for the\nbenefit of badly engineered firewalls and other intermediate devices\nthat attempt to inspect the protocol stream.\n\nOnce a non-plaintext cipher is in use, all records masquerade as\napplication data, with the unencrypted record comprising the real\nrecord content followed by the real type byte and an arbitrary amount\nof zero padding.\n\nExtract the inner plaintext on receive, and create the simplest\npossible inner plaintext (with no zero padding) on transmit.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "47b934676a28afb2be2775b1819e6f8ddf15c56f", "tree": "6366413baf8f058edc40fd343b9faef5835f443e", "parents": [ "6872d143d67c10a60fa4eb740b528e01cc4f2793" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 14:28:32 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 15:51:17 2026 +0100" }, "message": "[tls] Allow support for newer TLS versions to be optimised out\n\nThe TLS version check already optimises down to a compile-time\nconstant if the specified version is guaranteed by the configured\nminimum supported version.\n\nExtend this check to also take into account the configured maximum\nsupported version.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "6872d143d67c10a60fa4eb740b528e01cc4f2793", "tree": "71ffea3189863c1f7762f75d337bba9924ad2b2d", "parents": [ "4ac73a5cbb016a9bcd4446a02d77e88c1a745833" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 13:01:14 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 13:56:59 2026 +0100" }, "message": "[tls] Discard received Change Cipher records under TLS version 1.3\n\nTLS version 1.3 allows unencrypted Change Cipher records to be sent\nafter switching to use the handshake traffic keys. This is an ugly\nprotocol hack to work around badly implemented firewalls of the kind\nbeloved by large organisations.\n\nIgnore and discard any such records, which would otherwise cause\ndecryption failures.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "4ac73a5cbb016a9bcd4446a02d77e88c1a745833", "tree": "1b5168a0cdbb6614548df42aca7131627ff2de47", "parents": [ "35a1abdbf85f8b74978da3c7feb7bbc9d21caed0" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 12:46:31 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 13:56:25 2026 +0100" }, "message": "[tls] Exclude sequence number from authentication for TLS version 1.3\n\nThe authentication header used for TLS version 1.3 no longer includes\nthe sequence number, since the use of sequential initialisation\nvectors renders it redundant.\n\nSkip authenticating this portion of the authentication header for TLS\nversion 1.3 or later.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "35a1abdbf85f8b74978da3c7feb7bbc9d21caed0", "tree": "ea8a14a600bcf5c336808db01891e8eaf68368df", "parents": [ "84af36a21bcec290763da89361af4ae059509405" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 12:33:57 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 13:55:08 2026 +0100" }, "message": "[tls] Allow for sequential cipher initialisation vectors\n\nThe CBC ciphers require a fully unpredictable initialisation vector,\nwhich we currently generate as a channel ephemeral secret. The GCM\nciphers require only a unique initialisation vector: there is no\nrequirement for it also to be unpredictable. The content of the\nrecord IV portion of the IV is a free choice of the sender, and we\ncurrently use an unpredictable value for both CBC and GCM.\n\nTLS version 1.3 removes the record IV portion for GCM ciphers, instead\nconstructing the IV by XORing the sequence number into the end of the\nfixed IV.\n\nDefine the concept of a sequential initialisation vector as meaning\nthat the sequence number is XORed into the end of the overall\ninitialisation vector (which may be either the fixed IV or the record\nIV portion), with no per-record unpredictable value required. This\nallows us to represent the mechanism required for TLS version 1.3, and\navoid the unnecessary cost of generating a channel ephemeral secret\nfor a GCM cipher under TLS version 1.2.\n\nOn the receive side, the XORed portion may be overwritten by the real\nrecord IV, since the sender\u0027s choice is always definitive for the\ncontents of the record IV.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "84af36a21bcec290763da89361af4ae059509405", "tree": "55df1a9050400db5d793f274fdcdfad6e00c37ba", "parents": [ "6f1646d7bd7aca1acec2602054006e6e73faa03d" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 12:29:12 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 12:29:12 2026 +0100" }, "message": "[tls] Limit to TLS version 1.2 in transmitted record headers\n\nTLS version 1.3 masquerades as TLS version 1.2 on the wire for the\nbenefit of badly engineered firewalls and other intermediate devices\nthat attempt to inspect the protocol stream.\n\nLimit the maximum version in transmitted record headers to be TLS\nversion 1.2. (Continue to accept any version in received record\nheaders, since this value has never had any significance.)\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "6f1646d7bd7aca1acec2602054006e6e73faa03d", "tree": "2db4ce7278929300efa1f338fa137932e0848b5e", "parents": [ "76e53bc23ff15c4ecc803b05f8f9632f26578f86" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 00:03:51 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 14 00:39:50 2026 +0100" }, "message": "[tls] Remove the concept of a pending cipher specification\n\nThe cipher specifications are currently modelled as an active cipher\nspecification that corresponds to the cipher currently in use by the\nsecure channel abstraction, and a pending cipher specification that\ncorresponds to the cipher that will be swapped in after the next\nChangeCipherSpec.\n\nThis design reflects the wording of RFC 2246 through to RFC 5246:\n\"there are always four connection states outstanding: the current read\nand write states, and the pending read and write states\".\n\nThis model does not map well to TLS version 1.3, with its multiple\nphases of traffic secrets and somewhat idiosyncratic choices of\ntranscript boundaries. The client Finished message is a particular\nproblem: the client application traffic secret must be calculated\nafter constructing the client Finished verify_data but before adding\nthe client Finished to the transcript digest (i.e. before encrypting\nit with the client handshake traffic keys). This is an irritating\nasymmetry with the server application traffic secret, which may be\ncalculated cleanly after the server Finished message has been added to\nthe transcript digest.\n\nSwitch to a model in which only the active cipher specification\nexists, and always corresponds to the cipher currently in use by the\nsecure channel abstraction.\n\nMove the record sequence number to become part of the cipher\nspecification, so that the sequence number reset logic can be shared\nbetween the transmit and receive paths.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "76e53bc23ff15c4ecc803b05f8f9632f26578f86", "tree": "2ad258924b28d77fcf03a5212535504b989dcbc6", "parents": [ "aaccac943697ef3f6e217a149b015c9d43b4d994" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 00:21:40 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 16:01:07 2026 +0100" }, "message": "[tls] Add support for the key share extension\n\nRFC 8446 defines the key_share extension as a mechanism for ephemeral\nkey exchange (replacing ServerKeyExchange and ClientKeyExchange).\n\nAdd support for sharing a key in our ClientHello and for parsing the\nshared key from a ServerHello. Construct the ClientHello on the heap\nrather than on the stack, since the shared key values may be large\n(e.g. for FFDHE4096).\n\nSelect the most preferred named group for sending the initial shared\nkey. (We do not yet handle a HelloRetryRequest: if the server chooses\na different named group then we will record this group but do not yet\nsupport sending the second ClientHello.)\n\nWe do not explicitly reject a key share extension received from a\nserver that negotiated TLS version 1.2 or lower. Any such key will be\nsuccessfully used to establish a shared secret (and so the secure\nchannel will become keyed), but there is no way for this shared secret\nto subsequently be successfully bound to the server\u0027s identity: a\nServerKeyExchange would replace the shared secret (since the TLS\nversion 1.2 key schedule is not accumulative), and a CertificateVerify\nwould fail to generate a signable digest.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "aaccac943697ef3f6e217a149b015c9d43b4d994", "tree": "bc910db898a7fa93b16dcf850f14cf828a31f34e", "parents": [ "d703617cc48bff99fe0599d1720f88e8cddaf60d" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 13:17:56 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 15:58:21 2026 +0100" }, "message": "[tls] Add ClientHello to transcript before selecting named group\n\nThe TLS version 1.3 ClientHello includes a key_share extension whose\nvalue will depend upon the selected key exchange named group. The\nincorporation of the initial ClientHello into the selected handshake\ndigest must therefore be done before the named group is potentially\nmodified.\n\nMove responsibility for adding the initial ClientHello to the\ntranscript digest from tls_new_server_hello() to tls_select_cipher(),\nso that this can be done before updating the selected named group.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "d703617cc48bff99fe0599d1720f88e8cddaf60d", "tree": "667ecfb986b4897cb164a5e96bd555cc4c4eb875", "parents": [ "744d9e8b568be565013236286fc724d22934cf66" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 13:45:00 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 15:58:21 2026 +0100" }, "message": "[tls] Handle TLS version 1.3 session ID echoing\n\nRFC 8446 redefines the session ID within a TLS version 1.3 ServerHello\nas being a field that must always echo the session ID from ClientHello\n(and no longer indicates that session resumption is taking place), as\na workaround for badly engineered middleware boxes.\n\nSkip ID-based session resumption if the negotiated version is TLS\nversion 1.3 or later, and instead abort the connection if the session\nID is not echoed verbatim (as per the RFC).\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "744d9e8b568be565013236286fc724d22934cf66", "tree": "42c491743e2ca10675861f5d4204ae729a255856", "parents": [ "30f0db898a90d8bb7a44965633ae7c12be54190c" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 14:18:43 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 15:58:21 2026 +0100" }, "message": "[tls] Use HKDF-based key schedule for TLS version 1.3 or later\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "30f0db898a90d8bb7a44965633ae7c12be54190c", "tree": "09a2ebe989f41fc5a79cf920df921a5b109c5f42", "parents": [ "7a3b423f6942a507c78dbb40ce6bb944f986a398" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 14:59:50 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 15:58:17 2026 +0100" }, "message": "[crypto] Refuse to allow zero-length ServerKeyExchange parameters\n\nThe signable digest value is used to bind the server identity to the\nshared secret, and so the digest must be computed over the parameters\nused to establish the shared secret.\n\nFor both endpoints in TLS version 1.3 and for the client endpoint in\nTLS version 1.2, the digest is computed over the running transcript\nhash and so already includes the parameters used to establish the\nshared secret.\n\nFor the server endpoint in TLS version 1.2, the digest is computed\nover only the client and server random bytes plus any additional data\npassed in by the caller, and so this additional data must include the\nparameters used to establish the shared secret.\n\nThe signable digest value for the server endpoint is currently\ncomputed only in response to a ServerKeyExchange record, in which case\nthe additional data correctly contains the parameters from that record\nthat were used to establish the shared secret.\n\nAdding support for TLS version 1.3 will necessitate adding the ability\nto parse a received CertificateVerify record, which will attempt to\nconstruct a signable digest value with no additional data.\n\nRequire additional data to be provided when constructing a signable\ndigest value for the server endpoint using the TLS version 1.2 key\nschedule, to prevent a CertificateVerify from potentially being used\nto verify a digest that was not computed over the parameters used to\nestablish the shared secret.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "7a3b423f6942a507c78dbb40ce6bb944f986a398", "tree": "4f3c8ca9d237c47c1dfc5282a40f51275515c7f0", "parents": [ "356bb14f33a6be17ac3f7883d09436b7ab7f9067" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 15:35:42 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 15:55:37 2026 +0100" }, "message": "[crypto] Ensure TLS signable digests cover a shared secret\n\nThe signable digest value is used to bind the server identity to the\nshared secret, and so the digest must be computed over the parameters\nused to establish the shared secret in order to be meaningful.\n\nThe secure channel will refuse to bind the peer identity on the basis\nof a verified signable digest if the channel does not already contain\nkey material derived from a shared secret.\n\nA signable digest that was erroneously constructed before a shared\nsecret was applied is therefore guaranteed to be unusable for binding\nthe channel, provided that the caller uses a sensible sequence of\noperations (i.e. constructs the signable digest and then immediately\nattempts to use it to bind the peer identity).\n\nStrengthen this guarantee further by refusing to generate a signable\ndigest value unless the key schedule already contains key material.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "356bb14f33a6be17ac3f7883d09436b7ab7f9067", "tree": "93c7af56423c9a369ed8cf5ca49629f66e7299f9", "parents": [ "f26cb52f16af5ce43a6a912c1cdfd01894021baf" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 11:02:16 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 11:34:35 2026 +0100" }, "message": "[tls] Detect version downgrade attacks\n\nRFC 8446 defines a mechanism that allows (but does not guarantee) the\ndetection of version downgrade attacks, based on magic signature\nvalues placed within the ServerHello random bytes. The magic\nsignature will be present if the server supports any version higher\nthan the negotiated version, and so may be present if the server\nsupports a higher version than we are offering.\n\nThe last byte of the magic signature is non-constant and is defined to\nmatch the server\u0027s negotiated protocol version, encoded as a delta\nfrom the value 0x0302 representing TLS version 1.1 (or lower). Since\nthe server random bytes are always used in the construction of\nverify_data (even in older versions of TLS without the extended master\nsecret), this encoding of the negotiated version cannot be forged by\nan attacker.\n\nIf the version that is negotiated is lower than the version that we\noffered (i.e. if a downgrade attack could possibly be happening), then\ncheck for the range of magic signatures that could indicate a\ndowngrade attack, and terminate the connection if applicable.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "f26cb52f16af5ce43a6a912c1cdfd01894021baf", "tree": "76ab9e3f34d5ce47101a0f26668fe4aab5671a01", "parents": [ "79df48adae1a53b09ef9747d46d90c9f6e4706ff" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sat Sep 12 23:36:07 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 11:27:04 2026 +0100" }, "message": "[tls] Add support for the supported versions extension\n\nRFC 8446 caps the version number field in ClientHello and ServerHello\nto represent at most TLS version 1.2, as a workaround for badly\nengineered servers and middleware boxes. The actual protocol version\nis instead negotiated via the supported_versions extension.\n\nSend the list of supported versions in the ClientHello, and parse the\nselected version from the supported_version extenion if present in the\nServerHello.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "79df48adae1a53b09ef9747d46d90c9f6e4706ff", "tree": "88aae914400960556dfd8f6c0f4b9ec11f17e0dc", "parents": [ "dbdbaa871c30210292c086e09e5004a818f1b64f" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sat Sep 12 23:05:01 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 11:26:40 2026 +0100" }, "message": "[tls] Add definitions for TLS version 1.3 cipher suites\n\nRFC 8446 redefines the concept of a cipher suite for TLS version 1.3\nto exclude the key exchange algorithm, leaving it specifying only the\nblock cipher algorithm and the handshake digest algorithm.\n\nAdd definitions for the two cipher suites that we can currently\nsupport (TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384).\n\nWe define these as using the null key exchange algorithm. The null\nkey exchange algorithm will fail on any attempt at key agreement. A\nserver that attempts to rely on the key exchange algorithm implied by\nthe cipher suite (e.g. a server attempting to illegally use these\ncipher suites with TLS version 1.2) will therefore be unable to\nestablish a shared secret and so will not be able to cause the secure\nchannel to become established.\n\nWe therefore do not explicitly check for and reject a server\u0027s attempt\nto negotiate a TLS version 1.3 cipher suite under TLS version 1.2 or\nearlier: the secure channel abstraction already ensures that such a\nnegotiation is doomed to failure.\n\nUnder TLS version 1.3, the cipher suite\u0027s key exchange algorithm\nspecification will not be used. We therefore do not explicitly check\nfor and reject a server\u0027s attempt to negotiate a TLS version 1.2 or\nearlier cipher suite under TLS version 1.3 or later: we instead just\nignore the key exchange algorithm aspect of that cipher suite.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "dbdbaa871c30210292c086e09e5004a818f1b64f", "tree": "a1f96437ca6715695d8fef3d65dec5d24fc414d7", "parents": [ "ff6e52063e0b37062394fe37b9788af25175e7af" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 00:13:37 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 13 00:27:50 2026 +0100" }, "message": "[tls] Record named group rather than key exchange algorithm\n\nThe concept of a named group is currently relevant only at the point\nof parsing a ServerKeyExchange record to determine the key exchange\nalgorithm: once parsed, the group\u0027s numeric code is no longer required\nand so we currently record only the resulting key exchange algorithm.\n\nFor TLS version 1.3, the numeric code will also be needed when\nconstructing the key_share extension in the ClientHello.\n\nSwitch from recording the key exchange algorithm to recording the\nfunctionally equivalent named group, thereby making it possible to\nretrieve the numeric code when needed.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "ff6e52063e0b37062394fe37b9788af25175e7af", "tree": "84a0f3b492cdcce9fd2f3c1ebd9e7717270ea2ee", "parents": [ "0214e4391a809e9930350ee9d172806b5d26f852" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 07 14:25:33 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Mon Sep 07 15:14:39 2026 +0100" }, "message": "[crypto] Add AES acceleration using the Arm Cryptographic Extensions\n\nImplement AES hardware acceleration for AArch64 using the AES subset\nof the Cryptographic Extensions. All supported runtime environments\nalready allow for use of the SIMD/FP registers, and so the only\nrequired compiler quirk is to annotate the functions as being\npermitted to emit the AES instructions.\n\nFeature detection relies upon the ability to read the ID_AA64ISAR0_EL1\nsystem register. This works as expected in all supported runtime\nenvironments:\n\n - As a UEFI binary, we are running in a real EL1 and so can just\n read the system register for the current (and only active) core\n\n - As a Linux userspace binary running in EL0, the kernel (since\n 4.11) will emulate the read to report the subset of features that\n are supported by all online cores\n\n - As a Linux userspace binary run via QEMU\u0027s binary translation,\n QEMU (since 4.0.0) will similarly emulate the read to report the\n features supported by the selected CPU model\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "0214e4391a809e9930350ee9d172806b5d26f852", "tree": "3882fa5cd979f6b69521cbe750aacde9195e0837", "parents": [ "7ada3e0f04d0526747df5e0e46c05c94cbf7a7d1" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 06 10:05:41 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 06 23:47:24 2026 +0100" }, "message": "[crypto] Add support for AES-NI hardware acceleration\n\nImplement AES hardware acceleration for i386 and x86_64, using the\nAES-NI instructions (and the SSE2 \"pxor\" instruction for the initial\nAddRoundKey), using the unmodified existing key schedule as generated\nby aes_setkey().\n\nFor raw AES (ignoring the block cipher mode of operation), this\nresults in a speed improvement from approximately 20 cycles per byte\ndown to approximately 1 cycle per byte.\n\nThe AES-NI instructions use SSE registers. For the sake of not having\nto think about the possible consequences across all various runtime\nenvironments (BIOS/UEFI/Linux), we choose not to enable \"-msse\" in\nCFLAGS for this file. We include \".arch\" directives to ensure that\nthe assembler knows that it is permitted to emit the SSE2 and AES-NI\ninstructions, use a fixed \"%xmm0\" rather than an \"x\" constraint (which\nGCC would consider to be impossible without \"-msse\"), and restore the\nvalue of \"%xmm0\" after use to meet the requirements of the most\nrestrictive ABI for which this file can be built.\n\nIn an ideal world, we would also use a \".arch push\" / \".arch pop\" pair\nto restore the permitted instruction set, rather than leaving the SSE2\nand AES-NI instructions as permitted outside the scope of the inline\nasm. Unfortunately this feature would require binutils 2.34 or newer,\nand so would prevent building iPXE on some still-current distros such\nas RHEL8.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "7ada3e0f04d0526747df5e0e46c05c94cbf7a7d1", "tree": "d145e43ce893ffece18ff60f2bb05d40e504e274", "parents": [ "c4023b98e3161360dea488f438df4442c8ee4ad1" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sat Sep 05 17:01:40 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 06 19:46:31 2026 +0100" }, "message": "[crypto] Align AES round keys within the AES context\n\nSome AES hardware acceleration instructions require each 16-byte round\nkey to be aligned on a 16-byte boundary. Cipher contexts are byte\narrays allocated by the caller and do not have any guaranteed\nalignment.\n\nIncrease the AES context size to allow space for alignment padding,\nand align the context before use. Reduce the round count field from\nan unsigned int to a uint8_t, to minimise wasted space and to ensure\nthat the resulting padded context size is itself reasonably aligned.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "c4023b98e3161360dea488f438df4442c8ee4ad1", "tree": "45e09b64cc405e5751dc015ace4528d93b1b43a3", "parents": [ "d916dfcfaebb2382a943b4cbbdc81c796e2dc56b" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sat Sep 05 20:29:11 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 06 19:46:31 2026 +0100" }, "message": "[crypto] Allow for AES hardware acceleration\n\nAllow architectures to detect support for AES hardware acceleration at\nruntime and to replace the AES algorithm\u0027s encrypt() and decrypt()\nmethod pointers with hardware accelerated implementations.\n\nExtend the automated tests to run the AES tests twice: once with\nhardware acceleration explicitly disabled (to test the unaccelerated\nsoftware implementation) and once with acceleration re-enabled. Skip\nthe second test if no hardware acceleration is available: this avoids\nunnecessarily repeating the test of the unaccelerated implementation,\nand allows a non-zero test count for \"aes-hw\" to indicate that the\nhardware acceleration was tested. For example:\n\nOn a system that supports AES hardware acceleration:\n\n OK: \"aes\" 120 tests passed\n OK: \"aes-hw\" 120 tests passed\n\nOn a system that does not support AES hardware acceleration:\n\n OK: \"aes\" 120 tests passed\n OK: \"aes-hw\" 0 tests passed\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "d916dfcfaebb2382a943b4cbbdc81c796e2dc56b", "tree": "9eb2f7af3d3d81874c45120fae6578fa6b5ec18f", "parents": [ "f5828201ea95dff75f12d2db03dafc68ed03645a" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 06 14:39:12 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 06 19:43:49 2026 +0100" }, "message": "[librm] Enable the use of SSE instructions if supported by the CPU\n\nClear CR0.EM, clear CR0.TS, and set CR4.OSFXSR in order to allow the\nexecution of SSE instructions such as the AES-NI instructions for AES\nhardware acceleration.\n\nNote that we have to assert CR4.OSFXSR to allow these instructions to\nexecute, but our context switching logic (e.g. the protected-mode and\nlong-mode interrupt handlers) does not actually preserve the\nFPU/MMX/SSE registers.\n\nOur C code therefore cannot in general presume that the FPU/MMX/SSE\nregisters will be preserved across arbitrary context boundaries.\nHowever, since C code executes with interrupts disabled, an individual\nfunction may safely use temporary FPU/MMX/SSE registers provided that\nit does not enable interrupts or otherwise relinquish the context.\n\nFor the same C code to also be usable under the UEFI IA-32 ABI, it\nmust preserve all registers other than %eax, %ecx, and %edx, including\npreserving all MMX and XMM registers.\n\nThe practical upshot is therefore that C code may use SSE instructions\nand may assume that SSE registers will not be changed arbitrarily\nduring execution (either because the ABI guarantees preservation, as\nwith UEFI or Linux, or because the runtime environment guarantees that\ninterrupts are disabled), but the C code must itself restore the\nvalues of any modified FPU/MMX/SSE registers.\n\nThe \"fxsave\"/\"fxrstor\" performed by virt_call() would allow for a\nslightly more relaxed constraint if support for the UEFI IA-32 ABI\nwere ever to be dropped in future. A real-mode caller that is making\nuse of SSE must have already set OSFXSR, and so its non-64-bit\nregisters %xmm0-%xmm7 would already be saved and restored across\nvirt_call(). The tightest constraint would then become the UEFI X64\nABI, which defines %xmm0-%xmm5 as volatile (i.e. caller-saved): this\nwould allow C code in iPXE to use %xmm0-%xmm5 without needing to\nexplicitly save and restore their values.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "f5828201ea95dff75f12d2db03dafc68ed03645a", "tree": "d5e8b9c210828c2e9f3b27a93633028110a5913f", "parents": [ "a69ad342174ac0e6f82eb7859a2487affc0fa4d5" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 06 14:30:52 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 06 15:13:38 2026 +0100" }, "message": "[librm] Preserve CR0 across virt_call()\n\nClearing the CR0.EM and CR0.TS flags is a prerequisite for using the\nAES-NI instructions for AES hardware acceleration: if CR0.EM is set\nthen the CPU will raise an undefined-instruction exception, and if\nCR0.TS is set then the CPU will raise a device-not-available exception\n(expecting the OS to have installed an exception handler that would\nperform a deferred context switch of the FPU/MMX/SSE registers).\n\nPreserve CR0 across virt_call(), to allow the CR0.EM and CR0.TS flags\nto be modified as needed.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" }, { "commit": "a69ad342174ac0e6f82eb7859a2487affc0fa4d5", "tree": "0f48d2e620ae24ffc258f0c42cecf3d8d5f50ec9", "parents": [ "8f334fd55d1a037c4bb091685a62a339b95425ea" ], "author": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 06 14:06:32 2026 +0100" }, "committer": { "name": "Michael Brown", "email": "mcb30@ipxe.org", "time": "Sun Sep 06 15:13:38 2026 +0100" }, "message": "[librm] Preserve CR4 across virt_call() if FXSR is supported\n\nSetting the CR4.OSFXSR flag is a prerequisite for using the AES-NI\ninstructions for AES hardware acceleration: if this flag is not set\nthen the CPU will raise an undefined-instruction exception.\n\nWe currently preserve CR4 across virt_call() only for 64-bit builds,\nsince those will modify CR4 by setting CR4.PAE. Extend this to\npreserve CR4 across virt_call() if FXSR is supported, to allow the\nCR4.OSFXSR flag to be modified as needed.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n" } ], "next": "8f334fd55d1a037c4bb091685a62a339b95425ea" }