summaryrefslogtreecommitdiffstats
path: root/src/crypto/certstore.c
Commit message (Collapse)AuthorAgeFilesLines
* [build] Mark known reviewed files as permitted for UEFI Secure BootMichael Brown2026-01-141-0/+1
| | | | | | | | | Some past security reviews carried out for UEFI Secure Boot signing submissions have covered specific drivers or functional areas of iPXE. Mark all of the files comprising these areas as permitted for UEFI Secure Boot. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [init] Show initialisation function names in debug messagesMichael Brown2025-07-151-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Formalise mechanism for accessing absolute symbolsMichael Brown2025-05-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | In a position-dependent executable, where all addresses are fixed at link time, we can use the standard technique as documented by GNU ld to get the value of an absolute symbol, e.g.: extern char _my_symbol[]; printf ( "Absolute symbol value is %x\n", ( ( int ) _my_symbol ) ); This technique may not work in a position-independent executable. When dynamic relocations are applied, the runtime addresses will no longer be equal to the link-time addresses. If the code to obtain the address of _my_symbol uses PC-relative addressing, then it will calculate the runtime "address" of the absolute symbol, which will no longer be equal the the link-time "address" (i.e. the correct value) of the absolute symbol. Define macros ABS_SYMBOL(), ABS_VALUE_INIT(), and ABS_VALUE() that provide access to the correct values of absolute symbols even in position-independent code, and use these macros wherever absolute symbols are accessed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Accept and trust CA certificates in the TlsCaCertificates variableMichael Brown2025-03-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UEFI's built-in HTTPS boot mechanism requires the trusted CA certificates to be provided via the TlsCaCertificates variable. (There is no equivalent of the iPXE cross-signing mechanism, so it is not possible for UEFI to automatically use public CA certificates.) Users who have configured UEFI HTTPS boot to use a custom root of trust (e.g. a private CA certificate) may find it useful to have iPXE automatically pick up and use this same root of trust, so that iPXE can seamlessly fetch files via HTTPS from the same servers that were trusted by UEFI HTTPS boot, in addition to servers that iPXE can validate through other means such as cross-signed certificates. Parse the TlsCaCertificates variable at startup, add any certificates to the certificate store, and mark these certificates as trusted. There are no access restrictions on modifying the TlsCaCertificates variable: anybody with access to write UEFI variables is permitted to change the root of trust. The UEFI security model assumes that anyone with access to run code prior to ExitBootServices() or with access to modify UEFI variables from within a loaded operating system is supposed to be able to change the system's root of trust for TLS. Any certificates parsed from TlsCaCertificates will show up in the output of "certstat", and may be discarded using "certfree" if unwanted. Support for parsing TlsCaCertificates is enabled by default in EFI builds, but may be disabled in config/general.h if needed. As with the ${trust} setting, the contents of the TlsCaCertificates variable will be ignored if iPXE has been compiled with an explicit root of trust by specifying TRUST=... on the build command line. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow passing a NULL certificate store to x509_find() et alMichael Brown2024-08-131-4/+4
| | | | | | | | | | Allow passing a NULL value for the certificate list to all functions used for identifying an X.509 certificate from an existing set of certificates, and rename function parameters to indicate that this certificate list represents an unordered certificate store (rather than an ordered certificate chain). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Centralise mechanisms for identifying X.509 certificatesMichael Brown2024-08-121-50/+12Star
| | | | | | | | | Centralise all current mechanisms for identifying an X.509 certificate (by raw content, by subject, by issuer and serial number, and by matching public key), and remove the certstore-specific and CMS-specific variants of these functions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow private key to be specified as a TLS connection parameterMichael Brown2020-12-151-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Mark permanent certificates as permanentMichael Brown2016-08-311-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow certificates to be marked as having been added explicitlyMichael Brown2016-08-311-4/+19
| | | | | | | | Allow certificates to be marked as having been added explicitly at run time. Such certificates will not be discarded via the certificate store cache discarder. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Expose certstore_del() to explicitly remove stored certificatesMichael Brown2016-08-311-4/+15
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow assembler section type character to vary by architectureMichael Brown2016-03-131-1/+1
| | | | | | | | | | | | | | | On some architectures (such as ARM) the "@" character is used as a comment delimiter. A section type argument such as "@progbits" therefore becomes "%progbits". This is further complicated by the fact that the "%" character has special meaning for inline assembly when input or output operands are used, in which cases "@progbits" becomes "%%progbits". Allow the section type character(s) to be defined via Makefile variables. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Relicense files under GPL2_OR_LATER_OR_UBDLMichael Brown2015-03-021-1/+5
| | | | | | | Relicense files for which I am the sole author (as identified by util/relicense.pl). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Generalise X.509 cache to a full certificate storeMichael Brown2014-03-281-0/+275
Expand the concept of the X.509 cache to provide the functionality of a certificate store. Certificates in the store will be automatically used to complete certificate chains where applicable. The certificate store may be prepopulated at build time using the CERT=... build command line option. For example: make bin/ipxe.usb CERT=mycert1.crt,mycert2.crt Certificates within the certificate store are not implicitly trusted; the trust list is specified using TRUST=... as before. For example: make bin/ipxe.usb CERT=root.crt TRUST=root.crt This can be used to embed the full trusted root certificate within the iPXE binary, which is potentially useful in an HTTPS-only environment in which there is no HTTP server from which to automatically download cross-signed certificates or other certificate chain fragments. This usage of CERT= extends the existing use of CERT= to specify the client certificate. The client certificate is now identified automatically by checking for a match against the private key. For example: make bin/ipxe.usb CERT=root.crt,client.crt TRUST=root.crt KEY=client.key Signed-off-by: Michael Brown <mcb30@ipxe.org>