TRADING ACCOUNT
Dear sir , I KELLY ALAN purchasing and sales manager of CFM INTERNATIONAL .Our Company specialised in Supplying computer hardware and Electronic .We want to extend our supplier list because of concurrency in prices on the international market. We are seeking a supplier with whom we can to have partnered long-term in order to have competitive prices . we are interested to buy the products you sell and want to place an order with you in big quantities. Can you give us payment facilities ( 14 , 30 or 60 days payment terms ) ? What is the procedure for our account opening and credit line application ? Cordially KELLY ALAN CFM INTERNATIONAL 2 BOULEVARD DU GAL MARTIAL VALIN 75015 PARIS REG N° 302 527 700 VAT N° FR90 302527700 TEL +33171025367 FAX +33177759149 https://www.cfmaeroengines.com
Re: [PATCH] crypto: arm64/aes-gcm-ce - fix scatterwalk API violation
On Mon, Aug 20, 2018 at 04:58:34PM +0200, Ard Biesheuvel wrote: > Commit 71e52c278c54 ("crypto: arm64/aes-ce-gcm - operate on > two input blocks at a time") modified the granularity at which > the AES/GCM code processes its input to allow subsequent changes > to be applied that improve performance by using aggregation to > process multiple input blocks at once. > > For this reason, it doubled the algorithm's 'chunksize' property > to 2 x AES_BLOCK_SIZE, but retained the non-SIMD fallback path that > processes a single block at a time. In some cases, this violates the > skcipher scatterwalk API, by calling skcipher_walk_done() with a > non-zero residue value for a chunk that is expected to be handled > in its entirety. This results in a WARN_ON() to be hit by the TLS > self test code, but is likely to break other user cases as well. > Unfortunately, none of the current test cases exercises this exact > code path at the moment. > > Fixes: 71e52c278c54 ("crypto: arm64/aes-ce-gcm - operate on two ...") > Reported-by: Vakul Garg > Signed-off-by: Ard Biesheuvel Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm64/sm4-ce - check for the right CPU feature bit
On Tue, Aug 07, 2018 at 11:18:36PM +0200, Ard Biesheuvel wrote: > ARMv8.2 specifies special instructions for the SM3 cryptographic hash > and the SM4 symmetric cipher. While it is unlikely that a core would > implement one and not the other, we should only use SM4 instructions > if the SM4 CPU feature bit is set, and we currently check the SM3 > feature bit instead. So fix that. > > Signed-off-by: Ard Biesheuvel Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: caam/qi - fix error path in xts setkey
On Mon, Aug 06, 2018 at 03:29:39PM +0300, Horia Geantă wrote: > xts setkey callback returns 0 on some error paths. > Fix this by returning -EINVAL. > > Cc: # 4.12+ > Fixes: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc > algorithms") > Signed-off-by: Horia Geantă Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: caam - fix DMA mapping direction for RSA forms 2 & 3
On Mon, Aug 06, 2018 at 03:29:55PM +0300, Horia Geantă wrote: > Crypto engine needs some temporary locations in external memory for > running RSA decrypt forms 2 and 3 (CRT). > These are named "tmp1" and "tmp2" in the PDB. > > Update DMA mapping direction of tmp1 and tmp2 from TO_DEVICE to > BIDIRECTIONAL, since engine needs r/w access. > > Cc: # 4.13+ > Fixes: 52e26d77b8b3 ("crypto: caam - add support for RSA key form 2") > Fixes: 4a651b122adb ("crypto: caam - add support for RSA key form 3") > Signed-off-by: Horia Geantă Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: caam/jr - fix descriptor DMA unmapping
On Mon, Aug 06, 2018 at 03:29:09PM +0300, Horia Geantă wrote: > Descriptor address needs to be swapped to CPU endianness before being > DMA unmapped. > > Cc: # 4.8+ > Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam > endianness") > Reported-by: Laurentiu Tudor > Signed-off-by: Horia Geantă Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] chtls_cm.c: fix missing return value check of alloc_skb()
Jiecheng Wu wrote: > Function chtls_close_conn() defined in > drivers/crypto/chelsio/chtls/chtls_cm.c calls alloc_skb() to allocate memory > for struct sk_buff which is dereferenced immediately. As alloc_skb() may > return NULL on failure, this code piece may cause NULL pointer dereference > bug. Please add a sign-off. You can refer to Documentation/process/submitting-patches.rst Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RESEND PATCH 2/2] crypto: caam - Support deferred probing in JR dependent drivers
On Tue, Aug 07, 2018 at 12:34:57PM +, Horia Geanta wrote: > On 8/7/2018 11:00 AM, Marcin Niestroj wrote: > > It is possible, that caam_jr_alloc() is called before JR devices are > > probed. Return -EPROBE_DEFER in drivers that rely on JR devices, so > > they are probed at later stage. > > > These drivers don't have a probe() callback. > Returning -EPROBE_DEFER in module's init() (caamrng) or crypto algorithm's > init() (caamalg etc.) callbacks is not going to help, they won't be called > later. > > Does adding request_module("caam_jr") in module's init() solve the issue? If everything is built as a module this should always work because a module isn't available until after its init function has finished. So the only problem here appears to be when everything is built-in in which case the init functions are run in random order. So perhaps move caam_jr's module_init function to an earlier level (i.e., earlier than device_initcall)? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt