iPXE is fundamentally asynchronous in operation: some operations
continue in the background even after the foreground has continued to
a new task. For example, the closing FIN/ACK exchanges of a TCP
connection will take place in the background after an HTTP download
has completed.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[http] Provide credentials only when requested by server
Provide HTTP Basic authentication credentials only in response to a
401 Unauthorized response from the server.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[http] Defer processing response code until after receiving all headers
Some headers can modify the meaning of the response code. For
example, a WWW-Authenticate header can change the interpretation of a
401 Unauthorized response from "Access denied" to "Please
authenticate".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Rename KEY= to PRIVKEY= and "key" to "privkey"
The setting name "key" conflicts with the setting name "key" already
in use by the 802.11 code. Resolve the conflict by renaming the newer
setting to "privkey".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Work around platforms which choke on EFI_PCI_DEVICE_ENABLE
EFI_PCI_DEVICE_ENABLE is a list of the standard attributes that must
be enabled for a PCI device to function: I/O cycles, memory cycles,
and bus-mastering. We currently call EFI_PCI_IO_PROTOCOL::Attribute()
with the parameter EFI_PCI_DEVICE_ENABLE to enable a PCI device. This
should translate to a single write to PCI configuration space.
Simplicity is not a virtue within the UEFI world. Some platforms will
'helpfully' report an error if EFI_PCI_DEVICE_ENABLE is used on a
device that doesn't actually support all three of the relevant
attributes. For example, if a PCI device provides only memory-mapped
accesses (and so hardwires the I/O enable bit to zero), then using
EFI_PCI_DEVICE_ENABLE on such a platform will result in an
EFI_UNSUPPORTED error.
There is no plausible use case in which it is useful for the platform
to return an error in this way, and doing so makes it impossible to
distinguish genuine errors from noise.
Work around this broken behaviour by attempting to enable the three
attributes individually, and ignoring any errors.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iSCSI generally includes a full SCSI response only when an error
occurs. iscsi_scsi_done() currently passes the NULL response through
to scsi_response(), which ends up causing scsicmd_response() to
dereference a NULL pointer.
Fix by calling scsi_response() only if we have a non-NULL response.
Reported-by: Brendon Walsh <brendonwalsh@niamu.com>
Tested-by: Brendon Walsh <brendonwalsh@niamu.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add support for constructing OCSP queries and parsing OCSP responses.
(There is no support yet for actually issuing an OCSP query via an
HTTP POST.)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
X.509 certificate processing currently produces an overwhelming amount
of debugging information. Move some of this from DBGLVL_LOG to
DBGLVL_EXTRA, to make the output more manageable.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Automatically attempt to download any required cross-signing
certificates from http://ca.ipxe.org/auto, in order to enable the use
of standard SSL certificates issued by public CAs.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
To allow for automatic download of cross-signing certificates and for
OCSP, the validation of certificates must be an asynchronous process.
Create a stub validator which uses a job-control interface to report
the result of certificate validation.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
CMS includes an unordered certificate set, from which certificates
must be extracted in order by matching up issuers with subjects. We
will use the same functionality as part of the automatic download of
cross-signing certificates. Generalise cms_find_subject() to
x509_find_subject(), and create x509_auto_append().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Allow certificate chains to be long-lived data structures
At present, certificate chain validation is treated as an
instantaneous process that can be carried out using only data that is
already in memory. This model does not allow for validation to
include non-instantaneous steps, such as downloading a cross-signing
certificate, or determining certificate revocation status via OCSP.
Redesign the internal representation of certificate chains to allow
chains to outlive the scope of the original source of certificates
(such as a TLS Certificate record).
Allow for certificates to be cached, so that each certificate needs to
be validated only once.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown