Dear Simon,
In message CAPnjgZ0V=MwiVYQ3H-dsVEpNVHMdOPx3Yh3qtPdje0=_Cz=smg@mail.gmail.com you wrote:
This is not exactly a proposal that triggers enthusiasm to me.
Enthusiasm is a strong word...
I tried to find a strictly non-negative phrasing here, because I felt that would be somewhat better ;-)
Let's take an example. We have AHCI/SATA support in U-Boot. There may be no board code in U-Boot that actually reads from a disk (I am not sure, but it is plausible, since hard-coded disk/fs access from a board's C code would be odd). Let's say this code exists only in commands that may or may not be executed by board scripts, which are out of tree. I'm sure this isn't considered dead code, but I want to
As soon as I can type on the console something like
ext2load sata 0:1 200000 boot/uImage
and this is actually capable of reading data from a S-ATA attached storage device, then this is perfectly fine: the driver provides a functionality, which can be used in U-Boot to perform certain actions on the real system.
understand the difference. If there is a TPM command which may or may not be executed by board scripts (also out of tree), what is the difference?
If there is a TPM command which actually communicates with the TPM hardware and can be used for example to verify an image checksum or such, then it provides a function.
Following this dead code argument, whole U-Boot subsystems are dead code since they are only used indirectly from the command line and not directly by any board code?
This is not what I mean.
So my thinking now is that I should:
- Create a way of extracting verification information from a signed
block (e.g. kernel hash, rollback info) 2. Add some commands to access this 3. Create a basic script which uses these commands
Does this sound right?
3. would actually not be needed, as long as 1. and 2. really work on some system.
Comment for 1. (but not relateds to this thread, just a note while we are at it): I imagine such functionality should be integrated with the FIT image handling, i. e. like we are today able to verify - say - a sha256 checksum of an image, your code would be able to verify a TPM backed signature. Does this match your plans?
So long as I can understand the definition then we should be fine.
Can we agree on something like: code is considered to be "used" (in the sense of it is no dead code) when there is at least one board configuration in mainline where, either as part of the normal initialization sequence or as reaction to some interactive user command, said code will be executed and perform the specific function it was designed for ?
As a side effect this means that there is at least one board configuration that will actually compile and link this piece of code.
Best regards,
Wolfgang Denk