Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>
To:     Antoine Tenart <antoine.tenart@bootlin.com>,
        Pascal van Leeuwen <pascalvanl@gmail.com>
CC:     "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "davem@davemloft.net" <davem@davemloft.net>
Subject: RE: [PATCH 3/3] crypto: inside-secure - add support for using the
 EIP197 without firmware images
Thread-Topic: [PATCH 3/3] crypto: inside-secure - add support for using the
 EIP197 without firmware images
Thread-Index: AQHVJaNNu6u4U0xf7kGF/n6JpxvKYaai6XuAgAAgPJA=
Date:   Wed, 19 Jun 2019 14:37:44 +0000
Message-ID: <AM6PR09MB3523D2FEC3A543FF037812DCD2E50@AM6PR09MB3523.eurprd09.prod.outlook.com>
References: <1560837384-29814-1-git-send-email-pvanleeuwen@insidesecure.com>
 <1560837384-29814-4-git-send-email-pvanleeuwen@insidesecure.com>
 <20190619122737.GB3254@kwain>
In-Reply-To: <20190619122737.GB3254@kwain>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: insidesecure.com does not
 designate permitted sender hosts)
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: bc2b27ff-a9cb-4617-1bdd-08d6f4c3b13a
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2019 14:37:44.6560
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3c07df58-7760-4e85-afd5-84803eac70ce
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pvanleeuwen@insidesecure.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR09MB3432
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

Thanks for the comments!

> -----Original Message-----
> From: Antoine Tenart <antoine.tenart@bootlin.com>
> Sent: Wednesday, June 19, 2019 2:28 PM
> To: Pascal van Leeuwen <pascalvanl@gmail.com>
> Cc: linux-crypto@vger.kernel.org; antoine.tenart@bootlin.com; herbert@gon=
dor.apana.org.au;
> davem@davemloft.net; Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>
> Subject: Re: [PATCH 3/3] crypto: inside-secure - add support for using th=
e EIP197 without
> firmware images
>=20
> Hi Pascal,
>=20
> On Tue, Jun 18, 2019 at 07:56:24AM +0200, Pascal van Leeuwen wrote:
> >
> >  static int eip197_load_firmwares(struct safexcel_crypto_priv *priv)
> >  {
> > +	/*
> > +	 * The embedded one-size-fits-all MiniFW is just for handling TR
> > +	 * prefetch & invalidate. It does not support any FW flows, effective=
ly
> > +	 * turning the EIP197 into a glorified EIP97
> > +	 */
> > +	const u32 ipue_minifw[] =3D {
> > +		 0x24808200, 0x2D008204, 0x2680E208, 0x2780E20C,
> > +		 0x2200F7FF, 0x38347000, 0x2300F000, 0x15200A80,
> > +		 0x01699003, 0x60038011, 0x38B57000, 0x0119F04C,
> > +		 0x01198548, 0x20E64000, 0x20E75000, 0x1E200000,
> > +		 0x30E11000, 0x103A93FF, 0x60830014, 0x5B8B0000,
> > +		 0xC0389000, 0x600B0018, 0x2300F000, 0x60800011,
> > +		 0x90800000, 0x10000000, 0x10000000};
> > +	const u32 ifpp_minifw[] =3D {
> > +		 0x21008000, 0x260087FC, 0xF01CE4C0, 0x60830006,
> > +		 0x530E0000, 0x90800000, 0x23008004, 0x24808008,
> > +		 0x2580800C, 0x0D300000, 0x205577FC, 0x30D42000,
> > +		 0x20DAA7FC, 0x43107000, 0x42220004, 0x00000000,
> > +		 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> > +		 0x00060004, 0x20337004, 0x90800000, 0x10000000,
> > +		 0x10000000};
>=20
> What is the license of this firmware? With this patch, it would be
> shipped with Linux kernel images and this question is then very
> important.
>=20
I am very well aware of that. The driver under GPL 2.0 so that simply
would also apply to this. This was written by me specifically for this
particular driver anyway and my company allows me to GPL this stuff.

> In addition to this, the direction the kernel has taken was to *remove*
> binary firmwares from its source code. I'm afraid adding this is a
> no-go.
>=20
Actually, I would like to argue against that here.

For a HW engineer, there really is no fundamental difference between
control register contents or an instruction word. They can both have
the exact same effects internal to the HW.
If I had disguised this as a handful of config reg writes writing=20
some #define'd magic values, probably no one would have even noticed.

This is not firmware for some general purpose CPU, it is firmware=20
for some very dedicated microengine thingy controlling some local
datapath. By that same definition, the tokens the driver generates
for processing could be considered "firmware" as well (as they are
used by the hardware in a very similar way) ...

> The proper solution I believe would be to support loading this "MiniFW",
> which (depending on the license) could be either distributed in the
> rootfs and loaded (like what's done currently), or through
> CONFIG_EXTRA_FIRMWARE.
>=20
That seems total overkill for just a handful of words though.
But I can do that if the community insists ...

> This should be discussed first before discussing the implementation of
> this particular patch.
>=20
> Thanks!
> Antoine
>=20
> --
> Antoine T=E9nart, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com


Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
www.insidesecure.com