Hi guys,
Let me know what you think about this patch. Short of the TLS dst_len rounding
fix, it should be just a refactoring.
Replacing CIOCAUTHCRYPT with another ioctl that takes dst_len is not such a
good idea in practice. The transition needs a lot of code duplication that has
to be tested
Hi Phil,
> This means we write more data into the userspace-supplied buffer than
> requested without noticing it. Although this might be correct in regards
> of the cipher mode's requirements, we could corrupt userspace memory by
> doing so. Correctly calculating the needed bufferspace for the req
Hi Joel,
Can you identify the cipher used during file transfer? If the web server is
under your control you can try restricting the cipher list.
What does "openssl s_client -connect :" report for the session?
> I tried disabling hash by removing -DUSE_CRYPTODEV_DIGESTS from
> Makefile, however c
Hi Phil,
> Nope, that's exactly it. But in this case probably a mistake happened
> when submitting your v2, as it contains the above change.
[]
The v2 patch does not touch the pcr part anymore
(https://github.com/cryptodev-linux/cryptodev-linux/blob/master/ioctl.c#L447)
Does the patch apply or is
Hi Phil,
> > for (i = 0; i < DEF_COP_RINGSIZE; i++) {
> > tmp = kzalloc(sizeof(struct todo_list_item), GFP_KERNEL);
> > if (!tmp)
> > - return -ENOMEM;
> > + goto err_ringalloc;
>
> This would mean that in case pcr allocation fails,
Hi Phil,
> Why should that be necessary?
The patch is concerned with 'close' being called with garbage input.
I'm not sure about the call chain here: is 'close' never called when 'open'
fails? What is the assumption of the caller?
> I just did a quick test, simply assigning
> NULL to pcr instead
Hi Phil,
You may want to have a look at this patch since it addresses an incomplete fix
of mine.
Thanks,
Cristian S.
> -Original Message-
> From: Horia Geanta [mailto:horia.gea...@freescale.com]
> Sent: Thursday, December 12, 2013 6:10 PM
> To: Nikos Mavrogiannopoulos
> Cc: cryptodev-li
Hi Phil,
> Wouldn't it be better to conditionally define INIT_COMPLETION to
> reinit_completion for newer kernels? Doesn't this break downwards
> compatibility?
>
> I could think of something like:
>
> #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 12, 0))
> # define INIT_COMPLETION(x) reinit_com
Hi Nikos,
I can confirm that this issue is fixed in kernel in 77dbd7a95.
The issue and the patch were discussed in
http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg09416.html
Thanks to Horia for mentioning the patch.
Cristian S.
> > Just for reference, I've found a possible workarou
