From: kbuild test robot <lkp@intel.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: kbuild-all@01.org, linux-usb@vger.kernel.org,
gregkh@linuxfoundation.org, linux-crypto@vger.kernel.org,
ebiggers@kernel.org, herbert@gondor.apana.org.au,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH v2] wusb: switch to cbcmac transform
Date: Sat, 15 Jun 2019 05:30:12 +0800 [thread overview]
Message-ID: <201906150512.MgKyftlo%lkp@intel.com> (raw)
In-Reply-To: <20190614094353.23089-1-ard.biesheuvel@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 6376 bytes --]
Hi Ard,
I love your patch! Yet something to improve:
[auto build test ERROR on cryptodev/master]
[also build test ERROR on v5.2-rc4 next-20190614]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ard-Biesheuvel/wusb-switch-to-cbcmac-transform/20190615-042110
base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=xtensa
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/usb//wusbcore/crypto.c: In function 'wusb_ccm_mac':
>> drivers/usb//wusbcore/crypto.c:230:2: error: implicit declaration of function 'crypto_xor_cpy'; did you mean 'crypto_comp_crt'? [-Werror=implicit-function-declaration]
crypto_xor_cpy(mic, (u8 *)&scratch->ax, iv, 8);
^~~~~~~~~~~~~~
crypto_comp_crt
cc1: some warnings being treated as errors
vim +230 drivers/usb//wusbcore/crypto.c
120
121 /*
122 * CC-MAC function WUSB1.0[6.5]
123 *
124 * Take a data string and produce the encrypted CBC Counter-mode MIC
125 *
126 * Note the names for most function arguments are made to (more or
127 * less) match those used in the pseudo-function definition given in
128 * WUSB1.0[6.5].
129 *
130 * @tfm_cbc: CBC(AES) blkcipher handle (initialized)
131 *
132 * @tfm_aes: AES cipher handle (initialized)
133 *
134 * @mic: buffer for placing the computed MIC (Message Integrity
135 * Code). This is exactly 8 bytes, and we expect the buffer to
136 * be at least eight bytes in length.
137 *
138 * @key: 128 bit symmetric key
139 *
140 * @n: CCM nonce
141 *
142 * @a: ASCII string, 14 bytes long (I guess zero padded if needed;
143 * we use exactly 14 bytes).
144 *
145 * @b: data stream to be processed
146 *
147 * @blen: size of b...
148 *
149 * Still not very clear how this is done, but looks like this: we
150 * create block B0 (as WUSB1.0[6.5] says), then we AES-crypt it with
151 * @key. We bytewise xor B0 with B1 (1) and AES-crypt that. Then we
152 * take the payload and divide it in blocks (16 bytes), xor them with
153 * the previous crypto result (16 bytes) and crypt it, repeat the next
154 * block with the output of the previous one, rinse wash. So we use
155 * the CBC-MAC(AES) shash, that does precisely that. The IV (Initial
156 * Vector) is 16 bytes and is set to zero, so
157 *
158 * (1) Created as 6.5 says, again, using as l(a) 'Blen + 14', and
159 * using the 14 bytes of @a to fill up
160 * b1.{mac_header,e0,security_reserved,padding}.
161 *
162 * NOTE: The definition of l(a) in WUSB1.0[6.5] vs the definition of
163 * l(m) is orthogonal, they bear no relationship, so it is not
164 * in conflict with the parameter's relation that
165 * WUSB1.0[6.4.2]) defines.
166 *
167 * NOTE: WUSB1.0[A.1]: Host Nonce is missing a nibble? (1e); fixed in
168 * first errata released on 2005/07.
169 *
170 * NOTE: we need to clean IV to zero at each invocation to make sure
171 * we start with a fresh empty Initial Vector, so that the CBC
172 * works ok.
173 *
174 * NOTE: blen is not aligned to a block size, we'll pad zeros, that's
175 * what sg[4] is for. Maybe there is a smarter way to do this.
176 */
177 static int wusb_ccm_mac(struct crypto_shash *tfm_cbcmac,
178 struct wusb_mac_scratch *scratch,
179 void *mic,
180 const struct aes_ccm_nonce *n,
181 const struct aes_ccm_label *a, const void *b,
182 size_t blen)
183 {
184 SHASH_DESC_ON_STACK(desc, tfm_cbcmac);
185 u8 iv[AES_BLOCK_SIZE];
186
187 /*
188 * These checks should be compile time optimized out
189 * ensure @a fills b1's mac_header and following fields
190 */
191 BUILD_BUG_ON(sizeof(*a) != sizeof(scratch->b1) - sizeof(scratch->b1.la));
192 BUILD_BUG_ON(sizeof(scratch->b0) != sizeof(struct aes_ccm_block));
193 BUILD_BUG_ON(sizeof(scratch->b1) != sizeof(struct aes_ccm_block));
194 BUILD_BUG_ON(sizeof(scratch->ax) != sizeof(struct aes_ccm_block));
195
196 /* Setup B0 */
197 scratch->b0.flags = 0x59; /* Format B0 */
198 scratch->b0.ccm_nonce = *n;
199 scratch->b0.lm = cpu_to_be16(0); /* WUSB1.0[6.5] sez l(m) is 0 */
200
201 /* Setup B1
202 *
203 * The WUSB spec is anything but clear! WUSB1.0[6.5]
204 * says that to initialize B1 from A with 'l(a) = blen +
205 * 14'--after clarification, it means to use A's contents
206 * for MAC Header, EO, sec reserved and padding.
207 */
208 scratch->b1.la = cpu_to_be16(blen + 14);
209 memcpy(&scratch->b1.mac_header, a, sizeof(*a));
210
211 desc->tfm = tfm_cbcmac;
212 crypto_shash_init(desc);
213 crypto_shash_update(desc, (u8 *)&scratch->b0, sizeof(scratch->b0) +
214 sizeof(scratch->b1));
215 crypto_shash_finup(desc, b, blen, iv);
216
217 /* Now we crypt the MIC Tag (*iv) with Ax -- values per WUSB1.0[6.5]
218 * The procedure is to AES crypt the A0 block and XOR the MIC
219 * Tag against it; we only do the first 8 bytes and place it
220 * directly in the destination buffer.
221 */
222 scratch->ax.flags = 0x01; /* as per WUSB 1.0 spec */
223 scratch->ax.ccm_nonce = *n;
224 scratch->ax.counter = 0;
225
226 /* reuse the CBC-MAC transform to perform the single block encryption */
227 crypto_shash_digest(desc, (u8 *)&scratch->ax, sizeof(scratch->ax),
228 (u8 *)&scratch->ax);
229
> 230 crypto_xor_cpy(mic, (u8 *)&scratch->ax, iv, 8);
231
232 return 8;
233 }
234
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 58635 bytes --]
prev parent reply other threads:[~2019-06-14 21:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-14 9:43 [PATCH v2] wusb: switch to cbcmac transform Ard Biesheuvel
2019-06-14 10:05 ` Greg KH
2019-06-14 10:07 ` Ard Biesheuvel
2019-06-14 21:30 ` kbuild test robot [this message]
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=201906150512.MgKyftlo%lkp@intel.com \
--to=lkp@intel.com \
--cc=ard.biesheuvel@linaro.org \
--cc=ebiggers@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=kbuild-all@01.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-usb@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox