{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":47706861,"defaultBranch":"master","name":"ipxe","ownerLogin":"qemu","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2015-12-09T17:17:57.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/2137033?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1678802314.641171","currentOid":""},"activityList":{"items":[{"before":"bf25e23d07f16be62825650c0826c4eadf2699b6","after":"09e8a154084c57311463408e3f2e412c305a9638","ref":"refs/heads/coverity_scan","pushedAt":"2023-03-16T00:35:49.570Z","pushType":"push","commitsCount":1,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"[efi] Claim fixed device paths by uninstalling device path protocol\n\nAs documented in commits 6a004be (\"[efi] Support the initrd\nautodetection mechanism in newer Linux kernels\") and 04e60a2 (\"[efi]\nOmit EFI_LOAD_FILE2_PROTOCOL for a zero-length initrd\"), the choice in\nLinux of using a fixed device path requires bootloaders to allow for\nthe fact that a previous bootloader may have already installed a\nhandle with the fixed device path.\n\nWe currently deal with this situation by reusing the existing handle,\nreplacing the EFI_LOAD_FILE2_PROTOCOL instance with our own. Simplify\nthe code by instead uninstalling the EFI_DEVICE_PATH_PROTOCOL instance\nfrom the existing handle (if present), thereby allowing the creation\nof a new handle to succeed.\n\nCreate the new handle only if we have a non-empty initrd to provide.\nThis works around bugs in bootloaders such as the systemd EFI stub\nthat fail to allow for the existence of multiple-bootloader chains.\n(The workaround is not comprehensive: if the user has downloaded other\nimages in iPXE before invoking the systemd Unified Kernel Image (UKI),\nthen the systemd EFI stub will still crash and burn since it fails to\nallow for the fact that a previous bootloader has already installed a\nhandle with the fixed device path.)\n\nSigned-off-by: Michael Brown ","shortMessageHtmlLink":"[efi] Claim fixed device paths by uninstalling device path protocol"}},{"before":"bf25e23d07f16be62825650c0826c4eadf2699b6","after":"09e8a154084c57311463408e3f2e412c305a9638","ref":"refs/heads/master","pushedAt":"2023-03-15T17:32:14.084Z","pushType":"push","commitsCount":1,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"[efi] Claim fixed device paths by uninstalling device path protocol\n\nAs documented in commits 6a004be (\"[efi] Support the initrd\nautodetection mechanism in newer Linux kernels\") and 04e60a2 (\"[efi]\nOmit EFI_LOAD_FILE2_PROTOCOL for a zero-length initrd\"), the choice in\nLinux of using a fixed device path requires bootloaders to allow for\nthe fact that a previous bootloader may have already installed a\nhandle with the fixed device path.\n\nWe currently deal with this situation by reusing the existing handle,\nreplacing the EFI_LOAD_FILE2_PROTOCOL instance with our own. Simplify\nthe code by instead uninstalling the EFI_DEVICE_PATH_PROTOCOL instance\nfrom the existing handle (if present), thereby allowing the creation\nof a new handle to succeed.\n\nCreate the new handle only if we have a non-empty initrd to provide.\nThis works around bugs in bootloaders such as the systemd EFI stub\nthat fail to allow for the existence of multiple-bootloader chains.\n(The workaround is not comprehensive: if the user has downloaded other\nimages in iPXE before invoking the systemd Unified Kernel Image (UKI),\nthen the systemd EFI stub will still crash and burn since it fails to\nallow for the fact that a previous bootloader has already installed a\nhandle with the fixed device path.)\n\nSigned-off-by: Michael Brown ","shortMessageHtmlLink":"[efi] Claim fixed device paths by uninstalling device path protocol"}},{"before":"e5f02551735922eb235388bff08249a6f31ded3d","after":"09e8a154084c57311463408e3f2e412c305a9638","ref":"refs/heads/initrd","pushedAt":"2023-03-15T16:58:52.912Z","pushType":"push","commitsCount":251,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"[efi] Claim fixed device paths by uninstalling device path protocol\n\nAs documented in commits 6a004be (\"[efi] Support the initrd\nautodetection mechanism in newer Linux kernels\") and 04e60a2 (\"[efi]\nOmit EFI_LOAD_FILE2_PROTOCOL for a zero-length initrd\"), the choice in\nLinux of using a fixed device path requires bootloaders to allow for\nthe fact that a previous bootloader may have already installed a\nhandle with the fixed device path.\n\nWe currently deal with this situation by reusing the existing handle,\nreplacing the EFI_LOAD_FILE2_PROTOCOL instance with our own. Simplify\nthe code by instead uninstalling the EFI_DEVICE_PATH_PROTOCOL instance\nfrom the existing handle (if present), thereby allowing the creation\nof a new handle to succeed.\n\nCreate the new handle only if we have a non-empty initrd to provide.\nThis works around bugs in bootloaders such as the systemd EFI stub\nthat fail to allow for the existence of multiple-bootloader chains.\n(The workaround is not comprehensive: if the user has downloaded other\nimages in iPXE before invoking the systemd Unified Kernel Image (UKI),\nthen the systemd EFI stub will still crash and burn since it fails to\nallow for the fact that a previous bootloader has already installed a\nhandle with the fixed device path.)\n\nSigned-off-by: Michael Brown ","shortMessageHtmlLink":"[efi] Claim fixed device paths by uninstalling device path protocol"}},{"before":"9e1f7a3659071004f4b8c76f2593da6287f0d575","after":"bf25e23d07f16be62825650c0826c4eadf2699b6","ref":"refs/heads/coverity_scan","pushedAt":"2023-03-15T00:29:02.385Z","pushType":"push","commitsCount":3,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"[intel] Add workaround for I210 reset hardware bugs\n\nThe Intel I210's packet buffer size registers reset only on power up,\nnot when a reset signal is asserted. This can lead to the inability\nto pass traffic in the event that the DMA TX Maximum Packet Size\n(which does reset to its default value on reset) is bigger than the TX\nPacket Buffer Size.\n\nFor example, an operating system may be using the time sensitive\nnetworking features of the I210 and the registers may be programmed\ncorrectly, but then a reset signal is asserted and iPXE on the next\nboot will be unable to use the I210.\n\nMimic what Linux does and forcibly set the registers to their default\nvalues.\n\nSigned-off-by: Matt Parrella ","shortMessageHtmlLink":"[intel] Add workaround for I210 reset hardware bugs"}},{"before":"8f1c1201199a924eeba31494be5aa6bf13eb3fa0","after":"bf25e23d07f16be62825650c0826c4eadf2699b6","ref":"refs/heads/master","pushedAt":"2023-03-14T15:09:29.185Z","pushType":"push","commitsCount":1,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"[intel] Add workaround for I210 reset hardware bugs\n\nThe Intel I210's packet buffer size registers reset only on power up,\nnot when a reset signal is asserted. This can lead to the inability\nto pass traffic in the event that the DMA TX Maximum Packet Size\n(which does reset to its default value on reset) is bigger than the TX\nPacket Buffer Size.\n\nFor example, an operating system may be using the time sensitive\nnetworking features of the I210 and the registers may be programmed\ncorrectly, but then a reset signal is asserted and iPXE on the next\nboot will be unable to use the I210.\n\nMimic what Linux does and forcibly set the registers to their default\nvalues.\n\nSigned-off-by: Matt Parrella ","shortMessageHtmlLink":"[intel] Add workaround for I210 reset hardware bugs"}},{"before":null,"after":"e86398d36474ddfc666af5f7644c8deafefbac5f","ref":"refs/heads/mtureset","pushedAt":"2023-03-14T13:58:34.641Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"WIP - cleaner MTU change","shortMessageHtmlLink":"WIP - cleaner MTU change"}},{"before":"9e1f7a3659071004f4b8c76f2593da6287f0d575","after":"8f1c1201199a924eeba31494be5aa6bf13eb3fa0","ref":"refs/heads/master","pushedAt":"2023-03-14T11:44:50.585Z","pushType":"push","commitsCount":2,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"[dhcp] Unregister ProxyDHCP and PXEBS settings on a successful DHCPACK\n\nWhen a DHCP transaction does not result in the registration of a new\n\"proxydhcp\" or \"pxebs\" settings block, any existing settings blocks\nare currently left unaltered.\n\nThis can cause surprising behaviour. For example: when chainloading\niPXE, the \"proxydhcp\" and \"pxebs\" settings blocks may be prepopulated\nusing cached values from the previous PXE bootloader. If iPXE\nperforms a subsequent DHCP request, then the DHCP or ProxyDHCP servers\nmay choose to respond differently to iPXE. The response may choose to\nomit the ProxyDHCP or PXEBS stages, in which case no new \"proxydhcp\"\nor \"pxebs\" settings blocks may be registered. This will result in\niPXE using a combination of both old and new DHCP responses.\n\nFix by assuming that a successful DHCPACK effectively acquires\nownership of the \"proxydhcp\" and \"pxebs\" settings blocks, and that any\nexisting settings blocks should therefore be unregistered.\n\nReported-by: Henry Tung \nSigned-off-by: Michael Brown ","shortMessageHtmlLink":"[dhcp] Unregister ProxyDHCP and PXEBS settings on a successful DHCPACK"}},{"before":"99aad3903716ec9b01270d84b96ac5f1cb736265","after":"4b7ad95261eb5ab5c27ae0f2d4b0e57a6dcf79d0","ref":"refs/heads/shim","pushedAt":"2023-03-13T13:54:41.557Z","pushType":"push","commitsCount":1,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"WIP - shim","shortMessageHtmlLink":"WIP - shim"}},{"before":"b123d3287009df4b50fd38c266072fefe677a0bf","after":"99aad3903716ec9b01270d84b96ac5f1cb736265","ref":"refs/heads/shim","pushedAt":"2023-03-10T16:56:56.263Z","pushType":"push","commitsCount":1,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"WIP - shim","shortMessageHtmlLink":"WIP - shim"}},{"before":"2aef08b7a5fa98e5b309d47d933b5cd32a6feec0","after":"b123d3287009df4b50fd38c266072fefe677a0bf","ref":"refs/heads/shim","pushedAt":"2023-03-10T15:52:05.828Z","pushType":"push","commitsCount":1,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"WIP - shim","shortMessageHtmlLink":"WIP - shim"}},{"before":null,"after":"c390e287df2a47984a4b9facdf15a196de7ad597","ref":"refs/heads/cleardhcp","pushedAt":"2023-03-08T01:25:30.179Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"[dhcp] Unregister ProxyDHCP and PXEBS settings on a successful DHCPACK\n\nWhen a DHCP transaction does not result in the registration of a new\n\"proxydhcp\" or \"pxebs\" settings block, any existing settings blocks\nare currently left unaltered.\n\nThis can cause surprising behaviour. For example: when chainloading\niPXE, the \"proxydhcp\" and \"pxebs\" settings blocks may be prepopulated\nusing cached values from the previous PXE bootloader. If iPXE\nperforms a subsequent DHCP request, then the DHCP or ProxyDHCP servers\nmay choose to respond differently to iPXE. The response may choose to\nomit the ProxyDHCP or PXEBS stages, in which case no new \"proxydhcp\"\nor \"pxebs\" settings blocks may be registered. This will result in\niPXE using a combination of both old and new DHCP responses.\n\nFix by assuming that a successful DHCPACK effectively acquires\nownership of the \"proxydhcp\" and \"pxebs\" settings blocks, and that any\nexisting settings blocks should therefore be unregistered.\n\nReported-by: Henry Tung \nSigned-off-by: Michael Brown ","shortMessageHtmlLink":"[dhcp] Unregister ProxyDHCP and PXEBS settings on a successful DHCPACK"}},{"before":"523788ccdaff515194347b8e3f0c8de4dcbf221f","after":"9e1f7a3659071004f4b8c76f2593da6287f0d575","ref":"refs/heads/coverity_scan","pushedAt":"2023-03-08T00:52:52.529Z","pushType":"push","commitsCount":2,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"[image] Always unregister currently executing image\n\nWe unregister script images during their execution, to prevent a\n\"boot\" command from re-executing the containing script. This also has\nthe side effect of preventing executing scripts from showing up within\nthe Linux magic initrd image (or the Multiboot module list).\n\nAdditional logic in bzimage.c and efi_file.c prevents a currently\nexecuting kernel from showing up within the magic initrd image.\nSimilar logic in multiboot.c prevents the Multiboot kernel from\nshowing up as a Multiboot module.\n\nThis still leaves some corner cases that are not covered correctly.\nFor example: when using a gzip-compressed kernel image, nothing will\ncurrently hide the original compressed image from the magic initrd.\n\nFix by moving the logic that temporarily unregisters the current image\nfrom script_exec() to image_exec(), so that it applies to all image\ntypes, and simplify the magic initrd and Multiboot module list\nconstruction logic on the basis that no further filtering of the\nregistered image list is necessary.\n\nThis change has the side effect of hiding currently executing EFI\nimages from the virtual filesystem exposed by iPXE. For example, when\nusing iPXE to boot wimboot, the wimboot binary itself will no longer\nbe visible within the virtual filesystem.\n\nSigned-off-by: Michael Brown ","shortMessageHtmlLink":"[image] Always unregister currently executing image"}},{"before":null,"after":"2aef08b7a5fa98e5b309d47d933b5cd32a6feec0","ref":"refs/heads/shim","pushedAt":"2023-03-07T14:28:53.151Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"WIP - shim","shortMessageHtmlLink":"WIP - shim"}},{"before":"e51e7bbad7d043a6b369b0050ff4e1c0e62f3b5d","after":"9e1f7a3659071004f4b8c76f2593da6287f0d575","ref":"refs/heads/master","pushedAt":"2023-03-07T13:23:34.003Z","pushType":"push","commitsCount":1,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"[image] Always unregister currently executing image\n\nWe unregister script images during their execution, to prevent a\n\"boot\" command from re-executing the containing script. This also has\nthe side effect of preventing executing scripts from showing up within\nthe Linux magic initrd image (or the Multiboot module list).\n\nAdditional logic in bzimage.c and efi_file.c prevents a currently\nexecuting kernel from showing up within the magic initrd image.\nSimilar logic in multiboot.c prevents the Multiboot kernel from\nshowing up as a Multiboot module.\n\nThis still leaves some corner cases that are not covered correctly.\nFor example: when using a gzip-compressed kernel image, nothing will\ncurrently hide the original compressed image from the magic initrd.\n\nFix by moving the logic that temporarily unregisters the current image\nfrom script_exec() to image_exec(), so that it applies to all image\ntypes, and simplify the magic initrd and Multiboot module list\nconstruction logic on the basis that no further filtering of the\nregistered image list is necessary.\n\nThis change has the side effect of hiding currently executing EFI\nimages from the virtual filesystem exposed by iPXE. For example, when\nusing iPXE to boot wimboot, the wimboot binary itself will no longer\nbe visible within the virtual filesystem.\n\nSigned-off-by: Michael Brown ","shortMessageHtmlLink":"[image] Always unregister currently executing image"}},{"before":"523788ccdaff515194347b8e3f0c8de4dcbf221f","after":"e51e7bbad7d043a6b369b0050ff4e1c0e62f3b5d","ref":"refs/heads/master","pushedAt":"2023-03-07T12:17:54.810Z","pushType":"push","commitsCount":1,"pusher":{"login":"bonzini","name":"Paolo Bonzini","path":"/bonzini","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/42082?s=80&v=4"},"commit":{"message":"[image] Consistently use for_each_image() to iterate over images\n\nSigned-off-by: Michael Brown ","shortMessageHtmlLink":"[image] Consistently use for_each_image() to iterate over images"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAADBG_OIQA","startCursor":null,"endCursor":null}},"title":"Activity ยท qemu/ipxe"}