<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/lib/efi_loader, branch v2022.04-rc3</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>efi_loader: update the timing of enabling and disabling EFI watchdog</title>
<updated>2022-02-26T06:37:01+00:00</updated>
<author>
<name>Masahisa Kojima</name>
<email>masahisa.kojima@linaro.org</email>
</author>
<published>2022-02-22T00:58:30+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3fa9ed9ae3b30dd6e7f5e887c76d183ad72a44a2'/>
<id>3fa9ed9ae3b30dd6e7f5e887c76d183ad72a44a2</id>
<content type='text'>
UEFI specification requires that 5 minutes watchdog timer is
armed before the firmware's boot manager invokes an EFI boot option.
This watchdog timer is updated as follows, according to the
UEFI specification.

 1) The EFI Image may reset or disable the watchdog timer as needed.
 2) If control is returned to the firmware's boot manager,
    the watchdog timer must be disabled.
 3) On successful completion of EFI_BOOT_SERVICES.ExitBootServices()
    the watchdog timer is disabled.

1) is up to the EFI image, and 3) is already implemented in U-Boot.
This patch implements 2), the watchdog is disabled when control is
returned to U-Boot.

In addition, current implementation arms the EFI watchdog at only
the first "bootefi" invocation. The EFI watchdog must be armed
in every EFI boot option invocation.

Signed-off-by: Masahisa Kojima &lt;masahisa.kojima@linaro.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
UEFI specification requires that 5 minutes watchdog timer is
armed before the firmware's boot manager invokes an EFI boot option.
This watchdog timer is updated as follows, according to the
UEFI specification.

 1) The EFI Image may reset or disable the watchdog timer as needed.
 2) If control is returned to the firmware's boot manager,
    the watchdog timer must be disabled.
 3) On successful completion of EFI_BOOT_SERVICES.ExitBootServices()
    the watchdog timer is disabled.

1) is up to the EFI image, and 3) is already implemented in U-Boot.
This patch implements 2), the watchdog is disabled when control is
returned to U-Boot.

In addition, current implementation arms the EFI watchdog at only
the first "bootefi" invocation. The EFI watchdog must be armed
in every EFI boot option invocation.

Signed-off-by: Masahisa Kojima &lt;masahisa.kojima@linaro.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: test/py: Reset system after capsule update on disk</title>
<updated>2022-02-26T06:37:01+00:00</updated>
<author>
<name>Masami Hiramatsu</name>
<email>masami.hiramatsu@linaro.org</email>
</author>
<published>2022-02-16T06:16:12+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3e6f81000672e6d0d88fde9c7ad5b01414eccf86'/>
<id>3e6f81000672e6d0d88fde9c7ad5b01414eccf86</id>
<content type='text'>
Add a cold reset soon after processing capsule update on disk.
This is required in UEFI specification 2.9 Section 8.5.5
"Delivery of Capsules via file on Mass Storage device" as;

    In all cases that a capsule is identified for processing the system is
    restarted after capsule processing is completed.

This also reports the result of each capsule update so that the user can
notice that the capsule update has been succeeded or not from console log.

Signed-off-by: Masami Hiramatsu &lt;masami.hiramatsu@linaro.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a cold reset soon after processing capsule update on disk.
This is required in UEFI specification 2.9 Section 8.5.5
"Delivery of Capsules via file on Mass Storage device" as;

    In all cases that a capsule is identified for processing the system is
    restarted after capsule processing is completed.

This also reports the result of each capsule update so that the user can
notice that the capsule update has been succeeded or not from console log.

Signed-off-by: Masami Hiramatsu &lt;masami.hiramatsu@linaro.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: use efi_update_capsule_firmware() for capsule on disk</title>
<updated>2022-02-26T06:37:00+00:00</updated>
<author>
<name>Masami Hiramatsu</name>
<email>masami.hiramatsu@linaro.org</email>
</author>
<published>2022-02-16T06:15:42+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a6aafce494ab3d963485e6425f232a9224359556'/>
<id>a6aafce494ab3d963485e6425f232a9224359556</id>
<content type='text'>
Since the efi_update_capsule() represents the UpdateCapsule() runtime
service, it has to handle the capsule flags and update ESRT. However
the capsule-on-disk doesn't need to care about such things.

Thus, the capsule-on-disk should use the efi_capsule_update_firmware()
directly instead of calling efi_update_capsule().

This means the roles of the efi_update_capsule() and capsule-on-disk
are different. We have to keep the efi_update_capsule() for providing
runtime service API at boot time.

Suggested-by: AKASHI Takahiro &lt;takahiro.akashi@linaro.org&gt;
Signed-off-by: Masami Hiramatsu &lt;masami.hiramatsu@linaro.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since the efi_update_capsule() represents the UpdateCapsule() runtime
service, it has to handle the capsule flags and update ESRT. However
the capsule-on-disk doesn't need to care about such things.

Thus, the capsule-on-disk should use the efi_capsule_update_firmware()
directly instead of calling efi_update_capsule().

This means the roles of the efi_update_capsule() and capsule-on-disk
are different. We have to keep the efi_update_capsule() for providing
runtime service API at boot time.

Suggested-by: AKASHI Takahiro &lt;takahiro.akashi@linaro.org&gt;
Signed-off-by: Masami Hiramatsu &lt;masami.hiramatsu@linaro.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: fix uefi secure boot with intermediate certs</title>
<updated>2022-02-26T06:37:00+00:00</updated>
<author>
<name>Ilias Apalodimas</name>
<email>ilias.apalodimas@linaro.org</email>
</author>
<published>2022-02-14T09:14:22+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=bdcc0a9594d4d3ae02f9f013e105e9a7430b3266'/>
<id>bdcc0a9594d4d3ae02f9f013e105e9a7430b3266</id>
<content type='text'>
The general rule of accepting or rejecting an image is
 1. Is the sha256 of the image in dbx
 2. Is the image signed with a certificate that's found in db and
    not in dbx
 3. The image carries a cert which is signed by a cert in db (and
    not in dbx) and the image can be verified against the former
 4. Is the sha256 of the image in db

For example SHIM is signed by "CN=Microsoft Windows UEFI Driver Publisher",
which is issued by "CN=Microsoft Corporation UEFI CA 2011", which in it's
turn is issued by "CN=Microsoft Corporation Third Party Marketplace Root".
The latter is a self-signed CA certificate and with our current implementation
allows shim to execute if we insert it in db.

However it's the CA cert in the middle of the chain which usually ends up
in the system's db.  pkcs7_verify_one() might or might not return the root
certificate for a given chain.  But when verifying executables in UEFI,  the
trust anchor can be in the middle of the chain, as long as that certificate
is present in db.  Currently we only allow this check on self-signed
certificates,  so let's remove that check and allow all certs to try a
match an entry in db.

Open questions:
- Does this break any aspect of variable authentication since
  efi_signature_verify() is used on those as well?

Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The general rule of accepting or rejecting an image is
 1. Is the sha256 of the image in dbx
 2. Is the image signed with a certificate that's found in db and
    not in dbx
 3. The image carries a cert which is signed by a cert in db (and
    not in dbx) and the image can be verified against the former
 4. Is the sha256 of the image in db

For example SHIM is signed by "CN=Microsoft Windows UEFI Driver Publisher",
which is issued by "CN=Microsoft Corporation UEFI CA 2011", which in it's
turn is issued by "CN=Microsoft Corporation Third Party Marketplace Root".
The latter is a self-signed CA certificate and with our current implementation
allows shim to execute if we insert it in db.

However it's the CA cert in the middle of the chain which usually ends up
in the system's db.  pkcs7_verify_one() might or might not return the root
certificate for a given chain.  But when verifying executables in UEFI,  the
trust anchor can be in the middle of the chain, as long as that certificate
is present in db.  Currently we only allow this check on self-signed
certificates,  so let's remove that check and allow all certs to try a
match an entry in db.

Open questions:
- Does this break any aspect of variable authentication since
  efi_signature_verify() is used on those as well?

Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: fix dual signed image certification</title>
<updated>2022-02-11T19:07:55+00:00</updated>
<author>
<name>Ilias Apalodimas</name>
<email>ilias.apalodimas@linaro.org</email>
</author>
<published>2022-02-11T07:37:49+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=54cebe8a3ae8b56d784dbd0672cbd06102423eeb'/>
<id>54cebe8a3ae8b56d784dbd0672cbd06102423eeb</id>
<content type='text'>
The EFI spec allows for images to carry multiple signatures. Currently
we don't adhere to the verification process for such images.

The spec says:
"Multiple signatures are allowed to exist in the binary's certificate
table (as per PE/COFF Section "Attribute Certificate Table"). Only one
hash or signature is required to be present in db in order to pass
validation, so long as neither the SHA-256 hash of the binary nor any
present signature is reflected in dbx."

With our current implementation signing the image with two certificates
and inserting both of them in db and one of them dbx doesn't always reject
the image.  The rejection depends on the order that the image was signed
and the order the certificates are read (and checked) in db.

While at it move the sha256 hash verification outside the signature
checking loop, since it only needs to run once per image and get simplify
the logic for authenticating an unsigned imahe using sha256 hashes.

Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The EFI spec allows for images to carry multiple signatures. Currently
we don't adhere to the verification process for such images.

The spec says:
"Multiple signatures are allowed to exist in the binary's certificate
table (as per PE/COFF Section "Attribute Certificate Table"). Only one
hash or signature is required to be present in db in order to pass
validation, so long as neither the SHA-256 hash of the binary nor any
present signature is reflected in dbx."

With our current implementation signing the image with two certificates
and inserting both of them in db and one of them dbx doesn't always reject
the image.  The rejection depends on the order that the image was signed
and the order the certificates are read (and checked) in db.

While at it move the sha256 hash verification outside the signature
checking loop, since it only needs to run once per image and get simplify
the logic for authenticating an unsigned imahe using sha256 hashes.

Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Drop unnecessary calls to blk_find_device()</title>
<updated>2022-02-05T19:20:01+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2022-01-29T21:58:39+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=e2bceb03312a8abfb4f423ac349ab5861feb3548'/>
<id>e2bceb03312a8abfb4f423ac349ab5861feb3548</id>
<content type='text'>
When we have the block descriptor we can simply access the device. Drop
the unnecessary function call.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When we have the block descriptor we can simply access the device. Drop
the unnecessary function call.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Use device_get_uclass_id() where appropriate</title>
<updated>2022-02-05T19:20:01+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2022-01-29T21:58:38+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=377d39d178570a3510a34aac61f008b43cca783f'/>
<id>377d39d178570a3510a34aac61f008b43cca783f</id>
<content type='text'>
Use this function rather than following the pointers, since it is there
for this purpose.

Add the uclass name to the debug call at the end of dp_fill() since it is
quite useful.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use this function rather than following the pointers, since it is there
for this purpose.

Add the uclass name to the debug call at the end of dp_fill() since it is
quite useful.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: add handle for UART</title>
<updated>2022-02-05T19:20:01+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2022-02-04T19:47:09+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3c95b323c7527dd2b312b061a82a4b65bb3feff2'/>
<id>3c95b323c7527dd2b312b061a82a4b65bb3feff2</id>
<content type='text'>
When loading an EFI binary via the UART we assign a UART device path to it.
But we lack a handle with that device path.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When loading an EFI binary via the UART we assign a UART device path to it.
But we lack a handle with that device path.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: fix text output for Uart() DP nodes</title>
<updated>2022-02-05T19:20:01+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2022-02-04T15:36:49+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=915623c0d3f504dce8a2310c1ddf5dcc638e5d93'/>
<id>915623c0d3f504dce8a2310c1ddf5dcc638e5d93</id>
<content type='text'>
The UEFI specification concerning Uart() device path nodes has been
clarified:

Parity and stop bits can either both use keywords or both use
numbers but numbers and keywords should not be mixed.

Let's go for keywords as this is what EDK II does. For illegal
values fall back to numbers.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The UEFI specification concerning Uart() device path nodes has been
clarified:

Parity and stop bits can either both use keywords or both use
numbers but numbers and keywords should not be mixed.

Let's go for keywords as this is what EDK II does. For illegal
values fall back to numbers.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: use %zu to print efi_uintn_t in FMP driver</title>
<updated>2022-02-05T19:20:01+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2022-02-03T19:13:17+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b1193fa9576c988ebbe04334f10bf38279cc72ec'/>
<id>b1193fa9576c988ebbe04334f10bf38279cc72ec</id>
<content type='text'>
For printing an unsigned value we should use %u and not %d.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For printing an unsigned value we should use %u and not %d.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
