IMX8M Mini HAB secure boot - working?
Greetings,
Has anyone successfully used secure boot with IMX8M Mini or other IMX8M? Peng's recent series got merged with the exception of what looks like the addition of couple of 'caam' commands to blob/deblob DEK's.
There are no guides yet however I'm following the guides for the downstream NXP U-Boot and thus far have been able to get the SPL to boot with no HAB events but when it tries to authenticate the FIT image it validate_ivt fails with 'Error: Invalid IVT structure'. I'm not entirely clear if my CSF is wrong, or in the wrong place or if there is something missing.
Best regards,
Tim
Hi Tim,
On 10.07.21 02:05, Tim Harvey wrote:
Greetings,
Has anyone successfully used secure boot with IMX8M Mini or other IMX8M? Peng's recent series got merged with the exception of what looks like the addition of couple of 'caam' commands to blob/deblob DEK's.
There are no guides yet however I'm following the guides for the downstream NXP U-Boot and thus far have been able to get the SPL to boot with no HAB events but when it tries to authenticate the FIT image it validate_ivt fails with 'Error: Invalid IVT structure'.
Heiko tested this and found it, if I am not wrong he found the cause. Added him in CC.
I have also planned to test this, it is on my TODO list...
I'm not entirely clear if my CSF is wrong, or in the wrong place or if there is something missing.
Best regards, Stefano
Hi Tim, Stefano,
On 10.07.21 11:14, Stefano Babic wrote:
Hi Tim,
On 10.07.21 02:05, Tim Harvey wrote:
Greetings,
Has anyone successfully used secure boot with IMX8M Mini or other IMX8M? Peng's recent series got merged with the exception of what looks like the addition of couple of 'caam' commands to blob/deblob DEK's.
There are no guides yet however I'm following the guides for the downstream NXP U-Boot and thus far have been able to get the SPL to boot with no HAB events but when it tries to authenticate the FIT image it validate_ivt fails with 'Error: Invalid IVT structure'.
Heiko tested this and found it, if I am not wrong he found the cause. Added him in CC.
I have also planned to test this, it is on my TODO list...
I am currently not in my office, the whole next week ... so I could not check my current state of the patches... but I found a problem, yes.
The problem was that the ROM API loaded the IVT header to a memallocated address, which does of course not fit with the address you have in IVT header ...
I have not full access to my development setup ,and found on my local some old state of the patches .... may you can try them?
Of course they need a rework, other solution, but it shows the problem hopefully...
bye, Heiko
I'm not entirely clear if my CSF is wrong, or in the wrong place or if there is something missing.
Best regards, Stefano
On Sat, Jul 10, 2021 at 5:24 AM Heiko Schocher hs@denx.de wrote:
Hi Tim, Stefano,
On 10.07.21 11:14, Stefano Babic wrote:
Hi Tim,
On 10.07.21 02:05, Tim Harvey wrote:
Greetings,
Has anyone successfully used secure boot with IMX8M Mini or other IMX8M? Peng's recent series got merged with the exception of what looks like the addition of couple of 'caam' commands to blob/deblob DEK's.
There are no guides yet however I'm following the guides for the downstream NXP U-Boot and thus far have been able to get the SPL to boot with no HAB events but when it tries to authenticate the FIT image it validate_ivt fails with 'Error: Invalid IVT structure'.
Heiko tested this and found it, if I am not wrong he found the cause. Added him in CC.
I have also planned to test this, it is on my TODO list...
I am currently not in my office, the whole next week ... so I could not check my current state of the patches... but I found a problem, yes.
The problem was that the ROM API loaded the IVT header to a memallocated address, which does of course not fit with the address you have in IVT header ...
I have not full access to my development setup ,and found on my local some old state of the patches .... may you can try them?
Of course they need a rework, other solution, but it shows the problem hopefully...
Heiko,
Thank you - that was indeed the issue and your patches resolve it. I have not seen your patch posted to the list and your commit msg makes it seem like your not sure if you should make it SoC dependent. Do you plan on submitting these to the mailing list?
Best regards,
Tim
Hello Tim,
On 12.07.21 18:06, Tim Harvey wrote:
On Sat, Jul 10, 2021 at 5:24 AM Heiko Schocher hs@denx.de wrote:
Hi Tim, Stefano,
On 10.07.21 11:14, Stefano Babic wrote:
Hi Tim,
On 10.07.21 02:05, Tim Harvey wrote:
Greetings,
Has anyone successfully used secure boot with IMX8M Mini or other IMX8M? Peng's recent series got merged with the exception of what looks like the addition of couple of 'caam' commands to blob/deblob DEK's.
There are no guides yet however I'm following the guides for the downstream NXP U-Boot and thus far have been able to get the SPL to boot with no HAB events but when it tries to authenticate the FIT image it validate_ivt fails with 'Error: Invalid IVT structure'.
Heiko tested this and found it, if I am not wrong he found the cause. Added him in CC.
I have also planned to test this, it is on my TODO list...
I am currently not in my office, the whole next week ... so I could not check my current state of the patches... but I found a problem, yes.
The problem was that the ROM API loaded the IVT header to a memallocated address, which does of course not fit with the address you have in IVT header ...
I have not full access to my development setup ,and found on my local some old state of the patches .... may you can try them?
Of course they need a rework, other solution, but it shows the problem hopefully...
Heiko,
Thank you - that was indeed the issue and your patches resolve it. I
Cool! Thanks for testing!
have not seen your patch posted to the list and your commit msg makes
Yes, as they are WIP not posted yet ... and I thought, I make something wrong ... but if you have the same problem, it seems it is a real bug!
it seem like your not sure if you should make it SoC dependent. Do you plan on submitting these to the mailing list?
The question is: is my approach to fix it the way to go? If you think so, I can send them .. but give me please some time as I am just back from vacation...
Fast look into it:
spl_load_simple_fit_fix_load() must also check if there is at "fit" pointer an IVT header, if not, return simply fit pointer.
Question: dependent on SoC ... as it is in common code, and I think we need this "fix" only for imx8m?, so yes, it should be SoC dependent or better only imx8m? code defines this function... if possible. Therefore the weak function approach.
If you find time for looking at it, I am fine, if you use my patches as base and you can post them?
bye, Heiko
On Sun, Jul 18, 2021 at 9:01 PM Heiko Schocher hs@denx.de wrote:
Hello Tim,
On 12.07.21 18:06, Tim Harvey wrote:
On Sat, Jul 10, 2021 at 5:24 AM Heiko Schocher hs@denx.de wrote:
Hi Tim, Stefano,
On 10.07.21 11:14, Stefano Babic wrote:
Hi Tim,
On 10.07.21 02:05, Tim Harvey wrote:
Greetings,
Has anyone successfully used secure boot with IMX8M Mini or other IMX8M? Peng's recent series got merged with the exception of what looks like the addition of couple of 'caam' commands to blob/deblob DEK's.
There are no guides yet however I'm following the guides for the downstream NXP U-Boot and thus far have been able to get the SPL to boot with no HAB events but when it tries to authenticate the FIT image it validate_ivt fails with 'Error: Invalid IVT structure'.
Heiko tested this and found it, if I am not wrong he found the cause. Added him in CC.
I have also planned to test this, it is on my TODO list...
I am currently not in my office, the whole next week ... so I could not check my current state of the patches... but I found a problem, yes.
The problem was that the ROM API loaded the IVT header to a memallocated address, which does of course not fit with the address you have in IVT header ...
I have not full access to my development setup ,and found on my local some old state of the patches .... may you can try them?
Of course they need a rework, other solution, but it shows the problem hopefully...
Heiko,
Thank you - that was indeed the issue and your patches resolve it. I
Cool! Thanks for testing!
have not seen your patch posted to the list and your commit msg makes
Yes, as they are WIP not posted yet ... and I thought, I make something wrong ... but if you have the same problem, it seems it is a real bug!
it seem like your not sure if you should make it SoC dependent. Do you plan on submitting these to the mailing list?
The question is: is my approach to fix it the way to go? If you think so, I can send them .. but give me please some time as I am just back from vacation...
Fast look into it:
spl_load_simple_fit_fix_load() must also check if there is at "fit" pointer an IVT header, if not, return simply fit pointer.
Yes, otherwise non-hab will fail, correct?
Question: dependent on SoC ... as it is in common code, and I think we need this "fix" only for imx8m?, so yes, it should be SoC dependent or better only imx8m? code defines this function... if possible. Therefore the weak function approach.
If you find time for looking at it, I am fine, if you use my patches as base and you can post them?
I may be able to look at it again later this week or next.
I did run into another snag in that I could not figure out a proper CSF template for multiple DTB's. When I try to include mulitple DTB's I get several HAB events.
flash.log: ... ========= OFFSET dump ========= Loader IMAGE: header_image_off 0x0 image_off 0x40 csf_off 0x33200 spl hab block: 0x7e0fc0 0x0 0x33200
Second Loader IMAGE: sld_header_off 0x57c00 sld_csf_off 0x58c20 sld hab block: 0x401fcdc0 0x57c00 0x1020
csf_fit.txt: ... [Authenticate Data] # Key slot index used to authenticate the image data Verification index = 2 # Authenticate Start Address, Offset, Length and file Blocks = \ 0x401fcdc0 0x00057c00 0x00001020 "flash.bin", \ 0x40200000 0x0005ac00 0x000b0150 "flash.bin", \ 0x402b0150 0x0010ad50 0x00008bc4 "flash.bin", \ 0x00920000 0x00113914 0x00009159 "flash.bin"
So that first block is the FIT image header I think (only 4128 bytes long) using data from flash.log 'sld hab block:', the second block is u-boot-nodtb.bin from within the FIT image, the third block is the dtb from within the FIT, and the fourth block is the ATF from within the FIT.
When I have multiple DTB's do I need a block per DTB? I haven't found any example of a CSF template where CONFIG_OF_LIST has multiple dtb's.
Thanks,
Tim
Hello Tim,
On 20.07.21 00:23, Tim Harvey wrote:
On Sun, Jul 18, 2021 at 9:01 PM Heiko Schocher hs@denx.de wrote:
Hello Tim,
On 12.07.21 18:06, Tim Harvey wrote:
On Sat, Jul 10, 2021 at 5:24 AM Heiko Schocher hs@denx.de wrote:
Hi Tim, Stefano,
On 10.07.21 11:14, Stefano Babic wrote:
Hi Tim,
On 10.07.21 02:05, Tim Harvey wrote:
Greetings,
Has anyone successfully used secure boot with IMX8M Mini or other IMX8M? Peng's recent series got merged with the exception of what looks like the addition of couple of 'caam' commands to blob/deblob DEK's.
There are no guides yet however I'm following the guides for the downstream NXP U-Boot and thus far have been able to get the SPL to boot with no HAB events but when it tries to authenticate the FIT image it validate_ivt fails with 'Error: Invalid IVT structure'.
Heiko tested this and found it, if I am not wrong he found the cause. Added him in CC.
I have also planned to test this, it is on my TODO list...
I am currently not in my office, the whole next week ... so I could not check my current state of the patches... but I found a problem, yes.
The problem was that the ROM API loaded the IVT header to a memallocated address, which does of course not fit with the address you have in IVT header ...
I have not full access to my development setup ,and found on my local some old state of the patches .... may you can try them?
Of course they need a rework, other solution, but it shows the problem hopefully...
Heiko,
Thank you - that was indeed the issue and your patches resolve it. I
Cool! Thanks for testing!
have not seen your patch posted to the list and your commit msg makes
Yes, as they are WIP not posted yet ... and I thought, I make something wrong ... but if you have the same problem, it seems it is a real bug!
it seem like your not sure if you should make it SoC dependent. Do you plan on submitting these to the mailing list?
The question is: is my approach to fix it the way to go? If you think so, I can send them .. but give me please some time as I am just back from vacation...
Fast look into it:
spl_load_simple_fit_fix_load() must also check if there is at "fit" pointer an IVT header, if not, return simply fit pointer.
Yes, otherwise non-hab will fail, correct?
Yes.
Question: dependent on SoC ... as it is in common code, and I think we need this "fix" only for imx8m?, so yes, it should be SoC dependent or better only imx8m? code defines this function... if possible. Therefore the weak function approach.
If you find time for looking at it, I am fine, if you use my patches as base and you can post them?
I may be able to look at it again later this week or next.
Fine.
I did run into another snag in that I could not figure out a proper CSF template for multiple DTB's. When I try to include mulitple DTB's I get several HAB events.
flash.log: ... ========= OFFSET dump ========= Loader IMAGE: header_image_off 0x0 image_off 0x40 csf_off 0x33200 spl hab block: 0x7e0fc0 0x0 0x33200
Second Loader IMAGE: sld_header_off 0x57c00 sld_csf_off 0x58c20 sld hab block: 0x401fcdc0 0x57c00 0x1020
csf_fit.txt: ... [Authenticate Data] # Key slot index used to authenticate the image data Verification index = 2 # Authenticate Start Address, Offset, Length and file Blocks = \ 0x401fcdc0 0x00057c00 0x00001020 "flash.bin", \ 0x40200000 0x0005ac00 0x000b0150 "flash.bin", \ 0x402b0150 0x0010ad50 0x00008bc4 "flash.bin", \ 0x00920000 0x00113914 0x00009159 "flash.bin"
So that first block is the FIT image header I think (only 4128 bytes long) using data from flash.log 'sld hab block:', the second block is
Yes
u-boot-nodtb.bin from within the FIT image, the third block is the dtb
Yes and yes
from within the FIT, and the fourth block is the ATF from within the FIT.
Yes
When I have multiple DTB's do I need a block per DTB? I haven't found any example of a CSF template where CONFIG_OF_LIST has multiple dtb's.
Hmm... good question... I think (not tested) when you have multiple DTBs the DTBs are packed into a FIT image, so you have again only one "dtb" part to sign...
./doc/README.multi-dtb-fit says: """ The relevant DTBs are packed into a FIT (list provided by CONFIG_OF_LIST). The FIT is automatically generated at the end of the compilation and appended to u-boot.bin so that U-Boot can locate it and select the correct DTB from inside the FIT. """
So I think no problem...or?
bye, Heiko
participants (3)
-
Heiko Schocher -
Stefano Babic -
Tim Harvey