On Fri, 2018-07-20 at 11:53 +0800, Herbert Xu wrote:
> On Fri, May 11, 2018 at 06:44:13PM -0700, Megha Dey wrote:
> >
> > +static struct ahash_alg *simd_ahash_create_compat(const char *algname,
> > + const char *drvname,
> > +
On 07/26/2018 09:37 AM, Tom Lendacky wrote:
Should the PSP initialization fail, the PSP data structure will be
freed and the value contained in the sp_device struct set to NULL.
At module unload, psp_dev_destroy() does not check if the pointer
value is NULL and will end up dereferencing a NULL po
Should the PSP initialization fail, the PSP data structure will be
freed and the value contained in the sp_device struct set to NULL.
At module unload, psp_dev_destroy() does not check if the pointer
value is NULL and will end up dereferencing a NULL pointer.
Add a pointer check of the psp_data fi
On 2018-07-26 09:25:40 [+0200], Ard Biesheuvel wrote:
> Thanks a lot.
>
> So 20 us ~= 20,000 cycles on my 1 GHz Cortex-A53, and if I am
> understanding you correctly, you wouldn't mind the quantum of work to
> be in the order 16,000 cycles or even substantially more?
I have currently that one box
On Thu, Jul 26, 2018 at 09:30:46AM +0200, Oliver Neukum wrote:
> On Di, 2018-07-24 at 00:23 +0800, Yu Chen wrote:
> >
> > Good point, we once tried to generate key in kernel, but people
> > suggest to generate key in userspace and provide it to the
> > kernel, which is what ecryptfs do currently,
On Di, 2018-07-24 at 00:23 +0800, Yu Chen wrote:
>
> Good point, we once tried to generate key in kernel, but people
> suggest to generate key in userspace and provide it to the
> kernel, which is what ecryptfs do currently, so it seems this
> should also be safe for encryption in kernel.
> https:
On 25 July 2018 at 18:50, bige...@linutronix.de wrote:
> On 2018-07-25 11:54:53 [+0200], Ard Biesheuvel wrote:
>> Indeed. OTOH, if the -rt people (Sebastian?) turn up and say that a
>> 1000 cycle limit to the quantum of work performed with preemption
>> disabled is unreasonably low, we can increas
