Hello,
I am interested in using the EIP197 crypto accelerator. I am aware that
it requires an NDA
to obtain the firmware for it, but I found out that there is some kind
of "minifw" as well
in the linux-firmware tree [3]. I found no description of it - I would
like to learn what
are the features and limitations of this "minifw".
I started with using it on the Debian image from board vendor [2]. The
kernel here is
5.1.0. The firmware is loaded, but the ALG tests are all failing:
[14785.750246] crypto-safexcel f2800000.crypto: firmware: direct-loading
firmware inside-secure/eip197b/ifpp.bin
[14785.762765] crypto-safexcel f2800000.crypto: firmware: direct-loading
firmware inside-secure/eip197b/ipue.bin
[14785.777978] alg: skcipher: safexcel-cbc-des encryption test failed
(wrong output IV) on test vector 0, cfg="in-place"
[14785.788661] 00000000: fe dc ba 98 76 54 32 10
[14785.800606] alg: skcipher: safexcel-cbc-des3_ede encryption test
failed (wrong output IV) on test vector 0, cfg="in-place"
[14785.811720] 00000000: 7d 33 88 93 0f 93 b2 42
[14785.823734] alg: skcipher: safexcel-cbc-aes encryption test failed
(wrong output IV) on test vector 0, cfg="in-place"
[14785.834439] 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f ac 41
[14785.884568] alg: hash: safexcel-hmac-sha224 test failed (wrong
result) on test vector 3, cfg="init+update+update+final two even splits"
[14785.901836] alg: hash: safexcel-hmac-sha256 test failed (wrong
result) on test vector 2, cfg="import/export"
[14785.926693] alg: aead: safexcel-authenc-hmac-sha1-cbc-aes encryption
test failed (wrong result) on test vector 0, cfg="misaligned splits
crossing pages, inplace"
[14785.944430] alg: No test for authenc(hmac(sha224),cbc(aes))
(safexcel-authenc-hmac-sha224-cbc-aes)
[14785.956978] alg: aead: safexcel-authenc-hmac-sha256-cbc-aes
encryption test failed (wrong result) on test vector 0, cfg="two even
aligned splits"
[14785.973472] alg: No test for authenc(hmac(sha384),cbc(aes))
(safexcel-authenc-hmac-sha384-cbc-aes)
[14785.986103] alg: aead: safexcel-authenc-hmac-sha512-cbc-aes
encryption test failed (wrong result) on test vector 0, cfg="two even
aligned splits"
I am going to test it with more recent, mainline kernel as well, but it
would be still nice to learn
a little bit more about this "minifw", it's features, and what could be
possibly achieved on this
board without proprietary (and behind NDA) crypto firmware.
Thank you,
[1]
https://www.solid-run.com/embedded-networking/marvell-armada-family/clearfog-gt-8k/
[2] https://images.solid-build.xyz/8040/Debian/
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/inside-secure/eip197_minifw/ifpp.bin?id=eefb5f7410150c00d0ab5c41c5d817ae9bf449b3
--
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com
Hello Maciej,
> -----Original Message-----
> From: Maciej Pijanowski <[email protected]>
> Sent: Monday, February 1, 2021 7:53 PM
> To: [email protected]
> Cc: [email protected]; [email protected]; Piotr Król <[email protected]>
> Subject: safexcel driver for EIP197 and mini firmware features
>
> <<< External Email >>>
> Hello,
>
> I am interested in using the EIP197 crypto accelerator. I am aware that
> it requires an NDA
> to obtain the firmware for it, but I found out that there is some kind
> of "minifw" as well
> in the linux-firmware tree [3]. I found no description of it - I would
> like to learn what
> are the features and limitations of this "minifw".
>
Actually, from the perspective of what that firmware normally does, it does not have any features
at all :-) Ok, except for cache invalidates, which the EIP-197 requires.
It just bypasses everything from the inputs to the internal crypto engine, effectively turning the
EIP-197 into an EIP-97 with caches & prefetching.
But that's OK for the Linux kernel driver, because that was using the EIP-197 in EIP-97 backward
compatibility mode anyway. It does not support any advanced EIP-197 firmware features.
So from the perspective of the current Linux driver: no limitations.
> I started with using it on the Debian image from board vendor [2]. The
> kernel here is
> 5.1.0. The firmware is loaded, but the ALG tests are all failing:
>
> [14785.750246] crypto-safexcel f2800000.crypto: firmware: direct-loading
> firmware inside-secure/eip197b/ifpp.bin
> [14785.762765] crypto-safexcel f2800000.crypto: firmware: direct-loading
> firmware inside-secure/eip197b/ipue.bin
> [14785.777978] alg: skcipher: safexcel-cbc-des encryption test failed
> (wrong output IV) on test vector 0, cfg="in-place"
> [14785.788661] 00000000: fe dc ba 98 76 54 32 10
> [14785.800606] alg: skcipher: safexcel-cbc-des3_ede encryption test
> failed (wrong output IV) on test vector 0, cfg="in-place"
> [14785.811720] 00000000: 7d 33 88 93 0f 93 b2 42
> [14785.823734] alg: skcipher: safexcel-cbc-aes encryption test failed
> (wrong output IV) on test vector 0, cfg="in-place"
> [14785.834439] 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f ac 41
> [14785.884568] alg: hash: safexcel-hmac-sha224 test failed (wrong
> result) on test vector 3, cfg="init+update+update+final two even splits"
> [14785.901836] alg: hash: safexcel-hmac-sha256 test failed (wrong
> result) on test vector 2, cfg="import/export"
> [14785.926693] alg: aead: safexcel-authenc-hmac-sha1-cbc-aes encryption
> test failed (wrong result) on test vector 0, cfg="misaligned splits
> crossing pages, inplace"
> [14785.944430] alg: No test for authenc(hmac(sha224),cbc(aes))
> (safexcel-authenc-hmac-sha224-cbc-aes)
> [14785.956978] alg: aead: safexcel-authenc-hmac-sha256-cbc-aes
> encryption test failed (wrong result) on test vector 0, cfg="two even
> aligned splits"
> [14785.973472] alg: No test for authenc(hmac(sha384),cbc(aes))
> (safexcel-authenc-hmac-sha384-cbc-aes)
> [14785.986103] alg: aead: safexcel-authenc-hmac-sha512-cbc-aes
> encryption test failed (wrong result) on test vector 0, cfg="two even
> aligned splits"
>
Ok, that is unexpected. Although I know there is one particular kernel version that was broken.
So you might want to try a slightly newer one.
(I'd love to try 5.1 myself but I don't have access to the hardware right now, working from home)
>
> I am going to test it with more recent, mainline kernel as well, but it
> would be still nice to learn
> a little bit more about this "minifw", it's features, and what could be
> possibly achieved on this
> board without proprietary (and behind NDA) crypto firmware.
>
Everything the kernel driver currently supports.
The real firmware is for doing full protocol offload (like IPsec, DTLS, etc.) which the Linux kernel
does not currently support anyway. (unfortunately, I might add)
> Thank you,
>
>
> [1]
> https://www.solid-run.com/embedded-networking/marvell-armada-family/clearfog-gt-8k/
> [2] https://images.solid-build.xyz/8040/Debian/
> [3]
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/inside-
> secure/eip197_minifw/ifpp.bin?id=eefb5f7410150c00d0ab5c41c5d817ae9bf449b3
>
> --
> Maciej Pijanowski
> Embedded Systems Engineer
> GPG: 9963C36AAC3B2B46
> https://3mdeb.com | @3mdeb_com
Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953
Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.
** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
Rambus Inc.<http://www.rambus.com>
On 02.02.2021 09:48, Van Leeuwen, Pascal wrote:
> Hello Maciej,
Hello,
>
>> -----Original Message-----
>> From: Maciej Pijanowski <[email protected]>
>> Sent: Monday, February 1, 2021 7:53 PM
>> To: [email protected]
>> Cc: [email protected]; [email protected]; Piotr Król <[email protected]>
>> Subject: safexcel driver for EIP197 and mini firmware features
>>
>> <<< External Email >>>
>> Hello,
>>
>> I am interested in using the EIP197 crypto accelerator. I am aware that
>> it requires an NDA
>> to obtain the firmware for it, but I found out that there is some kind
>> of "minifw" as well
>> in the linux-firmware tree [3]. I found no description of it - I would
>> like to learn what
>> are the features and limitations of this "minifw".
>>
> Actually, from the perspective of what that firmware normally does, it does not have any features
> at all :-) Ok, except for cache invalidates, which the EIP-197 requires.
> It just bypasses everything from the inputs to the internal crypto engine, effectively turning the
> EIP-197 into an EIP-97 with caches & prefetching.
>
> But that's OK for the Linux kernel driver, because that was using the EIP-197 in EIP-97 backward
> compatibility mode anyway. It does not support any advanced EIP-197 firmware features.
> So from the perspective of the current Linux driver: no limitations.
Thank you very much for the response. That is much more clear now.
>
>> I started with using it on the Debian image from board vendor [2]. The
>> kernel here is
>> 5.1.0. The firmware is loaded, but the ALG tests are all failing:
>>
>> [14785.750246] crypto-safexcel f2800000.crypto: firmware: direct-loading
>> firmware inside-secure/eip197b/ifpp.bin
>> [14785.762765] crypto-safexcel f2800000.crypto: firmware: direct-loading
>> firmware inside-secure/eip197b/ipue.bin
>> [14785.777978] alg: skcipher: safexcel-cbc-des encryption test failed
>> (wrong output IV) on test vector 0, cfg="in-place"
>> [14785.788661] 00000000: fe dc ba 98 76 54 32 10
>> [14785.800606] alg: skcipher: safexcel-cbc-des3_ede encryption test
>> failed (wrong output IV) on test vector 0, cfg="in-place"
>> [14785.811720] 00000000: 7d 33 88 93 0f 93 b2 42
>> [14785.823734] alg: skcipher: safexcel-cbc-aes encryption test failed
>> (wrong output IV) on test vector 0, cfg="in-place"
>> [14785.834439] 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f ac 41
>> [14785.884568] alg: hash: safexcel-hmac-sha224 test failed (wrong
>> result) on test vector 3, cfg="init+update+update+final two even splits"
>> [14785.901836] alg: hash: safexcel-hmac-sha256 test failed (wrong
>> result) on test vector 2, cfg="import/export"
>> [14785.926693] alg: aead: safexcel-authenc-hmac-sha1-cbc-aes encryption
>> test failed (wrong result) on test vector 0, cfg="misaligned splits
>> crossing pages, inplace"
>> [14785.944430] alg: No test for authenc(hmac(sha224),cbc(aes))
>> (safexcel-authenc-hmac-sha224-cbc-aes)
>> [14785.956978] alg: aead: safexcel-authenc-hmac-sha256-cbc-aes
>> encryption test failed (wrong result) on test vector 0, cfg="two even
>> aligned splits"
>> [14785.973472] alg: No test for authenc(hmac(sha384),cbc(aes))
>> (safexcel-authenc-hmac-sha384-cbc-aes)
>> [14785.986103] alg: aead: safexcel-authenc-hmac-sha512-cbc-aes
>> encryption test failed (wrong result) on test vector 0, cfg="two even
>> aligned splits"
>>
> Ok, that is unexpected. Although I know there is one particular kernel version that was broken.
> So you might want to try a slightly newer one.
> (I'd love to try 5.1 myself but I don't have access to the hardware right now, working from home)
I am going to try with 5.10.12 and let you know with the results.
>
>> I am going to test it with more recent, mainline kernel as well, but it
>> would be still nice to learn
>> a little bit more about this "minifw", it's features, and what could be
>> possibly achieved on this
>> board without proprietary (and behind NDA) crypto firmware.
>>
> Everything the kernel driver currently supports.
> The real firmware is for doing full protocol offload (like IPsec, DTLS, etc.) which the Linux kernel
> does not currently support anyway. (unfortunately, I might add)
Are you aware of any other system (OS) or implementation which takes
advantage of more of the EIP197 features (like the mentioned IPsec offload)?
>
>> Thank you,
>>
>>
>> [1]
>> https://www.solid-run.com/embedded-networking/marvell-armada-family/clearfog-gt-8k/
>> [2] https://images.solid-build.xyz/8040/Debian/
>> [3]
>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/inside-
>> secure/eip197_minifw/ifpp.bin?id=eefb5f7410150c00d0ab5c41c5d817ae9bf449b3
>>
>> --
>> Maciej Pijanowski
>> Embedded Systems Engineer
>> GPG: 9963C36AAC3B2B46
>> https://3mdeb.com | @3mdeb_com
> Regards,
> Pascal van Leeuwen
> Silicon IP Architect Multi-Protocol Engines, Rambus Security
> Rambus ROTW Holding BV
> +31-73 6581953
>
> Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
> Please be so kind to update your e-mail address book with my new e-mail address.
>
>
> ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
>
> Rambus Inc.<http://www.rambus.com>
--
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com
> -----Original Message-----
> From: Maciej Pijanowski <[email protected]>
> Sent: Wednesday, February 3, 2021 11:00 AM
> To: Van Leeuwen, Pascal <[email protected]>; [email protected]
> Cc: [email protected]; [email protected]; Piotr Król <[email protected]>
> Subject: Re: safexcel driver for EIP197 and mini firmware features
>
> <<< External Email >>>
>
> On 02.02.2021 10:15, Maciej Pijanowski wrote:
> >
> > On 02.02.2021 09:48, Van Leeuwen, Pascal wrote:
> >> Hello Maciej,
> > Hello,
> >>
> >>> -----Original Message-----
> >>> From: Maciej Pijanowski <[email protected]>
> >>> Sent: Monday, February 1, 2021 7:53 PM
> >>> To: [email protected]
> >>> Cc: [email protected]; [email protected]; Piotr Król
> >>> <[email protected]>
> >>> Subject: safexcel driver for EIP197 and mini firmware features
> >>>
> >>> <<< External Email >>>
> >>> Hello,
> >>>
> >>> I am interested in using the EIP197 crypto accelerator. I am aware that
> >>> it requires an NDA
> >>> to obtain the firmware for it, but I found out that there is some kind
> >>> of "minifw" as well
> >>> in the linux-firmware tree [3]. I found no description of it - I would
> >>> like to learn what
> >>> are the features and limitations of this "minifw".
> >>>
> >> Actually, from the perspective of what that firmware normally does,
> >> it does not have any features
> >> at all :-) Ok, except for cache invalidates, which the EIP-197 requires.
> >> It just bypasses everything from the inputs to the internal crypto
> >> engine, effectively turning the
> >> EIP-197 into an EIP-97 with caches & prefetching.
> >>
> >> But that's OK for the Linux kernel driver, because that was using the
> >> EIP-197 in EIP-97 backward
> >> compatibility mode anyway. It does not support any advanced EIP-197
> >> firmware features.
> >> So from the perspective of the current Linux driver: no limitations.
> > Thank you very much for the response. That is much more clear now.
> >>
> >>> I started with using it on the Debian image from board vendor [2]. The
> >>> kernel here is
> >>> 5.1.0. The firmware is loaded, but the ALG tests are all failing:
> >>>
> >>> [14785.750246] crypto-safexcel f2800000.crypto: firmware:
> >>> direct-loading
> >>> firmware inside-secure/eip197b/ifpp.bin
> >>> [14785.762765] crypto-safexcel f2800000.crypto: firmware:
> >>> direct-loading
> >>> firmware inside-secure/eip197b/ipue.bin
> >>> [14785.777978] alg: skcipher: safexcel-cbc-des encryption test failed
> >>> (wrong output IV) on test vector 0, cfg="in-place"
> >>> [14785.788661] 00000000: fe dc ba 98 76 54 32 10
> >>> [14785.800606] alg: skcipher: safexcel-cbc-des3_ede encryption test
> >>> failed (wrong output IV) on test vector 0, cfg="in-place"
> >>> [14785.811720] 00000000: 7d 33 88 93 0f 93 b2 42
> >>> [14785.823734] alg: skcipher: safexcel-cbc-aes encryption test failed
> >>> (wrong output IV) on test vector 0, cfg="in-place"
> >>> [14785.834439] 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f
> >>> ac 41
> >>> [14785.884568] alg: hash: safexcel-hmac-sha224 test failed (wrong
> >>> result) on test vector 3, cfg="init+update+update+final two even
> >>> splits"
> >>> [14785.901836] alg: hash: safexcel-hmac-sha256 test failed (wrong
> >>> result) on test vector 2, cfg="import/export"
> >>> [14785.926693] alg: aead: safexcel-authenc-hmac-sha1-cbc-aes encryption
> >>> test failed (wrong result) on test vector 0, cfg="misaligned splits
> >>> crossing pages, inplace"
> >>> [14785.944430] alg: No test for authenc(hmac(sha224),cbc(aes))
> >>> (safexcel-authenc-hmac-sha224-cbc-aes)
> >>> [14785.956978] alg: aead: safexcel-authenc-hmac-sha256-cbc-aes
> >>> encryption test failed (wrong result) on test vector 0, cfg="two even
> >>> aligned splits"
> >>> [14785.973472] alg: No test for authenc(hmac(sha384),cbc(aes))
> >>> (safexcel-authenc-hmac-sha384-cbc-aes)
> >>> [14785.986103] alg: aead: safexcel-authenc-hmac-sha512-cbc-aes
> >>> encryption test failed (wrong result) on test vector 0, cfg="two even
> >>> aligned splits"
> >>>
> >> Ok, that is unexpected. Although I know there is one particular
> >> kernel version that was broken.
> >> So you might want to try a slightly newer one.
> >> (I'd love to try 5.1 myself but I don't have access to the hardware
> >> right now, working from home)
> > I am going to try with 5.10.12 and let you know with the results.
> This is the first result with 5.10.12 mainline kernel:
>
> [ 1.678251] mmcblk0rpmb: mmc0:0001 8GTF4R partition 3 512 KiB,
> chardev (239:0)
> [ 182.882113] random: fast init done
> [ 185.308594] crypto-safexcel f2800000.crypto: HW init failed (-11)
> [ 185.314737] ------------[ cut here ]------------
> [ 185.319379] WARNING: CPU: 2 PID: 1 at kernel/irq/manage.c:1777
> free_irq+0x31c/0x350
> [ 185.327065] Modules linked in:
> [ 185.330134] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.10.12-dirty #1
> [ 185.336687] Hardware name: SolidRun ClearFog GT 8K (DT)
> [ 185.341934] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
> [ 185.347964] pc : free_irq+0x31c/0x350
> [ 185.351640] lr : free_irq+0x300/0x350
> [ 185.355315] sp : ffff80001160baf0
> [ 185.358641] x29: ffff80001160baf0 x28: 0000000000000000
> [ 185.363976] x27: ffff8000111d1078 x26: ffff8000111404b8
> [ 185.369310] x25: 000000000000002d x24: ffff0001016036dc
> [ 185.374644] x23: ffff000101603790 x22: ffff0001015db180
> [ 185.379978] x21: 0000000000000000 x20: ffff0001015da700
> [ 185.385313] x19: ffff000101603600 x18: 0000000000000010
> [ 185.390647] x17: 00000000000000a9 x16: 0000000000000087
> [ 185.395981] x15: ffff000100078478 x14: 0000000000000102
> [ 185.401316] x13: ffff000100078478 x12: 00000000ffffffea
> [ 185.406649] x11: 0000000000000040 x10: ffff8000114322a0
> [ 185.411983] x9 : ffff800011432298 x8 : ffff000100400270
> [ 185.417318] x7 : 0000000000000000 x6 : 0000000000000000
> [ 185.422651] x5 : ffff000100400248 x4 : ffff8000115b0000
> [ 185.427985] x3 : ffff8000115b0188 x2 : 0000000000020000
> [ 185.433319] x1 : ffff000101603600 x0 : ffff800010c87198
> [ 185.438654] Call trace:
> [ 185.441109] free_irq+0x31c/0x350
> [ 185.444437] devm_irq_release+0x18/0x28
> [ 185.448289] release_nodes+0x1b0/0x228
> [ 185.452052] devres_release_all+0x38/0x60
> [ 185.456077] really_probe+0x1e4/0x3b0
> [ 185.459753] driver_probe_device+0x58/0xb8
> [ 185.463865] device_driver_attach+0x74/0x80
> [ 185.468063] __driver_attach+0x58/0xe0
> [ 185.471827] bus_for_each_dev+0x70/0xc8
> [ 185.475677] driver_attach+0x24/0x30
> [ 185.479265] bus_add_driver+0x14c/0x1f0
> [ 185.483116] driver_register+0x64/0x120
> [ 185.486965] __platform_driver_register+0x48/0x58
> [ 185.491690] safexcel_init+0x48/0x70
> [ 185.495279] do_one_initcall+0x54/0x1b8
> [ 185.499130] kernel_init_freeable+0x1d4/0x23c
> [ 185.503505] kernel_init+0x14/0x118
> [ 185.507005] ret_from_fork+0x10/0x34
> [ 185.510596] ---[ end trace a5f4f63f649fa735 ]---
> [ 185.515370] crypto-safexcel: probe of f2800000.crypto failed with
> error -11
> [ 185.522632] usbcore: registered new interface driver usbhid
>
> The "HW init failed" comes from here:
> https://elixir.bootlin.com/linux/v5.10.12/source/drivers/crypto/inside-secure/safexcel.c#L1692
> Interestingly, I cannot see in the driver code (at least at a first
> glance) where the (-11)
> error code would come from.
>
> Any hints?
>
It's a weird error code indeed. -11 would be ... EAGAIN? That's certainly not something local.
So it must be some error code passed on from some Linux kernel API function call.
My best guess at the moment would be the firmware load call (firmware_request_nowarn).
But it would have been helpful to see the driver logging _prior_ to HW init failed, to see
which parts of the initialization _did_ succeed properly.
>
> Do you have a known working kernel version for this driver?
>
I've seen a lot of kernel versions work just fine in the past.
5.4 - 5.8 should definitely work just fine. Last time I tried was September of last year,
when I tried to get some fix in for a customer of ours. (but had to give up due to the patch
not being accepted as such and me not having the time to redo it as suggested)
In any case, whatever was in development (5.10?) at the time still worked fine on my side.
In any case, I only know of one older kernel version that was truly broken. Could be the 5.1
you tried, don't remember exactly ...
> Thank you,
>
> >>
> >>> I am going to test it with more recent, mainline kernel as well, but it
> >>> would be still nice to learn
> >>> a little bit more about this "minifw", it's features, and what could be
> >>> possibly achieved on this
> >>> board without proprietary (and behind NDA) crypto firmware.
> >>>
> >> Everything the kernel driver currently supports.
> >> The real firmware is for doing full protocol offload (like IPsec,
> >> DTLS, etc.) which the Linux kernel
> >> does not currently support anyway. (unfortunately, I might add)
> > Are you aware of any other system (OS) or implementation which takes
> > advantage of more of the EIP197 features (like the mentioned IPsec
> > offload)?
> >>
> >>> Thank you,
> >>>
> >>>
> >>> [1]
> >>> https://www.solid-run.com/embedded-networking/marvell-armada-family/clearfog-gt-8k/
> >>>
> >>> [2] https://images.solid-build.xyz/8040/Debian/
> >>> [3]
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/inside-
> >>>
> >>> secure/eip197_minifw/ifpp.bin?id=eefb5f7410150c00d0ab5c41c5d817ae9bf449b3
> >>>
> >>>
> >>> --
> >>> Maciej Pijanowski
> >>> Embedded Systems Engineer
> >>> GPG: 9963C36AAC3B2B46
> >>> https://3mdeb.com | @3mdeb_com
> >> Regards,
> >> Pascal van Leeuwen
> >> Silicon IP Architect Multi-Protocol Engines, Rambus Security
> >> Rambus ROTW Holding BV
> >> +31-73 6581953
> >>
> >> Note: The Inside Secure/Verimatrix Silicon IP team was recently
> >> acquired by Rambus.
> >> Please be so kind to update your e-mail address book with my new
> >> e-mail address.
> >>
> >>
> >> ** This message and any attachments are for the sole use of the
> >> intended recipient(s). It may contain information that is
> >> confidential and privileged. If you are not the intended recipient of
> >> this message, you are prohibited from printing, copying, forwarding
> >> or saving it. Please delete the message and attachments and notify
> >> the sender immediately. **
> >>
> >> Rambus Inc.<http://www.rambus.com>
> >
> --
> Maciej Pijanowski
> Embedded Systems Engineer
> GPG: 9963C36AAC3B2B46
> https://3mdeb.com | @3mdeb_com
Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953
Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.
** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
Rambus Inc.<http://www.rambus.com>
> -----Original Message-----
> From: Maciej Pijanowski <[email protected]>
> Sent: Tuesday, February 2, 2021 10:16 AM
> To: Van Leeuwen, Pascal <[email protected]>; [email protected]
> Cc: [email protected]; [email protected]; Piotr Król <[email protected]>
> Subject: Re: safexcel driver for EIP197 and mini firmware features
>
> <<< External Email >>>
>
> On 02.02.2021 09:48, Van Leeuwen, Pascal wrote:
> > Hello Maciej,
> Hello,
> >
> >> -----Original Message-----
> >> From: Maciej Pijanowski <[email protected]>
> >> Sent: Monday, February 1, 2021 7:53 PM
> >> To: [email protected]
> >> Cc: [email protected]; [email protected]; Piotr Król <[email protected]>
> >> Subject: safexcel driver for EIP197 and mini firmware features
> >>
> >> <<< External Email >>>
> >> Hello,
> >>
> >> I am interested in using the EIP197 crypto accelerator. I am aware that
> >> it requires an NDA
> >> to obtain the firmware for it, but I found out that there is some kind
> >> of "minifw" as well
> >> in the linux-firmware tree [3]. I found no description of it - I would
> >> like to learn what
> >> are the features and limitations of this "minifw".
> >>
> > Actually, from the perspective of what that firmware normally does, it does not have any features
> > at all :-) Ok, except for cache invalidates, which the EIP-197 requires.
> > It just bypasses everything from the inputs to the internal crypto engine, effectively turning the
> > EIP-197 into an EIP-97 with caches & prefetching.
> >
> > But that's OK for the Linux kernel driver, because that was using the EIP-197 in EIP-97 backward
> > compatibility mode anyway. It does not support any advanced EIP-197 firmware features.
> > So from the perspective of the current Linux driver: no limitations.
> Thank you very much for the response. That is much more clear now.
> >
> >> I started with using it on the Debian image from board vendor [2]. The
> >> kernel here is
> >> 5.1.0. The firmware is loaded, but the ALG tests are all failing:
> >>
> >> [14785.750246] crypto-safexcel f2800000.crypto: firmware: direct-loading
> >> firmware inside-secure/eip197b/ifpp.bin
> >> [14785.762765] crypto-safexcel f2800000.crypto: firmware: direct-loading
> >> firmware inside-secure/eip197b/ipue.bin
> >> [14785.777978] alg: skcipher: safexcel-cbc-des encryption test failed
> >> (wrong output IV) on test vector 0, cfg="in-place"
> >> [14785.788661] 00000000: fe dc ba 98 76 54 32 10
> >> [14785.800606] alg: skcipher: safexcel-cbc-des3_ede encryption test
> >> failed (wrong output IV) on test vector 0, cfg="in-place"
> >> [14785.811720] 00000000: 7d 33 88 93 0f 93 b2 42
> >> [14785.823734] alg: skcipher: safexcel-cbc-aes encryption test failed
> >> (wrong output IV) on test vector 0, cfg="in-place"
> >> [14785.834439] 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f ac 41
> >> [14785.884568] alg: hash: safexcel-hmac-sha224 test failed (wrong
> >> result) on test vector 3, cfg="init+update+update+final two even splits"
> >> [14785.901836] alg: hash: safexcel-hmac-sha256 test failed (wrong
> >> result) on test vector 2, cfg="import/export"
> >> [14785.926693] alg: aead: safexcel-authenc-hmac-sha1-cbc-aes encryption
> >> test failed (wrong result) on test vector 0, cfg="misaligned splits
> >> crossing pages, inplace"
> >> [14785.944430] alg: No test for authenc(hmac(sha224),cbc(aes))
> >> (safexcel-authenc-hmac-sha224-cbc-aes)
> >> [14785.956978] alg: aead: safexcel-authenc-hmac-sha256-cbc-aes
> >> encryption test failed (wrong result) on test vector 0, cfg="two even
> >> aligned splits"
> >> [14785.973472] alg: No test for authenc(hmac(sha384),cbc(aes))
> >> (safexcel-authenc-hmac-sha384-cbc-aes)
> >> [14785.986103] alg: aead: safexcel-authenc-hmac-sha512-cbc-aes
> >> encryption test failed (wrong result) on test vector 0, cfg="two even
> >> aligned splits"
> >>
> > Ok, that is unexpected. Although I know there is one particular kernel version that was broken.
> > So you might want to try a slightly newer one.
> > (I'd love to try 5.1 myself but I don't have access to the hardware right now, working from home)
> I am going to try with 5.10.12 and let you know with the results.
> >
> >> I am going to test it with more recent, mainline kernel as well, but it
> >> would be still nice to learn
> >> a little bit more about this "minifw", it's features, and what could be
> >> possibly achieved on this
> >> board without proprietary (and behind NDA) crypto firmware.
> >>
> > Everything the kernel driver currently supports.
> > The real firmware is for doing full protocol offload (like IPsec, DTLS, etc.) which the Linux kernel
> > does not currently support anyway. (unfortunately, I might add)
> Are you aware of any other system (OS) or implementation which takes
> advantage of more of the EIP197 features (like the mentioned IPsec offload)?
>
For the specific integration case of the 8040, which is bus attached lookaside, something like
OpenDataPlane or DPDK should work, provided you have drivers for the EIP-197.
Which have to come from the chip vendor, as we only provide driver development kits (to
our customers only), not final drivers. Official maintainer of the kernel driver is still
Bootlin, who worked on this on behalf of Marvell. I'm just helping out where I can.
(Interestingly, it seems like Antoine - still the official maintainer - has left Bootlin?)
I know Marvell has an ODP driver for the EIP-197, but IIRC that is from before they actually
added protocol offload to ODP, so it's probably still basic crypto only, as I think they stopped
actively supporting Armada years ago, about when they acquired Cavium.
Anyway, it's still available from MarvellEmbeddedProcessors/odp-marvell.
Marvell also had a thing called MUSDK, which is proprietary but may support more advanced
features of the EIP-197(?). Try MarvellEmbeddedProcessors/musdk-marvell on GitHub.
And just generally, if you want to have help using your Marvell platform, it seems like you
should try to get that from Marvell directly (but perhaps you already tried that?).
In any case, I'm not aware of any OS/driver/platform that will give you automatic protocol
offload support without having to invest in the application software (either creating it,
porting it or acquiring it from some 3rd party like 6WINDgate)
> >
> >> Thank you,
> >>
> >>
> >> [1]
> >> https://www.solid-run.com/embedded-networking/marvell-armada-family/clearfog-gt-8k/
> >> [2] https://images.solid-build.xyz/8040/Debian/
> >> [3]
> >> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/inside-
> >> secure/eip197_minifw/ifpp.bin?id=eefb5f7410150c00d0ab5c41c5d817ae9bf449b3
> >>
> >> --
> >> Maciej Pijanowski
> >> Embedded Systems Engineer
> >> GPG: 9963C36AAC3B2B46
> >> https://3mdeb.com | @3mdeb_com
> > Regards,
> > Pascal van Leeuwen
> > Silicon IP Architect Multi-Protocol Engines, Rambus Security
> > Rambus ROTW Holding BV
> > +31-73 6581953
> >
> > Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
> > Please be so kind to update your e-mail address book with my new e-mail address.
> >
> >
> > ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential
> and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it.
> Please delete the message and attachments and notify the sender immediately. **
> >
> > Rambus Inc.<http://www.rambus.com>
>
> --
> Maciej Pijanowski
> Embedded Systems Engineer
> GPG: 9963C36AAC3B2B46
> https://3mdeb.com | @3mdeb_com
Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953
Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.
** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
Rambus Inc.<http://www.rambus.com>
On 03.02.2021 12:04, Van Leeuwen, Pascal wrote:
>> -----Original Message-----
>> From: Maciej Pijanowski <[email protected]>
>> Sent: Wednesday, February 3, 2021 11:00 AM
>> To: Van Leeuwen, Pascal <[email protected]>; [email protected]
>> Cc: [email protected]; [email protected]; Piotr Król <[email protected]>
>> Subject: Re: safexcel driver for EIP197 and mini firmware features
>>
>> <<< External Email >>>
>>
>> On 02.02.2021 10:15, Maciej Pijanowski wrote:
>>> On 02.02.2021 09:48, Van Leeuwen, Pascal wrote:
>>>> Hello Maciej,
>>> Hello,
>>>>> -----Original Message-----
>>>>> From: Maciej Pijanowski <[email protected]>
>>>>> Sent: Monday, February 1, 2021 7:53 PM
>>>>> To: [email protected]
>>>>> Cc: [email protected]; [email protected]; Piotr Król
>>>>> <[email protected]>
>>>>> Subject: safexcel driver for EIP197 and mini firmware features
>>>>>
>>>>> <<< External Email >>>
>>>>> Hello,
>>>>>
>>>>> I am interested in using the EIP197 crypto accelerator. I am aware that
>>>>> it requires an NDA
>>>>> to obtain the firmware for it, but I found out that there is some kind
>>>>> of "minifw" as well
>>>>> in the linux-firmware tree [3]. I found no description of it - I would
>>>>> like to learn what
>>>>> are the features and limitations of this "minifw".
>>>>>
>>>> Actually, from the perspective of what that firmware normally does,
>>>> it does not have any features
>>>> at all :-) Ok, except for cache invalidates, which the EIP-197 requires.
>>>> It just bypasses everything from the inputs to the internal crypto
>>>> engine, effectively turning the
>>>> EIP-197 into an EIP-97 with caches & prefetching.
>>>>
>>>> But that's OK for the Linux kernel driver, because that was using the
>>>> EIP-197 in EIP-97 backward
>>>> compatibility mode anyway. It does not support any advanced EIP-197
>>>> firmware features.
>>>> So from the perspective of the current Linux driver: no limitations.
>>> Thank you very much for the response. That is much more clear now.
>>>>> I started with using it on the Debian image from board vendor [2]. The
>>>>> kernel here is
>>>>> 5.1.0. The firmware is loaded, but the ALG tests are all failing:
>>>>>
>>>>> [14785.750246] crypto-safexcel f2800000.crypto: firmware:
>>>>> direct-loading
>>>>> firmware inside-secure/eip197b/ifpp.bin
>>>>> [14785.762765] crypto-safexcel f2800000.crypto: firmware:
>>>>> direct-loading
>>>>> firmware inside-secure/eip197b/ipue.bin
>>>>> [14785.777978] alg: skcipher: safexcel-cbc-des encryption test failed
>>>>> (wrong output IV) on test vector 0, cfg="in-place"
>>>>> [14785.788661] 00000000: fe dc ba 98 76 54 32 10
>>>>> [14785.800606] alg: skcipher: safexcel-cbc-des3_ede encryption test
>>>>> failed (wrong output IV) on test vector 0, cfg="in-place"
>>>>> [14785.811720] 00000000: 7d 33 88 93 0f 93 b2 42
>>>>> [14785.823734] alg: skcipher: safexcel-cbc-aes encryption test failed
>>>>> (wrong output IV) on test vector 0, cfg="in-place"
>>>>> [14785.834439] 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f
>>>>> ac 41
>>>>> [14785.884568] alg: hash: safexcel-hmac-sha224 test failed (wrong
>>>>> result) on test vector 3, cfg="init+update+update+final two even
>>>>> splits"
>>>>> [14785.901836] alg: hash: safexcel-hmac-sha256 test failed (wrong
>>>>> result) on test vector 2, cfg="import/export"
>>>>> [14785.926693] alg: aead: safexcel-authenc-hmac-sha1-cbc-aes encryption
>>>>> test failed (wrong result) on test vector 0, cfg="misaligned splits
>>>>> crossing pages, inplace"
>>>>> [14785.944430] alg: No test for authenc(hmac(sha224),cbc(aes))
>>>>> (safexcel-authenc-hmac-sha224-cbc-aes)
>>>>> [14785.956978] alg: aead: safexcel-authenc-hmac-sha256-cbc-aes
>>>>> encryption test failed (wrong result) on test vector 0, cfg="two even
>>>>> aligned splits"
>>>>> [14785.973472] alg: No test for authenc(hmac(sha384),cbc(aes))
>>>>> (safexcel-authenc-hmac-sha384-cbc-aes)
>>>>> [14785.986103] alg: aead: safexcel-authenc-hmac-sha512-cbc-aes
>>>>> encryption test failed (wrong result) on test vector 0, cfg="two even
>>>>> aligned splits"
>>>>>
>>>> Ok, that is unexpected. Although I know there is one particular
>>>> kernel version that was broken.
>>>> So you might want to try a slightly newer one.
>>>> (I'd love to try 5.1 myself but I don't have access to the hardware
>>>> right now, working from home)
>>> I am going to try with 5.10.12 and let you know with the results.
>> This is the first result with 5.10.12 mainline kernel:
>>
>> [ 1.678251] mmcblk0rpmb: mmc0:0001 8GTF4R partition 3 512 KiB,
>> chardev (239:0)
>> [ 182.882113] random: fast init done
>> [ 185.308594] crypto-safexcel f2800000.crypto: HW init failed (-11)
>> [ 185.314737] ------------[ cut here ]------------
>> [ 185.319379] WARNING: CPU: 2 PID: 1 at kernel/irq/manage.c:1777
>> free_irq+0x31c/0x350
>> [ 185.327065] Modules linked in:
>> [ 185.330134] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.10.12-dirty #1
>> [ 185.336687] Hardware name: SolidRun ClearFog GT 8K (DT)
>> [ 185.341934] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
>> [ 185.347964] pc : free_irq+0x31c/0x350
>> [ 185.351640] lr : free_irq+0x300/0x350
>> [ 185.355315] sp : ffff80001160baf0
>> [ 185.358641] x29: ffff80001160baf0 x28: 0000000000000000
>> [ 185.363976] x27: ffff8000111d1078 x26: ffff8000111404b8
>> [ 185.369310] x25: 000000000000002d x24: ffff0001016036dc
>> [ 185.374644] x23: ffff000101603790 x22: ffff0001015db180
>> [ 185.379978] x21: 0000000000000000 x20: ffff0001015da700
>> [ 185.385313] x19: ffff000101603600 x18: 0000000000000010
>> [ 185.390647] x17: 00000000000000a9 x16: 0000000000000087
>> [ 185.395981] x15: ffff000100078478 x14: 0000000000000102
>> [ 185.401316] x13: ffff000100078478 x12: 00000000ffffffea
>> [ 185.406649] x11: 0000000000000040 x10: ffff8000114322a0
>> [ 185.411983] x9 : ffff800011432298 x8 : ffff000100400270
>> [ 185.417318] x7 : 0000000000000000 x6 : 0000000000000000
>> [ 185.422651] x5 : ffff000100400248 x4 : ffff8000115b0000
>> [ 185.427985] x3 : ffff8000115b0188 x2 : 0000000000020000
>> [ 185.433319] x1 : ffff000101603600 x0 : ffff800010c87198
>> [ 185.438654] Call trace:
>> [ 185.441109] free_irq+0x31c/0x350
>> [ 185.444437] devm_irq_release+0x18/0x28
>> [ 185.448289] release_nodes+0x1b0/0x228
>> [ 185.452052] devres_release_all+0x38/0x60
>> [ 185.456077] really_probe+0x1e4/0x3b0
>> [ 185.459753] driver_probe_device+0x58/0xb8
>> [ 185.463865] device_driver_attach+0x74/0x80
>> [ 185.468063] __driver_attach+0x58/0xe0
>> [ 185.471827] bus_for_each_dev+0x70/0xc8
>> [ 185.475677] driver_attach+0x24/0x30
>> [ 185.479265] bus_add_driver+0x14c/0x1f0
>> [ 185.483116] driver_register+0x64/0x120
>> [ 185.486965] __platform_driver_register+0x48/0x58
>> [ 185.491690] safexcel_init+0x48/0x70
>> [ 185.495279] do_one_initcall+0x54/0x1b8
>> [ 185.499130] kernel_init_freeable+0x1d4/0x23c
>> [ 185.503505] kernel_init+0x14/0x118
>> [ 185.507005] ret_from_fork+0x10/0x34
>> [ 185.510596] ---[ end trace a5f4f63f649fa735 ]---
>> [ 185.515370] crypto-safexcel: probe of f2800000.crypto failed with
>> error -11
>> [ 185.522632] usbcore: registered new interface driver usbhid
>>
>> The "HW init failed" comes from here:
>> https://elixir.bootlin.com/linux/v5.10.12/source/drivers/crypto/inside-secure/safexcel.c#L1692
>> Interestingly, I cannot see in the driver code (at least at a first
>> glance) where the (-11)
>> error code would come from.
>>
>> Any hints?
>>
> It's a weird error code indeed. -11 would be ... EAGAIN? That's certainly not something local.
> So it must be some error code passed on from some Linux kernel API function call.
> My best guess at the moment would be the firmware load call (firmware_request_nowarn).
> But it would have been helpful to see the driver logging _prior_ to HW init failed, to see
> which parts of the initialization _did_ succeed properly.
>
>> Do you have a known working kernel version for this driver?
>>
> I've seen a lot of kernel versions work just fine in the past.
>
> 5.4 - 5.8 should definitely work just fine. Last time I tried was September of last year,
> when I tried to get some fix in for a customer of ours. (but had to give up due to the patch
> not being accepted as such and me not having the time to redo it as suggested)
> In any case, whatever was in development (5.10?) at the time still worked fine on my side.
>
> In any case, I only know of one older kernel version that was truly broken. Could be the 5.1
> you tried, don't remember exactly ...
I will try with one of these suggested versions and maybe add some
logging in the initialization as suggested above. Thanks.
>
>> Thank you,
>>
>>>>> I am going to test it with more recent, mainline kernel as well, but it
>>>>> would be still nice to learn
>>>>> a little bit more about this "minifw", it's features, and what could be
>>>>> possibly achieved on this
>>>>> board without proprietary (and behind NDA) crypto firmware.
>>>>>
>>>> Everything the kernel driver currently supports.
>>>> The real firmware is for doing full protocol offload (like IPsec,
>>>> DTLS, etc.) which the Linux kernel
>>>> does not currently support anyway. (unfortunately, I might add)
>>> Are you aware of any other system (OS) or implementation which takes
>>> advantage of more of the EIP197 features (like the mentioned IPsec
>>> offload)?
>>>>> Thank you,
>>>>>
>>>>>
>>>>> [1]
>>>>> https://www.solid-run.com/embedded-networking/marvell-armada-family/clearfog-gt-8k/
>>>>>
>>>>> [2] https://images.solid-build.xyz/8040/Debian/
>>>>> [3]
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/inside-
>>>>>
>>>>> secure/eip197_minifw/ifpp.bin?id=eefb5f7410150c00d0ab5c41c5d817ae9bf449b3
>>>>>
>>>>>
>>>>> --
>>>>> Maciej Pijanowski
>>>>> Embedded Systems Engineer
>>>>> GPG: 9963C36AAC3B2B46
>>>>> https://3mdeb.com | @3mdeb_com
>>>> Regards,
>>>> Pascal van Leeuwen
>>>> Silicon IP Architect Multi-Protocol Engines, Rambus Security
>>>> Rambus ROTW Holding BV
>>>> +31-73 6581953
>>>>
>>>> Note: The Inside Secure/Verimatrix Silicon IP team was recently
>>>> acquired by Rambus.
>>>> Please be so kind to update your e-mail address book with my new
>>>> e-mail address.
>>>>
>>>>
>>>> ** This message and any attachments are for the sole use of the
>>>> intended recipient(s). It may contain information that is
>>>> confidential and privileged. If you are not the intended recipient of
>>>> this message, you are prohibited from printing, copying, forwarding
>>>> or saving it. Please delete the message and attachments and notify
>>>> the sender immediately. **
>>>>
>>>> Rambus Inc.<http://www.rambus.com>
>> --
>> Maciej Pijanowski
>> Embedded Systems Engineer
>> GPG: 9963C36AAC3B2B46
>> https://3mdeb.com | @3mdeb_com
> Regards,
> Pascal van Leeuwen
> Silicon IP Architect Multi-Protocol Engines, Rambus Security
> Rambus ROTW Holding BV
> +31-73 6581953
>
> Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
> Please be so kind to update your e-mail address book with my new e-mail address.
>
>
> ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
>
> Rambus Inc.<http://www.rambus.com>
--
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com
On 02.02.2021 10:15, Maciej Pijanowski wrote:
>
> On 02.02.2021 09:48, Van Leeuwen, Pascal wrote:
>> Hello Maciej,
> Hello,
>>
>>> -----Original Message-----
>>> From: Maciej Pijanowski <[email protected]>
>>> Sent: Monday, February 1, 2021 7:53 PM
>>> To: [email protected]
>>> Cc: [email protected]; [email protected]; Piotr Król
>>> <[email protected]>
>>> Subject: safexcel driver for EIP197 and mini firmware features
>>>
>>> <<< External Email >>>
>>> Hello,
>>>
>>> I am interested in using the EIP197 crypto accelerator. I am aware that
>>> it requires an NDA
>>> to obtain the firmware for it, but I found out that there is some kind
>>> of "minifw" as well
>>> in the linux-firmware tree [3]. I found no description of it - I would
>>> like to learn what
>>> are the features and limitations of this "minifw".
>>>
>> Actually, from the perspective of what that firmware normally does,
>> it does not have any features
>> at all :-) Ok, except for cache invalidates, which the EIP-197 requires.
>> It just bypasses everything from the inputs to the internal crypto
>> engine, effectively turning the
>> EIP-197 into an EIP-97 with caches & prefetching.
>>
>> But that's OK for the Linux kernel driver, because that was using the
>> EIP-197 in EIP-97 backward
>> compatibility mode anyway. It does not support any advanced EIP-197
>> firmware features.
>> So from the perspective of the current Linux driver: no limitations.
> Thank you very much for the response. That is much more clear now.
>>
>>> I started with using it on the Debian image from board vendor [2]. The
>>> kernel here is
>>> 5.1.0. The firmware is loaded, but the ALG tests are all failing:
>>>
>>> [14785.750246] crypto-safexcel f2800000.crypto: firmware:
>>> direct-loading
>>> firmware inside-secure/eip197b/ifpp.bin
>>> [14785.762765] crypto-safexcel f2800000.crypto: firmware:
>>> direct-loading
>>> firmware inside-secure/eip197b/ipue.bin
>>> [14785.777978] alg: skcipher: safexcel-cbc-des encryption test failed
>>> (wrong output IV) on test vector 0, cfg="in-place"
>>> [14785.788661] 00000000: fe dc ba 98 76 54 32 10
>>> [14785.800606] alg: skcipher: safexcel-cbc-des3_ede encryption test
>>> failed (wrong output IV) on test vector 0, cfg="in-place"
>>> [14785.811720] 00000000: 7d 33 88 93 0f 93 b2 42
>>> [14785.823734] alg: skcipher: safexcel-cbc-aes encryption test failed
>>> (wrong output IV) on test vector 0, cfg="in-place"
>>> [14785.834439] 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f
>>> ac 41
>>> [14785.884568] alg: hash: safexcel-hmac-sha224 test failed (wrong
>>> result) on test vector 3, cfg="init+update+update+final two even
>>> splits"
>>> [14785.901836] alg: hash: safexcel-hmac-sha256 test failed (wrong
>>> result) on test vector 2, cfg="import/export"
>>> [14785.926693] alg: aead: safexcel-authenc-hmac-sha1-cbc-aes encryption
>>> test failed (wrong result) on test vector 0, cfg="misaligned splits
>>> crossing pages, inplace"
>>> [14785.944430] alg: No test for authenc(hmac(sha224),cbc(aes))
>>> (safexcel-authenc-hmac-sha224-cbc-aes)
>>> [14785.956978] alg: aead: safexcel-authenc-hmac-sha256-cbc-aes
>>> encryption test failed (wrong result) on test vector 0, cfg="two even
>>> aligned splits"
>>> [14785.973472] alg: No test for authenc(hmac(sha384),cbc(aes))
>>> (safexcel-authenc-hmac-sha384-cbc-aes)
>>> [14785.986103] alg: aead: safexcel-authenc-hmac-sha512-cbc-aes
>>> encryption test failed (wrong result) on test vector 0, cfg="two even
>>> aligned splits"
>>>
>> Ok, that is unexpected. Although I know there is one particular
>> kernel version that was broken.
>> So you might want to try a slightly newer one.
>> (I'd love to try 5.1 myself but I don't have access to the hardware
>> right now, working from home)
> I am going to try with 5.10.12 and let you know with the results.
This is the first result with 5.10.12 mainline kernel:
[ 1.678251] mmcblk0rpmb: mmc0:0001 8GTF4R partition 3 512 KiB,
chardev (239:0)
[ 182.882113] random: fast init done
[ 185.308594] crypto-safexcel f2800000.crypto: HW init failed (-11)
[ 185.314737] ------------[ cut here ]------------
[ 185.319379] WARNING: CPU: 2 PID: 1 at kernel/irq/manage.c:1777
free_irq+0x31c/0x350
[ 185.327065] Modules linked in:
[ 185.330134] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.10.12-dirty #1
[ 185.336687] Hardware name: SolidRun ClearFog GT 8K (DT)
[ 185.341934] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[ 185.347964] pc : free_irq+0x31c/0x350
[ 185.351640] lr : free_irq+0x300/0x350
[ 185.355315] sp : ffff80001160baf0
[ 185.358641] x29: ffff80001160baf0 x28: 0000000000000000
[ 185.363976] x27: ffff8000111d1078 x26: ffff8000111404b8
[ 185.369310] x25: 000000000000002d x24: ffff0001016036dc
[ 185.374644] x23: ffff000101603790 x22: ffff0001015db180
[ 185.379978] x21: 0000000000000000 x20: ffff0001015da700
[ 185.385313] x19: ffff000101603600 x18: 0000000000000010
[ 185.390647] x17: 00000000000000a9 x16: 0000000000000087
[ 185.395981] x15: ffff000100078478 x14: 0000000000000102
[ 185.401316] x13: ffff000100078478 x12: 00000000ffffffea
[ 185.406649] x11: 0000000000000040 x10: ffff8000114322a0
[ 185.411983] x9 : ffff800011432298 x8 : ffff000100400270
[ 185.417318] x7 : 0000000000000000 x6 : 0000000000000000
[ 185.422651] x5 : ffff000100400248 x4 : ffff8000115b0000
[ 185.427985] x3 : ffff8000115b0188 x2 : 0000000000020000
[ 185.433319] x1 : ffff000101603600 x0 : ffff800010c87198
[ 185.438654] Call trace:
[ 185.441109] free_irq+0x31c/0x350
[ 185.444437] devm_irq_release+0x18/0x28
[ 185.448289] release_nodes+0x1b0/0x228
[ 185.452052] devres_release_all+0x38/0x60
[ 185.456077] really_probe+0x1e4/0x3b0
[ 185.459753] driver_probe_device+0x58/0xb8
[ 185.463865] device_driver_attach+0x74/0x80
[ 185.468063] __driver_attach+0x58/0xe0
[ 185.471827] bus_for_each_dev+0x70/0xc8
[ 185.475677] driver_attach+0x24/0x30
[ 185.479265] bus_add_driver+0x14c/0x1f0
[ 185.483116] driver_register+0x64/0x120
[ 185.486965] __platform_driver_register+0x48/0x58
[ 185.491690] safexcel_init+0x48/0x70
[ 185.495279] do_one_initcall+0x54/0x1b8
[ 185.499130] kernel_init_freeable+0x1d4/0x23c
[ 185.503505] kernel_init+0x14/0x118
[ 185.507005] ret_from_fork+0x10/0x34
[ 185.510596] ---[ end trace a5f4f63f649fa735 ]---
[ 185.515370] crypto-safexcel: probe of f2800000.crypto failed with
error -11
[ 185.522632] usbcore: registered new interface driver usbhid
The "HW init failed" comes from here:
https://elixir.bootlin.com/linux/v5.10.12/source/drivers/crypto/inside-secure/safexcel.c#L1692
Interestingly, I cannot see in the driver code (at least at a first
glance) where the (-11)
error code would come from.
Any hints?
Do you have a known working kernel version for this driver?
Thank you,
>>
>>> I am going to test it with more recent, mainline kernel as well, but it
>>> would be still nice to learn
>>> a little bit more about this "minifw", it's features, and what could be
>>> possibly achieved on this
>>> board without proprietary (and behind NDA) crypto firmware.
>>>
>> Everything the kernel driver currently supports.
>> The real firmware is for doing full protocol offload (like IPsec,
>> DTLS, etc.) which the Linux kernel
>> does not currently support anyway. (unfortunately, I might add)
> Are you aware of any other system (OS) or implementation which takes
> advantage of more of the EIP197 features (like the mentioned IPsec
> offload)?
>>
>>> Thank you,
>>>
>>>
>>> [1]
>>> https://www.solid-run.com/embedded-networking/marvell-armada-family/clearfog-gt-8k/
>>>
>>> [2] https://images.solid-build.xyz/8040/Debian/
>>> [3]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/inside-
>>>
>>> secure/eip197_minifw/ifpp.bin?id=eefb5f7410150c00d0ab5c41c5d817ae9bf449b3
>>>
>>>
>>> --
>>> Maciej Pijanowski
>>> Embedded Systems Engineer
>>> GPG: 9963C36AAC3B2B46
>>> https://3mdeb.com | @3mdeb_com
>> Regards,
>> Pascal van Leeuwen
>> Silicon IP Architect Multi-Protocol Engines, Rambus Security
>> Rambus ROTW Holding BV
>> +31-73 6581953
>>
>> Note: The Inside Secure/Verimatrix Silicon IP team was recently
>> acquired by Rambus.
>> Please be so kind to update your e-mail address book with my new
>> e-mail address.
>>
>>
>> ** This message and any attachments are for the sole use of the
>> intended recipient(s). It may contain information that is
>> confidential and privileged. If you are not the intended recipient of
>> this message, you are prohibited from printing, copying, forwarding
>> or saving it. Please delete the message and attachments and notify
>> the sender immediately. **
>>
>> Rambus Inc.<http://www.rambus.com>
>
--
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com