Received-SPF: pass (google.com: domain of linux-crypto+bounces-4105-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Fri, 10 May 2024 13:31:58 +0200
From: Marek =?UTF-8?B?QmVow7pu?= <kabel@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Gregory CLEMENT <gregory.clement@bootlin.com>, Arnd Bergmann
 <arnd@arndb.de>, soc@kernel.org, arm@kernel.org, Andy Shevchenko
 <andy@kernel.org>, Hans de Goede <hdegoede@redhat.com>, Ilpo
 =?UTF-8?B?SsOkcnZpbmVu?= <ilpo.jarvinen@linux.intel.com>,
 linux-crypto@vger.kernel.org, Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: [PATCH v10 7/9] platform: cznic: turris-omnia-mcu: Add support
 for digital message signing via debugfs
Message-ID: <20240510133158.2f40ee55@dellmb>
In-Reply-To: <2024051007-rendering-borrowing-ffc5@gregkh>
References: <20240510101819.13551-1-kabel@kernel.org>
	<20240510101819.13551-8-kabel@kernel.org>
	<2024051007-rendering-borrowing-ffc5@gregkh>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, 10 May 2024 11:52:56 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Fri, May 10, 2024 at 12:18:17PM +0200, Marek Beh=C3=BAn wrote:
> > Add support for digital message signing with private key stored in the
> > MCU. Boards with MKL MCUs have a NIST256p ECDSA private key created
> > when manufactured. The private key is not readable from the MCU, but
> > MCU allows for signing messages with it and retrieving the public key.
> >=20
> > As described in a similar commit 50524d787de3 ("firmware:
> > turris-mox-rwtm: support ECDSA signatures via debugfs"):
> >   The optimal solution would be to register an akcipher provider via
> >   kernel's crypto API, but crypto API does not yet support accessing
> >   akcipher API from userspace (and probably won't for some time, see
> >   https://www.spinics.net/lists/linux-crypto/msg38388.html).
> >=20
> > Therefore we add support for accessing this signature generation
> > mechanism via debugfs for now, so that userspace can access it. =20
>=20
> Having a "real" user/kernel api in debugfs feels wrong here, why would
> you not do this properly?  On most, if not all, systems, debugfs is
> locked down so you do not have access to it, as it is only there for
> debugging.  So how is a user supposed to use this feature if they can't
> get access to it?
>=20
> And debugfs files can be changed at any time, so how can you ensure that
> your new api will always be there?
>=20
> In other words, please solve this properly, do not just add a hack into
> debugfs that no one can use as that is not a good idea.

Hi Greg,

this is the same thing we discussed 5 years ago, I wanted to implement
it via crypto's akcipher, but was refused due to
  https://www.spinics.net/lists/linux-crypto/msg38388.html

I've then exposed this via debugfs in the turris-mox-rwtm driver 4
years ago, and we have supported this in our utility scripts, with the
plan that to reimplement it in the kernel via the correct ABI once
akcipher (or other ABI) is available to userspace, but AFAIK after 5
years this is still not the case :-(

If not debugfs and not akcipher, another option is to expose this via
sysfs, but that also doesn't seem right, and if I recall correctly you
also disapproved of this 5 years ago.

The last option would be to create another device, something like
/dev/turris-crypto for this. I wanted to avoid that and wait for
akcipher to be exposed do crypto since another /dev device must be
supported forever, while debugfs implementation can be removed once
this is supported via standardized ABI.

Do you have any suggestions?

Marek