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>
CC:     Pascal van Leeuwen <pascalvanl@gmail.com>,
        "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/n6JpxvKYaai6XuAgAAgPJCAAX9kAIAAGfRA
Date:   Thu, 20 Jun 2019 14:59:20 +0000
Message-ID: <AM6PR09MB35236CA6971A1B6D03AB9BD4D2E40@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>
 <AM6PR09MB3523D2FEC3A543FF037812DCD2E50@AM6PR09MB3523.eurprd09.prod.outlook.com>
 <20190620131512.GB4642@kwain>
In-Reply-To: <20190620131512.GB4642@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: a621267e-0b93-4ec5-03a5-08d6f58fdffa
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2019 14:59:20.5327
 (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: AM6PR09MB2728
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

> -----Original Message-----
> From: Antoine Tenart <antoine.tenart@bootlin.com>
> Sent: Thursday, June 20, 2019 3:15 PM
> To: Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>
> Cc: Antoine Tenart <antoine.tenart@bootlin.com>; Pascal van Leeuwen <pasc=
alvanl@gmail.com>; linux-crypto@vger.kernel.org;
> herbert@gondor.apana.org.au; davem@davemloft.net
> Subject: Re: [PATCH 3/3] crypto: inside-secure - add support for using th=
e EIP197 without firmware images
>=20
> Hi Pascal,
>=20
> On Wed, Jun 19, 2019 at 02:37:44PM +0000, Pascal Van Leeuwen wrote:
> > > From: Antoine Tenart <antoine.tenart@bootlin.com>
> > > On Tue, Jun 18, 2019 at 07:56:24AM +0200, Pascal van Leeuwen wrote:
> >
> > > In addition to this, the direction the kernel has taken was to *remov=
e*
> > > binary firmwares from its source code. I'm afraid adding this is a
> > > no-go.
> >
> > 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
> > some #define'd magic values, probably no one would have even noticed.
>=20
> I do not fully agree. If this is comparable to configuring h/w
> registers, then you could probably have defines explaining why each bit
> is set and what it's doing. Which would be fine.
>=20
Strictly speaking, we (and probably most other HW vendors as well) don't do=
=20
that for every register bit either, not even in the official Programmer Man=
ual.=20
Some bits are just "you don't need to know, just write this" :-)

But I get your point.

> > 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) ...
>=20
> Right. The main difference here is we do have a clear definition of what
> the tokens are doing. Thanks to your explanation, if this firmware is
> really looking like the token we're using, the words have a defined
> structure and the magic values could be generated with proper defines
> and macros. And I think it's the main issue here: it's not acceptable to
> have an array of magic values. If you can give a meaning to those bits,
> I see no reason why it couldn't be added to the driver.
>=20
> (And I'm all for what you're trying to achieve here :)).
>=20
Now we're reaching a tricky subject. Because I think if some people here
find out those token bits are explicitly documented in the driver, they
will not be so happy ... (don't worry, I won't wake any sleeping dogs :-)
We provide this information to our customers under NDA, but it's=20
obviously quite sensitive information as it reveals a lot about the
inner workings of our HW design.

The encoding of the microengine control words is considered even
more sensitive, so we don't even provide that under NDA.
Adding that to the driver will probably get me in trouble.

So maybe putting these images in /lib/firmware is unavoidable, but
I'd really like to hear some more opinions on that subject.

> > > The proper solution I believe would be to support loading this "MiniF=
W",
> > > which (depending on the license) could be either distributed in the
> > > rootfs and loaded (like what's done currently), or through
> > > CONFIG_EXTRA_FIRMWARE.
> > >
> > That seems total overkill for just a handful of words though.
>=20
> Given your explanation, I agree. (If those bits can have meaning).
>=20
> Thanks!
> Antoine
>=20
> --
> Antoine T=E9nart, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Thanks,

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