On Fri, Oct 29, 2021 at 01:20:52PM +0300, Ilias Apalodimas wrote:
Hi Simon,
[...]
Why me? Perhaps Linaro could take this on instead of working in a separate tool and domain? You guys could really pull things together and reduce the fragmentation, if you took it on.
Honestly it is hard enough to even get Linaro people to write a test for code they have written. What gives?
That's completely inaccurate. We've added selftests for *every* single feature we've sent for EFI up to now. Functionality wise the past 2 years we've added
- EFI variables
- EFI secure boot
- capsule updates
- initrd loading
- efi TCG protocol
- ESRT tables
- RNG protocol
5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() ce62b0f8f45f1 test/py: Fix efidebug related tests 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule de489d82e3189 test: test the ESRT creation 57be8cdce35 test/py: efi_secboot: small rework for adding a new test e1174c566a61c test/py: efi_secboot: add test for intermediate certificates 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
and I am pretty sure I am forgetting more on functionality and selftests.
So basically we've either contributed new selftests for *everything* we've or fixed the existing ones. The only thing that's not merged is the TCG selftests which are on upstream review.
Er, I didn't say or mean that no tests were written, just that there is too much push-back on it. Heinrich put a huge amount of effort into
There's no pushback at all, apart from the TPM one. (and for a very good reason I've explained over and over again). In fact we add the sefltests as part of our patchsets.
And, for that set of TPM things, I agree with NOT making sandbox the requirement there. As QEMU is able to provide a TPM that will see real world usage, that's what we need to validate against primarily.
the tests and basically created a strong base for it. Congrats and huge kudos to him. As to Linaro, no offence intended, and it is great that all these tests have been added. Thank you for your efforts and it is very helpful. But I think you miss my point. Or perhaps you don't even agree with it? I sent an email about this on one patch just a day or two ago.
I guess you mean [1]. I've lost count of how many times I responded to this. Threads [2], [3] and [4] are just a few examples, so I just got tired or replying the same thing over and over.
So bottom line, we are contributing selftests as always, we just don't agree with the way *you* want this specific TPM test, trying to force us into sandbox. So instead of respecting what we have (which btw is acceptable from u-boot's perspective and cleans up a lot of the TPM crud along the way), you went ahead making misleading statements on the selftests we contribute, in general. What's even more annoying is that, as I showed you, we pretty much add a selftest for *every* feature we add. Excellent ... that's certainly ... encouraging ... and very productive.
As to the leadership side (my bigger point), Linaro is leading us all down this fragmented path, with TF-A, FIP, more and more binaries and larger firmware diagrams. Or do you disagree with that too?
Of course I disagree. People decided not to use SPL for their own reasons. I am certainly not qualified to answer why Arm choose to do that, but it seems to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure U-Boot is compatible and remains the de-facto choice for embedded boot loaders playing nicely with all the new FSBLs come up with. If you cosinder SPL and U-Boot the center of the known universe, we certainly view things differently. FWIW it's *our* work mostly that made U-Boot SystemReady compliant, which is something Arm pushes for [5].
Let me say for the record that I am appreciative of the fact the Linaro has been putting so much effort in to U-Boot, both in terms of tests and also in general SystemReady compliance work.