|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11 |
|
| #
02e2f9aa |
| 15-Sep-2024 |
Luca Boccassi <[email protected]> |
ipe: allow secondary and platform keyrings to install/update policies
The current policy management makes it impossible to use IPE
in a general purpose distribution. In such cases the users are not
ipe: allow secondary and platform keyrings to install/update policies
The current policy management makes it impossible to use IPE
in a general purpose distribution. In such cases the users are not
building the kernel, the distribution is, and access to the private
key included in the trusted keyring is, for obvious reason, not
available.
This means that users have no way to enable IPE, since there will
be no built-in generic policy, and no access to the key to sign
updates validated by the trusted keyring.
Just as we do for dm-verity, kernel modules and more, allow the
secondary and platform keyrings to also validate policies. This
allows users enrolling their own keys in UEFI db or MOK to also
sign policies, and enroll them. This makes it sensible to enable
IPE in general purpose distributions, as it becomes usable by
any user wishing to do so. Keys in these keyrings can already
load kernels and kernel modules, so there is no security
downgrade.
Add a kconfig each, like dm-verity does, but default to enabled if
the dependencies are available.
Signed-off-by: Luca Boccassi <[email protected]>
Reviewed-by: Serge Hallyn <[email protected]>
[FW: fixed some style issues]
Signed-off-by: Fan Wu <[email protected]>
show more ...
|
| #
5ceecb30 |
| 25-Sep-2024 |
Luca Boccassi <[email protected]> |
ipe: also reject policy updates with the same version
Currently IPE accepts an update that has the same version as the policy
being updated, but it doesn't make it a no-op nor it checks that the
old
ipe: also reject policy updates with the same version
Currently IPE accepts an update that has the same version as the policy
being updated, but it doesn't make it a no-op nor it checks that the
old and new policyes are the same. So it is possible to change the
content of a policy, without changing its version. This is very
confusing from userspace when managing policies.
Instead change the update logic to reject updates that have the same
version with ESTALE, as that is much clearer and intuitive behaviour.
Signed-off-by: Luca Boccassi <[email protected]>
Reviewed-by: Serge Hallyn <[email protected]>
Signed-off-by: Fan Wu <[email protected]>
show more ...
|
|
Revision tags: v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2 |
|
| #
ac673187 |
| 03-Aug-2024 |
Deven Bowers <[email protected]> |
documentation: add IPE documentation
Add IPE's admin and developer documentation to the kernel tree.
Co-developed-by: Fan Wu <[email protected]>
Signed-off-by: Deven Bowers <deven.desai@lin
documentation: add IPE documentation
Add IPE's admin and developer documentation to the kernel tree.
Co-developed-by: Fan Wu <[email protected]>
Signed-off-by: Deven Bowers <[email protected]>
Signed-off-by: Fan Wu <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
show more ...
|