This SEBoot update brings secure policy refactoring.
The old secure policies include
enforced: denotes key programmed and secure boot enable bit flipped.
soft: denotes everything else.
However, there should be another soft mode defined by the state that
customer key is programmed but the secure boot bit is not flipped. under
this mode SEBoot should validate the image against the OTP key, however
the failed validation should not prevent the device from continual
booting. This brings values for customer to have a final gate to check
if everything is working as expected.
Hence the refactored secure policies:
enforced: denotes key programmed and secure boot enable bit flipped.
soft: denotes key programmed but secure boot enable bit not flipped.
none: denotes everything else, i.e. neither the key nor the enable
bit is programmed.
This SEBoot update brings secure policy refactoring.
The old secure policies include
enforced: denotes key programmed and secure boot enable bit flipped.soft: denotes everything else.However, there should be another soft mode defined by the state that customer key is programmed but the secure boot bit is not flipped. under this mode SEBoot should validate the image against the OTP key, however the failed validation should not prevent the device from continual booting. This brings values for customer to have a final gate to check if everything is working as expected.
Hence the refactored secure policies:
enforced: denotes key programmed and secure boot enable bit flipped.soft: denotes key programmed but secure boot enable bit not flipped.none: denotes everything else, i.e. neither the key nor the enable bit is programmed.Signed-off-by: Baocheng Su baocheng.su@siemens.com