On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu wrote:
> On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote:
>>
>> That said, I do think that the "don't assume stack alignment, do it by
>> hand" may be the safer thing. Because who knows what the random rules
>> will be on other architectur
On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote:
>
> That said, I do think that the "don't assume stack alignment, do it by
> hand" may be the safer thing. Because who knows what the random rules
> will be on other architectures.
Sure we can ban the use of attribute aligned on stack
On Tue, Jan 10, 2017 at 7:30 PM, Linus Torvalds
wrote:
>
> If you really want more stack alignment, you have to generate that
> alignment yourself by hand (and have a bigger buffer that you do that
> alignment inside).
Side note: gcc can (and does) actually generate forced alignment using
"and" i
On Tue, Jan 10, 2017 at 7:11 PM, Herbert Xu wrote:
>
> Well the only other alternative I see is to ban compilers which
> enforce 16-byte stack alignment, such as gcc 4.7.2.
No, you don't have to ban the compiler - it's just a "generate overly
stupid code that just uses extra instructions to like
On Tue, Jan 10, 2017 at 11:22:15AM -0800, Andy Lutomirski wrote:
>
> > Actually, the breakage is introduced by the patch Herbert refers to
> >
> > https://patchwork.kernel.org/patch/9468391/
> >
> > where the state is replaced by a simple
> >
> > u32 state[16] __aligned(CHACHA20_STATE_ALIGN);
> >
>
On Tue, Jan 10, 2017 at 03:25:47PM -0800, Andy Lutomirski wrote:
>
> > If it does what it says on the tin, it should fix the issue, but after
> > adding the attribute, I get the exact same object output, so there's
> > something dodgy going on here.
>
> Ugh, that's annoying. Maybe it needs noinli
On Tue, Jan 10, 2017 at 11:00:31AM -0800, Andy Lutomirski wrote:
>
> Here's what I think is really going on. This is partially from
> memory, so I could be off base. The kernel is up against
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383, which means that,
> on some GCC versions (like the
On Tue, Jan 10, 2017 at 05:30:48PM +, Ard Biesheuvel wrote:
>
> Apologies for introducing this breakage. It seemed like an obvious and
> simple cleanup, so I didn't even bother to mention it in the commit
> log, but if the kernel does not guarantee 16 byte alignment, I guess
> we should revert
On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote:
> On Tue, Jan 10, 2017 at 6:39 AM, Herbert Xu
> wrote:
> >
> > BTW this is with Debian gcc 4.7.2 which does not allow an 8-byte
> > stack alignment as attempted by the Makefile:
>
> I'm pretty sure we have random asm code that may n
On Tue, Jan 10, 2017 at 4:50 PM, Daniel Borkmann wrote:
> On 01/11/2017 12:24 AM, Andy Lutomirski wrote:
>>
>> This makes it easier to add another digest algorithm down the road if
>> needed. It also serves to force any programs that might have been
>> written against a kernel that had the old fi
On Tue, Jan 10, 2017 at 03:24:38PM -0800, Andy Lutomirski wrote:
> I can imagine future uses for the new-in-4.10 BPF digest feature that
> would be problematic if malicious users could produce collisions, and
> SHA-1 is no longer consdiered to be collision-free. Even without
> needing collision re
On 01/11/2017 12:24 AM, Andy Lutomirski wrote:
This makes it easier to add another digest algorithm down the road if
needed. It also serves to force any programs that might have been
written against a kernel that had the old field name to notice the
change and make any necessary changes.
This s
This makes it easier to add another digest algorithm down the road if
needed. It also serves to force any programs that might have been
written against a kernel that had the old field name to notice the
change and make any necessary changes.
This shouldn't violate any stable API policies, as no r
SHA1 is considered obsolete. It is no longer considered to be
collision resistant and, in general, it should not be used for new
applications. Change the new-in-4.10 BPF digest to SHA-256. This
means that potential future applications of the digest that need
collision resistance will be able to
This makes it easier to add another digest algorithm down the road
if needed. It also serves to force any programs that might have
been written against a kernel that had 'prog_digest' to be updated.
This shouldn't violate any stable API policies, as no released
kernel has ever had 'prog_digest'.
On Tue, Jan 10, 2017 at 12:00 PM, Ard Biesheuvel
wrote:
> On 10 January 2017 at 19:22, Andy Lutomirski wrote:
>> On Tue, Jan 10, 2017 at 11:16 AM, Ard Biesheuvel
>> wrote:
>>> On 10 January 2017 at 19:00, Andy Lutomirski wrote:
On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel
wrote:
>
The sha256 helpers can consume a message incrementally, so there's no need
to allocate a buffer to store the whole blob to be hashed.
This may be a slight slowdown for very long messages because gcc can't
inline the sha256_update() calls. For reasonably-sized programs,
however, this should be a c
This just moves code around -- no code changes in this patch. This
wil let BPF-based tracing link against the SHA256 core code without
depending on the crypto core.
Cc: Ard Biesheuvel
Cc: Herbert Xu
Signed-off-by: Andy Lutomirski
---
crypto/Kconfig | 8 ++
crypto/Makefile |
There are some hashes (e.g. sha224) that have some internal trickery
to make sure that only the correct number of output bytes are
generated. If something goes wrong, they could potentially overrun
the output buffer.
Make the test more robust by allocating only enough space for the
correct output
This provides a very simple interface for kernel code to use to do
synchronous, unaccelerated, virtual-address-based SHA256 hashing
without needing to create a crypto context.
Subsequent patches will make this work without building the crypto
core and will use to avoid making BPF-based tracing dep
I can imagine future uses for the new-in-4.10 BPF digest feature that
would be problematic if malicious users could produce collisions, and
SHA-1 is no longer consdiered to be collision-free. Even without
needing collision resistance, SHA-1 is no longer recommended for new
applications. Switch th
I want to expose a minimal SHA256 API that can be used without the
depending on the crypto core. To prepare for this, factor out the
meat of the sha256_base_*() helpers.
Cc: Ard Biesheuvel
Cc: Herbert Xu
Signed-off-by: Andy Lutomirski
---
include/crypto/sha256_base.h | 53
On 10 January 2017 at 19:22, Andy Lutomirski wrote:
> On Tue, Jan 10, 2017 at 11:16 AM, Ard Biesheuvel
> wrote:
>> On 10 January 2017 at 19:00, Andy Lutomirski wrote:
>>> On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel
>>> wrote:
On 10 January 2017 at 14:33, Herbert Xu
wrote:
>
On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel
wrote:
> On 10 January 2017 at 14:33, Herbert Xu wrote:
>> I recently applied the patch
>>
>> https://patchwork.kernel.org/patch/9468391/
>>
>> and ended up with a boot crash when it tried to run the x86 chacha20
>> code. It turned out that
On Tue, Jan 10, 2017 at 11:16 AM, Ard Biesheuvel
wrote:
> On 10 January 2017 at 19:00, Andy Lutomirski wrote:
>> On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel
>> wrote:
>>> On 10 January 2017 at 14:33, Herbert Xu wrote:
I recently applied the patch
https://patchwork.ker
On 10 January 2017 at 19:00, Andy Lutomirski wrote:
> On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel
> wrote:
>> On 10 January 2017 at 14:33, Herbert Xu wrote:
>>> I recently applied the patch
>>>
>>> https://patchwork.kernel.org/patch/9468391/
>>>
>>> and ended up with a boot crash whe
On 10 January 2017 at 14:33, Herbert Xu wrote:
> I recently applied the patch
>
> https://patchwork.kernel.org/patch/9468391/
>
> and ended up with a boot crash when it tried to run the x86 chacha20
> code. It turned out that the patch changed a manually aligned
> stack buffer to one that
On Tue, Jan 10, 2017 at 9:05 AM, Linus Torvalds
wrote:
> On Tue, Jan 10, 2017 at 6:39 AM, Herbert Xu
> wrote:
>>
>> BTW this is with Debian gcc 4.7.2 which does not allow an 8-byte
>> stack alignment as attempted by the Makefile:
>
> I'm pretty sure we have random asm code that may not maintain
On Tue, Jan 10, 2017 at 6:39 AM, Herbert Xu wrote:
>
> BTW this is with Debian gcc 4.7.2 which does not allow an 8-byte
> stack alignment as attempted by the Makefile:
I'm pretty sure we have random asm code that may not maintain a
16-byte stack alignment when it calls other code (including, in s
On Tue, Jan 10, 2017 at 10:33:40PM +0800, Herbert Xu wrote:
> I recently applied the patch
>
> https://patchwork.kernel.org/patch/9468391/
>
> and ended up with a boot crash when it tried to run the x86 chacha20
> code. It turned out that the patch changed a manually aligned
> stack buffer
I recently applied the patch
https://patchwork.kernel.org/patch/9468391/
and ended up with a boot crash when it tried to run the x86 chacha20
code. It turned out that the patch changed a manually aligned
stack buffer to one that is aligned by gcc. What was happening was
that gcc can sta
On 01/10/2017 01:36 PM, Gonglei (Arei) wrote:
> Hi,
>
>>
>> On 12/15/2016 03:03 AM, Gonglei wrote:
>> [...]
>>> +
>>> +static struct crypto_alg virtio_crypto_algs[] = { {
>>> + .cra_name = "cbc(aes)",
>>> + .cra_driver_name = "virtio_crypto_aes_cbc",
>>> + .cra_priority = 501,
>>
>>
>> This
Hi,
>
> On 12/15/2016 03:03 AM, Gonglei wrote:
> [...]
> > +
> > +static struct crypto_alg virtio_crypto_algs[] = { {
> > + .cra_name = "cbc(aes)",
> > + .cra_driver_name = "virtio_crypto_aes_cbc",
> > + .cra_priority = 501,
>
>
> This is still higher than the hardware-accelerators (like
On 12/15/2016 03:03 AM, Gonglei wrote:
[...]
> +
> +static struct crypto_alg virtio_crypto_algs[] = { {
> + .cra_name = "cbc(aes)",
> + .cra_driver_name = "virtio_crypto_aes_cbc",
> + .cra_priority = 501,
This is still higher than the hardware-accelerators (like intel aesni or the
s39
On Tue, Jan 10, 2017 at 11:00:32AM +0100, Greg KH wrote:
> On Tue, Jan 10, 2017 at 10:21:16AM +0100, Sven Schmidt wrote:
> > On 01/08/2017 12:25 PM, Greg KH wrote:
> > >On Sat, Jan 07, 2017 at 05:55:42PM +0100, Sven Schmidt wrote:
> > >> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Co
On Tue, Jan 10, 2017 at 10:21:16AM +0100, Sven Schmidt wrote:
> On 01/08/2017 12:25 PM, Greg KH wrote:
> >On Sat, Jan 07, 2017 at 05:55:42PM +0100, Sven Schmidt wrote:
> >> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Collet.
> >> The kernel module is inspired by the previous work by
On Tue, Jan 10, 2017 at 10:32:17AM +0100, Sven Schmidt wrote:
> On 01/08/2017 12:23 PM, Greg KH wrote:
> > And follow the proper kernel coding style rules, putting your patches
> > through scripts/checkpatch.pl should help you out here.
>
> Sorry, I didn't know about that particular script. I alre
Hi Kees,
On 01/07/2017 10:33 PM, Kees Cook wrote:
>On Sat, Jan 7, 2017 at 8:55 AM, Sven Schmidt
><4ssch...@informatik.uni-hamburg.de> wrote:
>> This patch updates fs/pstore and fs/squashfs to use the updated functions
>> from
>> the new LZ4 module.
>>
>> Signed-off-by: Sven Schmidt <4ssch.
On 01/08/2017 12:23 PM, Greg KH wrote:
> On Sat, Jan 07, 2017 at 05:55:43PM +0100, Sven Schmidt wrote:
>> This patch updates the unlz4 wrapper to work with the new LZ4 kernel module
>> version.
>>
>> Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
>> ---
>> lib/decompress_unlz4.c
On 01/08/2017 12:25 PM, Greg KH wrote:
>On Sat, Jan 07, 2017 at 05:55:42PM +0100, Sven Schmidt wrote:
>> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Collet.
>> The kernel module is inspired by the previous work by Chanho Min.
>> The updated LZ4 module will not break existing code sin
40 matches
Mail list logo
