Re: x86-64: Maintain 16-byte stack alignment

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

Re: x86-64: Maintain 16-byte stack alignment

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

Re: x86-64: Maintain 16-byte stack alignment

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

Re: x86-64: Maintain 16-byte stack alignment

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

Re: x86-64: Maintain 16-byte stack alignment

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); > >

Re: x86-64: Maintain 16-byte stack alignment

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

Re: x86-64: Maintain 16-byte stack alignment

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

Re: x86-64: Maintain 16-byte stack alignment

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

Re: x86-64: Maintain 16-byte stack alignment

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

Re: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256

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

Re: [PATCH v2 0/8] Switch BPF's digest to SHA256

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: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256

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

[PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256

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

[PATCH v2 4/8] bpf: Use SHA256 instead of SHA1 for bpf digests

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

[PATCH v2 6/8] bpf: Rename fdinfo's prog_digest to prog_sha256

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'.

[PATCH v2 3/8] crypto/sha256: Build the SHA256 core separately from the crypto module

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

Re: x86-64: Maintain 16-byte stack alignment

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

[PATCH v2 5/8] bpf: Avoid copying the entire BPF program when hashing it

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

[PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests

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

[PATCH v2 2/8] crypto/sha256: Export a sha256_{init,update,final}_direct() API

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

[PATCH v2 0/8] Switch BPF's digest to SHA256

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

[PATCH v2 1/8] crypto/sha256: Factor out the parts of base API that don't use shash_desc

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

Re: x86-64: Maintain 16-byte stack alignment

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 >>>

Re: x86-64: Maintain 16-byte stack alignment

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

Re: x86-64: Maintain 16-byte stack alignment

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 >>> >>>

Re: x86-64: Maintain 16-byte stack alignment

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

Re: x86-64: Maintain 16-byte stack alignment

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: > >

Re: x86-64: Maintain 16-byte stack alignment

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

Re: x86-64: Maintain 16-byte stack alignment

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

x86-64: Maintain 16-byte stack alignment

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

Re: [PATCH v8 1/1] crypto: add virtio-crypto driver

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

RE: [PATCH v8 1/1] crypto: add virtio-crypto driver

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

Re: [PATCH v8 1/1] crypto: add virtio-crypto driver

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

Re: [PATCH v2 1/4] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

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

Re: [PATCH v2 1/4] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

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

Re: [PATCH v2 1/4] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

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

Re: [PATCH v2 4/4] fs/pstore: fs/squashfs: Change usage of LZ4 to comply with new LZ4 module version

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

Re: [PATCH v2 1/4] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

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> >> --- >>

Re: [PATCH v2 1/4] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

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