All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

      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.