All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <andersson@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Abel Vesa <abel.vesa@linaro.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Andy Gross <agross@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Manivannan Sadhasivam <mani@kernel.org>,
	Alim Akhtar <alim.akhtar@samsung.com>,
	Avri Altman <avri.altman@wdc.com>,
	Bart Van Assche <bvanassche@acm.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"James E . J . Bottomley" <jejb@linux.ibm.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S . Miller" <davem@davemloft.net>,
	linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH v4 4/7] soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver
Date: Mon, 27 Mar 2023 12:27:04 -0700	[thread overview]
Message-ID: <20230327192704.ywczpr2otbwxnsh5@ripper> (raw)
In-Reply-To: <20230327190954.GE73752@sol.localdomain>

On Mon, Mar 27, 2023 at 12:09:54PM -0700, Eric Biggers wrote:
> On Mon, Mar 27, 2023 at 11:53:58AM -0700, Bjorn Andersson wrote:
> > > +int qcom_ice_program_key(struct qcom_ice *ice,
> > > +			 u8 algorithm_id, u8 key_size,
> > > +			 const u8 crypto_key[], u8 data_unit_size,
> > > +			 int slot)
> > > +{
> > > +	struct device *dev = ice->dev;
> > > +	union {
> > > +		u8 bytes[AES_256_XTS_KEY_SIZE];
> > > +		u32 words[AES_256_XTS_KEY_SIZE / sizeof(u32)];
> > > +	} key;
> > > +	int i;
> > > +	int err;
> > > +
> > > +	/* Only AES-256-XTS has been tested so far. */
> > > +	if (algorithm_id != QCOM_ICE_CRYPTO_ALG_AES_XTS ||
> > > +	    key_size != QCOM_ICE_CRYPTO_KEY_SIZE_256) {
> > > +		dev_err_ratelimited(dev,
> > > +				    "Unhandled crypto capability; algorithm_id=%d, key_size=%d\n",
> > > +				    algorithm_id, key_size);
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	memcpy(key.bytes, crypto_key, AES_256_XTS_KEY_SIZE);
> > > +
> > > +	/*
> > > +	 * The SCM call byte-swaps the 32-bit words of the key.
> > > +	 * So we have to do the same, in order for the final key be correct.
> > 
> > Does it actually byte swap the words, or is the API just specified to
> > take the words in big endian format?
> 
> [Note, this is existing code I wrote that Abel is just moving to a new file.]
> 

Ah right, then I'm inclined to keep it untouched.

> It doesn't write to the input array, if that is what you are asking.  I was
> thinking of this as one byte swap cancelling out another.  But sure, the comment
> could be simplified to something like the following:
> 
> 	/* The SCM call requires that the key words be byte-swapped. */
> 

Last time I looked at a crypto driver, it was full of "switch the
endian" operations, back and forth. So my request here was simply to
make it clear which endian is actually expected.
So I'm guessing the appropriate comment is:

	/* The SCM call requires that the key words are encoded in big endian */

> > How come you memcpy + swap in place, instead of loop over the words and
> > cpu_to_be32() them into a __be words[] array?
> > 
> > > +	 */
> > > +	for (i = 0; i < ARRAY_SIZE(key.words); i++)
> > > +		__cpu_to_be32s(&key.words[i]);
> 
> With this approach there is no need to worry about unaligned memory accesses.

That's a valid reason that I was looking for. Wouldn't this be a common
problem, something other parts of the stack would like to avoid?
Or it's just a byte array until we get here?

> It could be done with unaligned memory accesses, though, if you prefer that:
> 

No need to jump through the hoops, but a comment would have saved
(robbed?) me from wondering.

Regards,
Bjorn

> 	union {
> 		[...]
> 		__be32 words[...];
> 	} key;
> 
> 	[...]
> 		key.words[i] = cpu_to_be32(get_unaligned((__u32 *)crypto_key + i));
> 
> - Eric

  reply	other threads:[~2023-03-27 19:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 13:47 [PATCH v4 0/7] Add dedicated Qcom ICE driver Abel Vesa
2023-03-27 13:47 ` [PATCH v4 1/7] dt-bindings: crypto: Add Qualcomm Inline Crypto Engine Abel Vesa
2023-03-27 17:50   ` Eric Biggers
2023-03-27 13:47 ` [PATCH v4 2/7] dt-bindings: mmc: sdhci-msm: Add ICE phandle Abel Vesa
2023-03-27 14:44   ` Krzysztof Kozlowski
2023-03-27 17:52   ` Eric Biggers
2023-03-27 13:47 ` [PATCH v4 3/7] dt-bindings: ufs: qcom: " Abel Vesa
2023-03-27 14:45   ` Krzysztof Kozlowski
2023-03-27 13:47 ` [PATCH v4 4/7] soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver Abel Vesa
2023-03-27 18:01   ` Eric Biggers
2023-03-27 18:53   ` Bjorn Andersson
2023-03-27 19:09     ` Eric Biggers
2023-03-27 19:27       ` Bjorn Andersson [this message]
2023-03-27 20:12         ` Eric Biggers
2023-03-27 13:47 ` [PATCH v4 5/7] scsi: ufs: ufs-qcom: Switch to the new ICE API Abel Vesa
2023-03-27 18:19   ` Eric Biggers
2023-03-31  5:13     ` Abel Vesa
2023-03-27 13:47 ` [PATCH v4 6/7] mmc: sdhci-msm: " Abel Vesa
2023-03-27 18:32   ` Eric Biggers
2023-03-31  5:04     ` Abel Vesa
2023-03-27 21:58   ` kernel test robot
2023-03-27 13:47 ` [PATCH v4 7/7] arm64: dts: qcom: sm8550: Add the Inline Crypto Engine node Abel Vesa

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=20230327192704.ywczpr2otbwxnsh5@ripper \
    --to=andersson@kernel.org \
    --cc=abel.vesa@linaro.org \
    --cc=adrian.hunter@intel.com \
    --cc=agross@kernel.org \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=bvanassche@acm.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jejb@linux.ibm.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=robh+dt@kernel.org \
    --cc=ulf.hansson@linaro.org \
    /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.