|
| 1 | +- commits: |
| 2 | + - subject: Update layers/meta-balena to de218895272b288458d86bcba4358eb9a9558c17 |
| 3 | + hash: fa35d68d4de8b28128fd6a7b1c36c980560cbc55 |
| 4 | + body: Update layers/meta-balena |
| 5 | + footer: |
| 6 | + Changelog-entry: Update layers/meta-balena to de218895272b288458d86bcba4358eb9a9558c17 |
| 7 | + changelog-entry: Update layers/meta-balena to de218895272b288458d86bcba4358eb9a9558c17 |
| 8 | + author: balena-renovate[bot] |
| 9 | + nested: |
| 10 | + - commits: |
| 11 | + - subject: Update tests/leviathan digest to 81e7f26 |
| 12 | + hash: e3ff6305b8db606870bd8271d00010945e771288 |
| 13 | + body: Update tests/leviathan |
| 14 | + footer: |
| 15 | + Change-type: patch |
| 16 | + change-type: patch |
| 17 | + author: balena-renovate[bot] |
| 18 | + nested: |
| 19 | + - commits: |
| 20 | + - subject: Update balena-io/balena-cli to v20.2.7 |
| 21 | + hash: 451d57f30bf1e8b16b0a1bdacd9d0bd12b848b38 |
| 22 | + body: | |
| 23 | + Update balena-io/balena-cli from 20.2.1 to 20.2.7 |
| 24 | + footer: |
| 25 | + Change-type: patch |
| 26 | + change-type: patch |
| 27 | + author: balena-renovate[bot] |
| 28 | + nested: [] |
| 29 | + version: leviathan-2.31.90 |
| 30 | + title: "" |
| 31 | + date: 2025-02-25T23:03:19.812Z |
| 32 | + version: meta-balena-6.5.1 |
| 33 | + title: "" |
| 34 | + date: 2025-03-14T00:29:54.195Z |
| 35 | + - commits: |
| 36 | + - subject: "resin-init-flasher: Support devices using 3rd party UEFI drivers" |
| 37 | + hash: 892fd4f6083b5dc6248f6a83fcdf60dd2528e5ec |
| 38 | + body: > |
| 39 | + At this moment, if anything is measured into PCR2 (OpROMs, UEFI |
| 40 | + drivers) |
| 41 | + |
| 42 | + the device will provision, but not be able to boot the first |
| 43 | + time. |
| 44 | + |
| 45 | + This is because the EFI applications measured in PCR2 need to |
| 46 | + verify |
| 47 | + |
| 48 | + against `db`, which means they will be loaded during |
| 49 | + provisioning |
| 50 | + |
| 51 | + (while secure boot is still off), but won't be loaded once |
| 52 | + secure boot |
| 53 | + |
| 54 | + is enabled. This changes the value of PCR2 between provisioning |
| 55 | + |
| 56 | + and first boot, which means the encryption keys won't be |
| 57 | + released. |
| 58 | + |
| 59 | + |
| 60 | + This patch adds two new behaviors to flasher: |
| 61 | + |
| 62 | + * By default ignore the PCR2 hashes during secure boot |
| 63 | + provisioning, |
| 64 | + assuming none of the drivers will work with secure boot enabled. |
| 65 | + * After an opt-in, read the hashes present in PCR2 and enroll |
| 66 | + them into `db` during provisioning. |
| 67 | + |
| 68 | + The latter is an opt-in, as we have no control and no way to |
| 69 | + know |
| 70 | + |
| 71 | + what a UEFI driver does. Since these run at firmware level, they |
| 72 | + have |
| 73 | + |
| 74 | + enough privileges to bypass secure boot. All we can do is |
| 75 | + blindly |
| 76 | + |
| 77 | + whitelist everything present during provisioning, which might be |
| 78 | + seen |
| 79 | + |
| 80 | + as security risk, and the user should explicitly accept that. |
| 81 | + footer: |
| 82 | + Change-type: minor |
| 83 | + change-type: minor |
| 84 | + Signed-off-by: Michal Toman < [email protected]> |
| 85 | + signed-off-by: Michal Toman < [email protected]> |
| 86 | + author: Michal Toman |
| 87 | + nested: [] |
| 88 | + - subject: "efitools: Allow building an ESL from a list of hashes" |
| 89 | + hash: 3711e752054bc83ec869c0bd726157bf7fe8acb3 |
| 90 | + body: > |
| 91 | + At this moment hash-to-efi-sig-list only allows to add hash to |
| 92 | + an ESL |
| 93 | + |
| 94 | + if the whole EFI application is presented, but this is |
| 95 | + technically |
| 96 | + |
| 97 | + not necessary. We want to be able to use raw hashes, because |
| 98 | + |
| 99 | + for PCIe devices using 3rd party drivers, we only know the hash, |
| 100 | + |
| 101 | + the full EFI application or driver is not accessible to |
| 102 | + userspace. |
| 103 | + |
| 104 | + |
| 105 | + This patch adds support to use raw hashes to |
| 106 | + hash-to-efi-sig-list |
| 107 | + |
| 108 | + and ships the tool with efitools-utils. |
| 109 | + footer: |
| 110 | + Change-type: patch |
| 111 | + change-type: patch |
| 112 | + Signed-off-by: Michal Toman < [email protected]> |
| 113 | + signed-off-by: Michal Toman < [email protected]> |
| 114 | + author: Michal Toman |
| 115 | + nested: [] |
| 116 | + version: meta-balena-6.5.0 |
| 117 | + title: "" |
| 118 | + date: 2025-03-13T21:11:06.177Z |
| 119 | + - commits: |
| 120 | + - subject: Differentiate MACHINE from DEVICE_TYPE |
| 121 | + hash: 3fa237d98c8b4039f0616544686e4aba1a2d0839 |
| 122 | + body: > |
| 123 | + Allow for device type names and machine to differ. Until know, |
| 124 | + the |
| 125 | + |
| 126 | + device type contract had to be named `$MACHINE.json`, and then |
| 127 | + the |
| 128 | + |
| 129 | + slug in it could be something else. |
| 130 | + |
| 131 | + |
| 132 | + The DEVICE_TYPE variable that defaults to MACHINE for backwards |
| 133 | + |
| 134 | + compatibility allows for the same MACHINE to build several |
| 135 | + device types |
| 136 | + |
| 137 | + by passing a different DEVICE_TYPE to the build. |
| 138 | + footer: |
| 139 | + Change-type: patch |
| 140 | + change-type: patch |
| 141 | + Signed-off-by: Alex Gonzalez < [email protected]> |
| 142 | + signed-off-by: Alex Gonzalez < [email protected]> |
| 143 | + author: Alex Gonzalez |
| 144 | + nested: [] |
| 145 | + version: meta-balena-6.4.4 |
| 146 | + title: "" |
| 147 | + date: 2025-03-12T10:14:34.113Z |
| 148 | + version: 6.5.1 |
| 149 | + title: "" |
| 150 | + date: 2025-03-15T11:28:00.277Z |
1 | 151 | - commits:
|
2 | 152 | - subject: Fix Revolution Pi build by including missing rpi4-nvmem.cfg
|
3 | 153 | hash: 9c2f4c2ae56af4119f44c140e7216b02aad2b782
|
|
0 commit comments