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 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.