Hey Ard,
On Tue, Sep 25, 2018 at 12:25 PM Ard Biesheuvel
wrote:
> Kees is currently dealing with VLA uses in crypto API skcipher
> invocations [0] that don't benefit from its async capabilities nor
> from the runtime resolution of cipher name strings, given that they
> always select the same one.
Hey Arnd,
On Tue, Sep 25, 2018 at 9:18 AM Arnd Bergmann wrote:
> I think I misread your earlier sentence and thought you had said the
> exact opposite.
>
> For confirmation, I've downloaded your git tree and built it with my
> collection of compilers (gcc-4.6 through 8.1) and tried building it
>
Hi Jason,
I have another couple of questions which are unrelated to the below,
so I will just respond again to the top message.
On Tue, 18 Sep 2018 at 18:18, Jason A. Donenfeld wrote:
>
> Zinc stands for "Zinc Is Neat Crypto" or "Zinc as IN Crypto" or maybe
> just "Zx2c4's INsane Cryptolib." It'
On Sat, Sep 22, 2018 at 6:11 PM Arnd Bergmann wrote:
>
> On Thu, Sep 20, 2018 at 5:12 PM Jason A. Donenfeld wrote:
> >
> > Hey Arnd,
> >
> > On Thu, Sep 20, 2018 at 6:02 PM Arnd Bergmann wrote:
> > > Right, if you hit a stack requirement like this, it's usually the compiler
> > > doing something
On Thu, Sep 20, 2018 at 5:12 PM Jason A. Donenfeld wrote:
>
> Hey Arnd,
>
> On Thu, Sep 20, 2018 at 6:02 PM Arnd Bergmann wrote:
> > Right, if you hit a stack requirement like this, it's usually the compiler
> > doing something bad, not just using too much stack but also generating
> > rather slo
> On Sep 20, 2018, at 9:30 PM, Ard Biesheuvel wrote:
>
>> On 20 September 2018 at 21:15, Jason A. Donenfeld wrote:
>> Hi Andy,
>>
>>> On Fri, Sep 21, 2018 at 5:23 AM Andy Lutomirski wrote:
>>> At the risk on suggesting something awful: on x86_64, since we turn
>>> preemption off for simd,
Hi Ard,
On Fri, Sep 21, 2018 at 6:30 AM Ard Biesheuvel
wrote:
> Did any of the fuzzing/testing you mention in the cover letter occur
> on the kernel versions of these algorithms?
Yes, of course.
Jason
On 20 September 2018 at 21:15, Jason A. Donenfeld wrote:
> Hi Andy,
>
> On Fri, Sep 21, 2018 at 5:23 AM Andy Lutomirski wrote:
>> At the risk on suggesting something awful: on x86_64, since we turn
>> preemption off for simd, it wouldn’t be *completely* insane to do the crypto
>> on the irq sta
Hi Andy,
On Fri, Sep 21, 2018 at 5:23 AM Andy Lutomirski wrote:
> At the risk on suggesting something awful: on x86_64, since we turn
> preemption off for simd, it wouldn’t be *completely* insane to do the crypto
> on the irq stack. It would look like:
>
> kernel_fpu_call(func, arg);
>
> And th
> On Sep 20, 2018, at 8:12 PM, Andrew Lunn wrote:
>
>> On Fri, Sep 21, 2018 at 02:11:43AM +0200, Jason A. Donenfeld wrote:
>> Hey Arnd,
>>
>>> On Thu, Sep 20, 2018 at 6:02 PM Arnd Bergmann wrote:
>>> Right, if you hit a stack requirement like this, it's usually the compiler
>>> doing somethin
Hi Andrew,
On Fri, Sep 21, 2018 at 5:13 AM Andrew Lunn wrote:
> Do you any stack usage information?
>
> A VPN can be at the bottom of some deep stack calls. Swap on NFS over
> the VPN? If you have one frame of 1K, you might be O.K. But if you
> have a few of these, i can see there might be issues
On Fri, Sep 21, 2018 at 02:11:43AM +0200, Jason A. Donenfeld wrote:
> Hey Arnd,
>
> On Thu, Sep 20, 2018 at 6:02 PM Arnd Bergmann wrote:
> > Right, if you hit a stack requirement like this, it's usually the compiler
> > doing something bad, not just using too much stack but also generating
> > ra
Hi Ard,
On Thu, Sep 20, 2018 at 5:42 PM Ard Biesheuvel
wrote:
> Apologies for not spotting these before:
>
> > +ccflags-y := -O3
>
> -O3 optimization has been problematic in the past, at least on x86 but
> I think on other architectures as well. Please stick with -O2.
Fixed up for v6.
>
> > +cc
Hey Arnd,
On Thu, Sep 20, 2018 at 6:02 PM Arnd Bergmann wrote:
> Right, if you hit a stack requirement like this, it's usually the compiler
> doing something bad, not just using too much stack but also generating
> rather slow object code in the process. It's better to fix the bug by
> optimizing
On Thu, Sep 20, 2018 at 8:41 AM Ard Biesheuvel
wrote:
>
> (+ Arnd, Eric)
>
> On 18 September 2018 at 09:16, Jason A. Donenfeld wrote:
> ...
>
> > diff --git a/lib/zinc/Makefile b/lib/zinc/Makefile
> > new file mode 100644
> > index ..83dfd63988c0
> > --- /dev/null
> > +++ b/lib/zinc/M
> On Sep 20, 2018, at 8:41 AM, Ard Biesheuvel wrote:
>
> (+ Arnd, Eric)
>
> On 18 September 2018 at 09:16, Jason A. Donenfeld wrote:
> ...
>
>> diff --git a/lib/zinc/Makefile b/lib/zinc/Makefile
>> new file mode 100644
>> index ..83dfd63988c0
>> --- /dev/null
>> +++ b/lib/zinc/M
(+ Arnd, Eric)
On 18 September 2018 at 09:16, Jason A. Donenfeld wrote:
...
> diff --git a/lib/zinc/Makefile b/lib/zinc/Makefile
> new file mode 100644
> index ..83dfd63988c0
> --- /dev/null
> +++ b/lib/zinc/Makefile
> @@ -0,0 +1,4 @@
Apologies for not spotting these before:
> +ccf
Zinc stands for "Zinc Is Neat Crypto" or "Zinc as IN Crypto" or maybe
just "Zx2c4's INsane Cryptolib." It's also short, easy to type, and
plays nicely with the recent trend of naming crypto libraries after
elements. The guiding principle is "don't overdo it". It's less of a
library and more of a di
18 matches
Mail list logo
