On 12/22/2016 05:59 PM, Hannes Frederic Sowa wrote:
On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa
wrote:
On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
wrote:
On 12/22/2016 06:25 PM, Andy Lutomirski wrote:
On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
[...]
I wondered if bpf program loading should have used the module loading
infrastructure from the beginning...
That would be way too complicated and would be nasty for the unprivileged cases
On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote:
> On 12/22/2016 05:59 PM, Hannes Frederic Sowa wrote:
> > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
> > > On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa
> > > wrote:
> > > > On Thu, 2016-12-22 at 16:41 +0100, Jason A.
Am Donnerstag, 22. Dezember 2016, 17:38:00 CET schrieb Cyrille Pitchen:
Hi Cyrille,
> This patchs allows to combine the AES and SHA hardware accelerators on
> some Atmel SoCs. Doing so, AES blocks are only written to/read from the
> AES hardware. Those blocks are also transferred from the AES to
On 12/23/2016 11:59 AM, Hannes Frederic Sowa wrote:
On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote:
On 12/22/2016 05:59 PM, Hannes Frederic Sowa wrote:
On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
[...]
The hashing is not a proper sha1 neither, unfortunately. I think th
On Thu, 2016-12-22 at 19:07 -0500, George Spelvin wrote:
> Hannes Frederic Sowa wrote:
> > A lockdep test should still be done. ;)
>
> Adding might_lock() annotations will improve coverage a lot.
Might be hard to find the correct lock we take later down the code
path, but if that is possible, cer
On Fri, Dec 23, 2016 at 3:59 AM, Daniel Borkmann wrote:
> On 12/23/2016 11:59 AM, Hannes Frederic Sowa wrote:
>>
>> On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote:
>>>
>>> On 12/22/2016 05:59 PM, Hannes Frederic Sowa wrote:
On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wro
On Fri, Dec 23, 2016 at 8:23 AM, Andy Lutomirski wrote:
> On Fri, Dec 23, 2016 at 3:59 AM, Daniel Borkmann wrote:
>> On 12/23/2016 11:59 AM, Hannes Frederic Sowa wrote:
>>>
>>> On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote:
On 12/22/2016 05:59 PM, Hannes Frederic Sowa wrote:
On 23.12.2016 17:42, Andy Lutomirski wrote:
> On Fri, Dec 23, 2016 at 8:23 AM, Andy Lutomirski wrote:
>> On Fri, Dec 23, 2016 at 3:59 AM, Daniel Borkmann
>> wrote:
>>> On 12/23/2016 11:59 AM, Hannes Frederic Sowa wrote:
On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote:
>
>>
(Cc: list trimmed slightly as the topic is wandering a bit.)
Hannes Frederic Sowa wrote:
> On Thu, 2016-12-22 at 19:07 -0500, George Spelvin wrote:
>> Adding might_lock() annotations will improve coverage a lot.
>
> Might be hard to find the correct lock we take later down the code
> path, but if
Hi,
On Fri, 2016-12-23 at 13:26 -0500, George Spelvin wrote:
> (Cc: list trimmed slightly as the topic is wandering a bit.)
>
> Hannes Frederic Sowa wrote:
> > On Thu, 2016-12-22 at 19:07 -0500, George Spelvin wrote:
> > > Adding might_lock() annotations will improve coverage a lot.
> >
> > Migh
On Fri, Dec 23, 2016 at 7:19 PM, Hannes Frederic Sowa
wrote:
> Factoring out sha3
Per the other thread, you probably don't actually want SHA3, because
it's slow in software. You want SHA2. If you want something faster and
better, then Blake2 is most certainly the way to go. I'll be
submitting som
Hannes Frederic Sowa wrote:
> In general this looks good, but bitbuffer needs to be protected from
> concurrent access, thus needing at least some atomic instruction and
> disabling of interrupts for the locking if done outside of
> get_random_long. Thus I liked your previous approach more where yo
Hi,
On 24.12.2016 00:39, George Spelvin wrote:
> Hannes Frederic Sowa wrote:
>> In general this looks good, but bitbuffer needs to be protected from
>> concurrent access, thus needing at least some atomic instruction and
>> disabling of interrupts for the locking if done outside of
>> get_random_l
Hannes Frederic Sowa wrote:
> On 24.12.2016 00:39, George Spelvin wrote:
>> We just finished discussing why 8 bytes isn't enough. If you only
>> feed back 8 bytes, an attacker who can do 2^64 computation can find it
>> (by guessing and computing forward to verify the guess) and recover the
>> prev
Since there are plenty of uses for the new-in-4.10 BPF digest feature
that would be problematic if malicious users could produce collisions,
the BPF digest should be collision-resistant. SHA-1 is no longer
considered collision-resistant, so switch it to SHA-256.
The actual switchover is trivial.
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 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
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'.
There are some pieecs of kernel code that want to compute SHA256
directly without going through the crypto core. Adjust the exported
API to decouple it from the crypto core.
I suspect this will very slightly speed up the SHA256 shash operations
as well by reducing the amount of indirection involv
BPF digests are intended to be used to avoid reloading programs that
are already loaded. For use cases (CRIU?) where untrusted programs
are involved, intentional hash collisions could cause the wrong BPF
program to execute. Additionally, if BPF digests are ever used
in-kernel to skip verification
This will let other kernel code call into sha256_init(), etc. without
pulling in the core crypto code.
Signed-off-by: Andy Lutomirski
---
crypto/Kconfig | 8
crypto/Makefile | 2 +-
crypto/sha256_generic.c | 4
include/crypto/sha.h| 4
4 files changed, 17
On Fri, Dec 23, 2016 at 6:22 PM, Andy Lutomirski wrote:
> There are some pieecs of kernel code that want to compute SHA256
> directly without going through the crypto core. Adjust the exported
> API to decouple it from the crypto core.
>
> I suspect this will very slightly speed up the SHA256 sha
23 matches
Mail list logo
