All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Marek Vasut <marex@denx.de>
Cc: "Christoph G. Baumann" <cb@sgoc.de>,
	linux-crypto@vger.kernel.org, Shawn Guo <shawn.guo@linaro.org>,
	Fabio Estevam <festevam@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Tobias Rauter <tobiasrauter@gmail.com>
Subject: Re: [PATCH 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
Date: Tue, 8 Oct 2013 15:36:31 +1100	[thread overview]
Message-ID: <20131008043631.GA18365@gondor.apana.org.au> (raw)
In-Reply-To: <201310071748.27150.marex@denx.de>

On Mon, Oct 07, 2013 at 05:48:26PM +0200, Marek Vasut wrote:
> Hello Christoph,
> 
> > Hello Marek,
> > 
> > > Marek Vasut <marex@denx.de> hat am 28. September 2013 um 05:35 geschrieben:
> > > [...]
> > >
> > > > > 3) What are those ugly new IOCTLs in the dcp.c driver?
> > > > 
> > > > When I firstly posted the driver in the mailinglist, there where one
> > > > person who actually used this interface (it was introduced in
> > > > Freescale's SDK) to use the OTP keys for crypto. As far as I have
> > > > seen, the crypto API does not support such keys (i.e. there seems to
> > > > be no way to tell a driver to use some kind of special keys - which
> > > > are not delivered by the user - via the API).
> > > > Therefore I added this miscdevice and adopted Freescale's interface.
> > > 
> > > The keys are programmed into the OTP registers, correct? There is OCOTP d
> > >river 
> > >for the MX23/MX28 OTP hardware. This is what should have been used then. 
> > > NOTE: This IOCTL interface seems like quite an abusive way to allow userl
> > >and to 
> > >access the crypto API in kernel. I understand this is used by some Freesc
> > >ale tool, but won't it be better to fix the Freescale tool instead ?
> > 
> > the IOCTL interface is used to AES encrypt a bootstream with the AES key in
> > OCOTP.
> > The idea is that only the DCP can read/access the key once it has been
> > programmed
> > into the OCOTP. If the crypto API has means to tell the DCP to use the key
> > from OCOTP, the tool from Freescale is a minor problem.
> 
> Ah right. I suspect the crypto API services shall not be exported into userland 
> at all, yes ? So there has to be some kind of workaround here for this freescale 
> tool, which is rather unfortunate.

These ioctls have to go.  I should have never let them through in
the first place.  Can someone cook up a patch to kill them please?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

WARNING: multiple messages have this Message-ID (diff)
From: herbert@gondor.apana.org.au (Herbert Xu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
Date: Tue, 8 Oct 2013 15:36:31 +1100	[thread overview]
Message-ID: <20131008043631.GA18365@gondor.apana.org.au> (raw)
In-Reply-To: <201310071748.27150.marex@denx.de>

On Mon, Oct 07, 2013 at 05:48:26PM +0200, Marek Vasut wrote:
> Hello Christoph,
> 
> > Hello Marek,
> > 
> > > Marek Vasut <marex@denx.de> hat am 28. September 2013 um 05:35 geschrieben:
> > > [...]
> > >
> > > > > 3) What are those ugly new IOCTLs in the dcp.c driver?
> > > > 
> > > > When I firstly posted the driver in the mailinglist, there where one
> > > > person who actually used this interface (it was introduced in
> > > > Freescale's SDK) to use the OTP keys for crypto. As far as I have
> > > > seen, the crypto API does not support such keys (i.e. there seems to
> > > > be no way to tell a driver to use some kind of special keys - which
> > > > are not delivered by the user - via the API).
> > > > Therefore I added this miscdevice and adopted Freescale's interface.
> > > 
> > > The keys are programmed into the OTP registers, correct? There is OCOTP d
> > >river 
> > >for the MX23/MX28 OTP hardware. This is what should have been used then. 
> > > NOTE: This IOCTL interface seems like quite an abusive way to allow userl
> > >and to 
> > >access the crypto API in kernel. I understand this is used by some Freesc
> > >ale tool, but won't it be better to fix the Freescale tool instead ?
> > 
> > the IOCTL interface is used to AES encrypt a bootstream with the AES key in
> > OCOTP.
> > The idea is that only the DCP can read/access the key once it has been
> > programmed
> > into the OCOTP. If the crypto API has means to tell the DCP to use the key
> > from OCOTP, the tool from Freescale is a minor problem.
> 
> Ah right. I suspect the crypto API services shall not be exported into userland 
> at all, yes ? So there has to be some kind of workaround here for this freescale 
> tool, which is rather unfortunate.

These ioctls have to go.  I should have never let them through in
the first place.  Can someone cook up a patch to kill them please?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

  reply	other threads:[~2013-10-08  4:36 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-26 11:18 [PATCH 1/3] crypto: Fully restore ahash request before completing Marek Vasut
2013-09-26 11:18 ` Marek Vasut
2013-09-26 11:18 ` [PATCH 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver Marek Vasut
2013-09-26 11:18   ` Marek Vasut
2013-09-26 11:27   ` Fabio Estevam
2013-09-26 11:27     ` Fabio Estevam
2013-09-26 12:07     ` Marek Vasut
2013-09-26 12:07       ` Marek Vasut
2013-09-27 16:03       ` Tobias Rauter
2013-09-27 16:03         ` Tobias Rauter
2013-09-28  3:35         ` Marek Vasut
2013-09-28  3:35           ` Marek Vasut
2013-10-07  9:50           ` Christoph G. Baumann
2013-10-07  9:50             ` Christoph G. Baumann
2013-10-07 15:48             ` Marek Vasut
2013-10-07 15:48               ` Marek Vasut
2013-10-08  4:36               ` Herbert Xu [this message]
2013-10-08  4:36                 ` Herbert Xu
2013-10-08 10:33                 ` Marek Vasut
2013-10-08 10:33                   ` Marek Vasut
2013-11-10 17:48                   ` Marek Vasut
2013-11-10 17:48                     ` Marek Vasut
2013-11-20 11:20                     ` Herbert Xu
2013-11-20 11:20                       ` Herbert Xu
2013-12-01 22:20                       ` Marek Vasut
2013-12-01 22:20                         ` Marek Vasut
2013-09-26 12:13   ` Lothar Waßmann
2013-09-26 12:13     ` Lothar Waßmann
2013-09-26 14:04     ` Marek Vasut
2013-09-26 14:04       ` Marek Vasut
2013-09-26 14:09       ` Lothar Waßmann
2013-09-26 14:09         ` Lothar Waßmann
2013-09-29 22:05         ` Marek Vasut
2013-09-29 22:05           ` Marek Vasut
2013-09-26 12:37   ` Veli-Pekka Peltola
2013-09-26 12:37     ` Veli-Pekka Peltola
2013-09-26 14:02     ` Marek Vasut
2013-09-26 14:02       ` Marek Vasut
2013-09-26 12:48   ` Fabio Estevam
2013-09-26 12:48     ` Fabio Estevam
2013-09-29 22:09     ` Marek Vasut
2013-09-29 22:09       ` Marek Vasut
2013-09-26 11:18 ` [PATCH 3/3] ARM: mxs: dts: Enable DCP for MXS Marek Vasut
2013-09-26 11:18   ` Marek Vasut
2013-09-26 11:36   ` Lothar Waßmann
2013-09-26 11:36     ` Lothar Waßmann
2013-09-26 12:08     ` Marek Vasut
2013-09-26 12:08       ` Marek Vasut
2013-09-29 22:11     ` Marek Vasut
2013-09-29 22:11       ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131008043631.GA18365@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=cb@sgoc.de \
    --cc=davem@davemloft.net \
    --cc=festevam@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=shawn.guo@linaro.org \
    --cc=tobiasrauter@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.