Hi all,
Over the past weeks I have been working on the crypto driver for Inside Secure
(EIP97/EIP197) hardware. This started out as a personal side project to be able
to do some architectural exploration using real application software, but as I
started fixing issues I realised these fixes may be generally useful. So I guess
I might want to try upstreaming those.
My problem, however, is that I do not have access to any of the original Marvell
hardware that this driver was developed for, I can only test things on my PCI-E
based FPGA development board with much newer, differently configured hardware in
an x86 PC. So I'm looking for volunteers that actually do have this Marvell HW
at their disposal - Marvell Armada 7K or 8K e.g. Macchiatobin (Riku? You wanted
a driver that did not need to load firmware, this your chance to help out! :-),
Marvell Armada 3700 e.g. Espressobin and Marvell Armada 39x to be exact - and
are willing to help me out with some testing.
Things that I worked on so far:
- all registered ciphersuites now pass the testmgr compliance tests
- fixed stability issues
- removed dependency on external firmware images
- added support for non-Marvell configurations of the EIP97 & EIP197
- added support for the latest HW & FW revisions (3.1) and features
- added support for the Xilinx FPGA development board we're using for our
internal development and for which we also provide images to our customers
Once I manage to get this upstreamed, I plan on working on improving performance
and adding support for additional algorithms our hardware supports.
Anyone out there willing to contribute?
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
http://www.insidesecure.com
Hi Pascal,
On Tue, Apr 30, 2019 at 01:08:27PM +0000, Pascal Van Leeuwen wrote:
>
> Over the past weeks I have been working on the crypto driver for
> Inside Secure (EIP97/EIP197) hardware. This started out as a personal
> side project to be able to do some architectural exploration using
> real application software, but as I started fixing issues I realised
> these fixes may be generally useful. So I guess I might want to try
> upstreaming those.
That's great!
> My problem, however, is that I do not have access to any of the
> original Marvell hardware that this driver was developed for, I can
> only test things on my PCI-E based FPGA development board with much
> newer, differently configured hardware in an x86 PC. So I'm looking
> for volunteers that actually do have this Marvell HW at their disposal
> - Marvell Armada 7K or 8K e.g. Macchiatobin (Riku? You wanted a driver
> that did not need to load firmware, this your chance to help out! :-),
> Marvell Armada 3700 e.g. Espressobin and Marvell Armada 39x to be
> exact - and are willing to help me out with some testing.
I do have access to Marvell boards, having the EIP197 & EIP97 engines. I
can help testing your modifications on those boards. Do you have a
public branch somewhere I can access?
> Things that I worked on so far:
> - all registered ciphersuites now pass the testmgr compliance tests
> - fixed stability issues
> - removed dependency on external firmware images
> - added support for non-Marvell configurations of the EIP97 & EIP197
> - added support for the latest HW & FW revisions (3.1) and features
> - added support for the Xilinx FPGA development board we're using for our
> internal development and for which we also provide images to our customers
I'm happy to see some activity on this driver :) I too was working on
making the boot test suite pass (some tests were not working since the
testmgr rework and improvement), and on performance improvement.
> Once I manage to get this upstreamed, I plan on working on improving
> performance and adding support for additional algorithms our hardware
> supports.
>
> Anyone out there willing to contribute?
If there is a branch publicly available, I'll be happy to give it a
try.
Thanks,
Antoine
--
Antoine T?nart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
> -----Original Message-----
> From: [email protected] [mailto:linux-crypto-
> [email protected]] On Behalf Of [email protected]
> Sent: Tuesday, April 30, 2019 3:27 PM
> To: Pascal Van Leeuwen <[email protected]>
> Cc: [email protected]; [email protected]; Herbert
> Xu <[email protected]>; ' David S. Miller '
> <[email protected]>
> Subject: Re: crypto: inside_secure - call for volunteers
>
> Hi Pascal,
>
> On Tue, Apr 30, 2019 at 01:08:27PM +0000, Pascal Van Leeuwen wrote:
> >
> > Over the past weeks I have been working on the crypto driver for
> > Inside Secure (EIP97/EIP197) hardware. This started out as a personal
> > side project to be able to do some architectural exploration using
> > real application software, but as I started fixing issues I realised
> > these fixes may be generally useful. So I guess I might want to try
> > upstreaming those.
>
> That's great!
>
> > My problem, however, is that I do not have access to any of the
> > original Marvell hardware that this driver was developed for, I can
> > only test things on my PCI-E based FPGA development board with much
> > newer, differently configured hardware in an x86 PC. So I'm looking
> > for volunteers that actually do have this Marvell HW at their
> disposal
> > - Marvell Armada 7K or 8K e.g. Macchiatobin (Riku? You wanted a
> driver
> > that did not need to load firmware, this your chance to help out! :-
> ),
> > Marvell Armada 3700 e.g. Espressobin and Marvell Armada 39x to be
> > exact - and are willing to help me out with some testing.
>
> I do have access to Marvell boards, having the EIP197 & EIP97 engines.
> I
> can help testing your modifications on those boards. Do you have a
> public branch somewhere I can access?
>
I do have a git tree on Github:
https://github.com/pvanleeuwen/linux.git
The branch I've been working on is "is_driver_armada_fix".
I don't actually know if that's publicly accessible or if I need to
do something to make it so ... first time Git user here :-) So let me
know if you have issues accessing that.
Alternatively, I can also send a patch file against the driver that's
currently part of the kernel mainline Git. Or a source tarball FTM.
> > Things that I worked on so far:
> > - all registered ciphersuites now pass the testmgr compliance tests
> > - fixed stability issues
> > - removed dependency on external firmware images
> > - added support for non-Marvell configurations of the EIP97 & EIP197
> > - added support for the latest HW & FW revisions (3.1) and features
> > - added support for the Xilinx FPGA development board we're using for
> our
> > internal development and for which we also provide images to our
> customers
>
> I'm happy to see some activity on this driver :) I too was working on
> making the boot test suite pass (some tests were not working since the
> testmgr rework and improvement), and on performance improvement.
>
> > Once I manage to get this upstreamed, I plan on working on improving
> > performance and adding support for additional algorithms our hardware
> > supports.
> >
> > Anyone out there willing to contribute?
>
> If there is a branch publicly available, I'll be happy to give it a
> try.
>
> Thanks,
> Antoine
>
> --
> Antoine T?nart, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
http://www.insidesecure.com
On Tue, Apr 30, 2019 at 01:41:27PM +0000, Pascal Van Leeuwen wrote:
> >
> > I do have access to Marvell boards, having the EIP197 & EIP97 engines.
> > I
> > can help testing your modifications on those boards. Do you have a
> > public branch somewhere I can access?
> >
> I do have a git tree on Github:
> https://github.com/pvanleeuwen/linux.git
>
> The branch I've been working on is "is_driver_armada_fix".
>
> I don't actually know if that's publicly accessible or if I need to
> do something to make it so ... first time Git user here :-) So let me
> know if you have issues accessing that.
>
> Alternatively, I can also send a patch file against the driver that's
> currently part of the kernel mainline Git. Or a source tarball FTM.
Thanks! Your branch is accessible, I'll be able to have a look at it.
Btw, my current development branch for the EIP driver is at:
https://github.com/atenart/linux/tree/v5.1-rc1/eip-fixes
It contains improvements & fixes for the IV retrieval and HMAC tests.
AEAD still has some issues with some testmgr tests due to the recent
refactoring.
Antoine
--
Antoine T?nart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Riku, Antoine,
It's been 2 weeks already so I'm kind of curious if either one of you
managed to try anything with my modified Inside Secure driver yet?
Note that if you experience any issues at all that:
a) I'd be very interested to hear about them
b) I'm fully willing to help resolve those issues
BTW: if there are no issues and everything worked fine I'm also
interested to hear about that :-)
Regards,
Pascal
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
Tel. : +31 (0)73 65 81 900
http://www.insidesecure.com
Hi Pascal,
On Wed, May 15, 2019 at 09:02:42AM +0000, Pascal Van Leeuwen wrote:
>
> It's been 2 weeks already so I'm kind of curious if either one of you
> managed to try anything with my modified Inside Secure driver yet?
> Note that if you experience any issues at all that:
>
> a) I'd be very interested to hear about them
> b) I'm fully willing to help resolve those issues
>
> BTW: if there are no issues and everything worked fine I'm also
> interested to hear about that :-)
Sorry about the looong delay. I did make a quick test of your series and
had some issues:
- You added use of PCI helpers, but this new dependency wasn't described
in Kconfig (leading to have build issues).
- Using an EIP197 and a MacchiatoBin many of the boot tests did not
pass (but I haven't look into it).
I'll perform the test again to at least give you a trace :)
Btw, I'm available on IRC (atenart on Freenode), that might be easier to
have a discussion when debugging things.
Thanks!
Antoine
--
Antoine T?nart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Monday, May 27, 2019 5:01 PM
> To: Pascal Van Leeuwen <[email protected]>
> Cc: [email protected]; Riku Voipio <[email protected]>; linux-
> [email protected]
> Subject: Re: crypto: inside_secure - call for volunteers
>
<snip>
> Sorry about the looong delay. I did make a quick test of your series and
> had some issues:
> - You added use of PCI helpers, but this new dependency wasn't described
> in Kconfig (leading to have build issues).
>
Ah OK, to be honest, I don't know a whole lot (or much of anything, actually)
about Kconfig, so I just hacked it a bit to be able to select the driver :-)
But it makes sense - the PCIE subsystem is obviously always present on an
x86 PC, so I'm getting that for free. I guess some Marvell board configs
don't include the PCIE stuff?
I guess the best approach would to config out the PCIE code if the
PCIE subsystem is not configured in (instead of adding the dependency).
> - Using an EIP197 and a MacchiatoBin many of the boot tests did not
> pass (but I haven't look into it).
>
Actually, if you use driver code from before yesterday with Herbert's
crypto2.6 git tree, then the fuzzing tests would have failed.
I originally developed directly against Linus' 5.1 tree, which apparently
did not contain those fuzzing tests yet.
> I'll perform the test again to at least give you a trace :)
>
Please sync with my Git tree before trying, that should help a lot.
> Btw, I'm available on IRC (atenart on Freenode), that might be easier to
> have a discussion when debugging things.
>
I'll see if I can get some IRC client installed over here.
Haven't used IRC in over a decade, didn't know it still existed ...
Thanks,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
http://www.insidesecure.com
Hello Pascal,
On Mon, May 27, 2019 at 09:06:48PM +0000, Pascal Van Leeuwen wrote:
> > From: [email protected] [mailto:[email protected]]
> > - You added use of PCI helpers, but this new dependency wasn't described
> > in Kconfig (leading to have build issues).
> >
> Ah OK, to be honest, I don't know a whole lot (or much of anything, actually)
> about Kconfig, so I just hacked it a bit to be able to select the driver :-)
> But it makes sense - the PCIE subsystem is obviously always present on an
> x86 PC, so I'm getting that for free. I guess some Marvell board configs
> don't include the PCIE stuff?
PCIE support is only a configuration option, so we could have
configurations not selecting it (for whatever reason). It's not entirely
linked to the hardware having a PCIe controller or not.
> I guess the best approach would to config out the PCIE code if the
> PCIE subsystem is not configured in (instead of adding the dependency).
That would be one option.
> > - Using an EIP197 and a MacchiatoBin many of the boot tests did not
> > pass (but I haven't look into it).
> >
> Actually, if you use driver code from before yesterday with Herbert's
> crypto2.6 git tree, then the fuzzing tests would have failed.
> I originally developed directly against Linus' 5.1 tree, which apparently
> did not contain those fuzzing tests yet.
I think basic boot tests failed as well. But I'll run this again and let
you know :)
Antoine
--
Antoine T?nart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com