Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apply EKU check with compile option #664

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

dennis-tseng99
Copy link
Contributor

Implement the CodeSign EKU check to fulfill the requirements of NIAP OS_PP.
Also modify the ModSign EKU check to use VerifyEKUsInPkcs7Signature() to
check the signer certificate instead of the certificate directly from the
key database.

These commits supersede the PR#232 and PR#661 (Apply the EKU checks) and
separate the original author's codes from other commit so that the author's
original codes can be quite independent.

The author also answered the question in PR#232 and changed the conditional
statement to EFI_Status != EFI_SUCCESS right after VerifyEKUsInPkcs7Signature()
in Cryptlib/Pk/CryptPkcs7Verify.c

User can optionally enable codesign EKU check in compiling time.
To enable the codesign check, set ENABLE_CODESIGN_EKU to 1.
To disable the codesign check, set ENABLE_CODESIGN_EKU to 0
or just omit this flag.

For example:
make xxxx ENABLE_CODESIGN_EKU=1 xxxx shim.efi

lcp and others added 2 commits June 5, 2024 16:21
…OS_PP.

Also modify the ModSign EKU check to use VerifyEKUsInPkcs7Signature() to
check the signer certificate instead of the certificate directly from the
key database.

This commit supersedes the PR#232 and PR#661 (Apply the EKU checks) so
that author's original codes can be quite independent of other modification.

To answer the question in PR#232, author also changed the conditional
statement to EFI_Status != EFI_SUCCESS right after VerifyEKUsInPkcs7Signature()
in Cryptlib/Pk/CryptPkcs7Verify.c

Signed-off-by: Dennis Tseng <[email protected]>
This commit also supersedes PR#232 which was closed on Jul 1, 2021.
So that original codesign EKU codes cannot be bothered.

To enable the codesign check, ENABLE_CODESIGN_EKU can be set to 1.
To disable the codesign check, ENABLE_CODESIGN_EKU can be set to 0
or just omit this flag.

For example:
make xxxx ENABLE_CODESIGN_EKU=1 xxxx shim.efi

Signed-off-by: Dennis Tseng <[email protected]>
}

Status = CheckEKUs (SignerCert, RequiredEKUs, RequiredEKUsSize, RequireAllPresent);
if (Status != EFI_SUCCESS) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The correct idiom in EDK-2 code, also mainly used in shim, is if (EFI_ERROR(Status)). The reasoning is that various EDK-2 functions can also return warnings (which are positive non-zero values; negative non-zero values are errors). So unless one explicitly wants the code to stop on warnings and errors (not usual) one should use EFI_ERROR.

Apologies if I've misunderstood and there's a reason to stop on warnings. If not, the comment applies three times that I can see in this PR.

By the way, I'm an interested outsider, so don't take this as a definitive comment from the shim project, but I believe it's correct!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikebeaton Thanks for your comment. Although your suggestion is reasonable, we just want to keep consistency with the newest EDK-2 codes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your reply. Could you clarify (e.g. with a link)? Obviously I'm not insisting how it should be done in shim code, but my understanding is that what I suggested is and was how EDK-2 code is written.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, here is the EDK2 codes we referred to. Thanks so much.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, it is indeed done the same way here. Thank you for the clarification.

@vathpela
Copy link
Contributor

What's the rationale for this being conditional at build time? To me, it seems likely we either always want this or never do, but making it so some builds get it and some don't feels weird. Help me understand the criteria for choosing when I would want it enabled and disabled?

@joeyli
Copy link
Contributor

joeyli commented Jan 22, 2025

What's the rationale for this being conditional at build time? To me, it seems likely we either always want this or never do, but making it so some builds get it and some don't feels weird. Help me understand the criteria for choosing when I would want it enabled and disabled?

Hi vathpela,

Those two patches are for checking the Code Signing extendedKeyUsage field in X.509 certification. (OID 1.3.6.1.5.5.7.3.3)
It's for supporting NIAP PP_OS spec:

https://www.niap-ccevs.org/MMO/PP/PP_OS_V4.2.1.pdif

FIA_X509_EXT.1 X.509 Certificate Validation
[...snip]
The OS shall validate the extendedKeyUsage field according to the following
rules:
Certificates used for trusted updates and executable code integrity
verification shall have the Code Signing purpose (id-kp 3 with OID
1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.

And
FPT_TST_EXT.1 Boot Integrity
FPT_TST_EXT.1.1
Application Note: The bootchain of the OS is the sequence of software, to include
the OS loader, the kernel, system drivers or modules, and system files, which
ultimately result in loading the OS. The first part of the OS, usually referred to as the
first-stage bootloader, must be loaded by the platform. Assessing its integrity, while
critical, is the platform's responsibility; and therefore outside the scope of this PP. All
software loaded after this stage is potentially within the control of the OS and is in
scope.

If those patches be applied to shim and user's MOK or embedded key in shim does NOT have Code Signing EKU. Then the verification of second bootloader (grub2) and kernel will fail. Which means that the key can NOT be used to sign grub2 and kernel.

So we provide a build option for shim builder to enable or disable the Code Signing EKU feature when building. If shim builder wants to use this feature, they can add ENABLE_CODESIGN_EKU=1 when running make command.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants