Message ID | 20240416190019.81016-12-raymond.mao@linaro.org |
---|---|
State | RFC |
Delegated to: | Tom Rini |
Headers | show |
Series | Integrate MbedTLS v3.6 LTS with U-Boot | expand |
On Tue, Apr 16, 2024 at 12:00:07PM -0700, Raymond Mao wrote: > When MBEDTLS_LIB_CRYPTO is enabled, use the APIs of sha256 from > hash shim layer instead. > > Signed-off-by: Raymond Mao <raymond.mao@linaro.org> > --- > lib/efi_loader/efi_tcg2.c | 9 +++++++++ > 1 file changed, 9 insertions(+) Why can't we have the abstraction be at the level where we include one library or the other so that the calling code doesn't change?
Hi Tom, On Tue, 16 Apr 2024 at 15:22, Tom Rini <trini@konsulko.com> wrote: > On Tue, Apr 16, 2024 at 12:00:07PM -0700, Raymond Mao wrote: > > > When MBEDTLS_LIB_CRYPTO is enabled, use the APIs of sha256 from > > hash shim layer instead. > > > > Signed-off-by: Raymond Mao <raymond.mao@linaro.org> > > --- > > lib/efi_loader/efi_tcg2.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > Why can't we have the abstraction be at the level where we include one > library or the other so that the calling code doesn't change? > > Yes, we can do this - The only reason I added new hash APIs with "_mb" is just to avoid vendor drivers that are using hash functions switch to MbedTLS with this patch set (As a [RFC], I was going to control all effects within the EFI loader). But if you think a complete switching has more benefits for estimation, I can unify all APIs between on/off MbedTLS. Thanks and Regards, Raymond
On Tue, Apr 16, 2024 at 08:22:23PM -0400, Raymond Mao wrote: > Hi Tom, > > On Tue, 16 Apr 2024 at 15:22, Tom Rini <trini@konsulko.com> wrote: > > > On Tue, Apr 16, 2024 at 12:00:07PM -0700, Raymond Mao wrote: > > > > > When MBEDTLS_LIB_CRYPTO is enabled, use the APIs of sha256 from > > > hash shim layer instead. > > > > > > Signed-off-by: Raymond Mao <raymond.mao@linaro.org> > > > --- > > > lib/efi_loader/efi_tcg2.c | 9 +++++++++ > > > 1 file changed, 9 insertions(+) > > > > Why can't we have the abstraction be at the level where we include one > > library or the other so that the calling code doesn't change? > > > > Yes, we can do this - The only reason I added new hash APIs with "_mb" is > just to > avoid vendor drivers that are using hash functions switch to MbedTLS with > this > patch set (As a [RFC], I was going to control all effects within the EFI > loader). > But if you think a complete switching has more benefits for estimation, I > can unify > all APIs between on/off MbedTLS. Yes, please, a complete switch.
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c index ac056dcfc5..3c356abc6e 100644 --- a/lib/efi_loader/efi_tcg2.c +++ b/lib/efi_loader/efi_tcg2.c @@ -1321,12 +1321,21 @@ efi_status_t efi_tcg2_measure_dtb(void *dtb) /* Measure populated areas of the DTB */ header = dtb; +#if CONFIG_IS_ENABLED(MBEDTLS_LIB_CRYPTO) + sha256_starts_mb(&hash_ctx); + sha256_update_mb(&hash_ctx, (u8 *)header, sizeof(struct fdt_header)); + sha256_update_mb(&hash_ctx, (u8 *)dtb + fdt_off_dt_struct(dtb), fdt_size_dt_strings(dtb)); + sha256_update_mb(&hash_ctx, (u8 *)dtb + fdt_off_dt_strings(dtb), fdt_size_dt_struct(dtb)); + sha256_update_mb(&hash_ctx, (u8 *)dtb + fdt_off_mem_rsvmap(dtb), rsvmap_size); + sha256_finish_mb(&hash_ctx, blob->data + blob->blob_description_size); +#else sha256_starts(&hash_ctx); sha256_update(&hash_ctx, (u8 *)header, sizeof(struct fdt_header)); sha256_update(&hash_ctx, (u8 *)dtb + fdt_off_dt_struct(dtb), fdt_size_dt_strings(dtb)); sha256_update(&hash_ctx, (u8 *)dtb + fdt_off_dt_strings(dtb), fdt_size_dt_struct(dtb)); sha256_update(&hash_ctx, (u8 *)dtb + fdt_off_mem_rsvmap(dtb), rsvmap_size); sha256_finish(&hash_ctx, blob->data + blob->blob_description_size); +#endif ret = measure_event(dev, 0, EV_POST_CODE, event_size, (u8 *)blob);
When MBEDTLS_LIB_CRYPTO is enabled, use the APIs of sha256 from hash shim layer instead. Signed-off-by: Raymond Mao <raymond.mao@linaro.org> --- lib/efi_loader/efi_tcg2.c | 9 +++++++++ 1 file changed, 9 insertions(+)