Hello,
while booting a latest -net.git kernel on s390x test machine, I've hit this one
below, just in case it was not reported yet:
[...]
[3.317031] qeth 0.0.1000: Outbound TSO not supported on eth0
[3.317123] qeth 0.0.1000: MAC address 02:a1:11:0e:bf:f0 successfully
registered on
On 01/11/2017 07:19 PM, Andy Lutomirski wrote:
On Wed, Jan 11, 2017 at 1:09 AM, Daniel Borkmann <dan...@iogearbox.net> wrote:
[...]
Ok. Sleeping over this a bit, how about a general rename into
"prog_tag" for fdinfo and TCA_BPF_TAG resp. TCA_ACT_BPF_TAG for
the netlink
Hi Andy,
On 01/11/2017 04:11 AM, Andy Lutomirski wrote:
On Tue, Jan 10, 2017 at 4:50 PM, Daniel Borkmann <dan...@iogearbox.net> 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 for
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
On 12/27/2016 10:58 AM, Herbert Xu wrote:
On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote:
According to Daniel, the networking folks want to let embedded systems
include BPF without requiring the crypto core.
Last I checked the IPv4 stack depended on the crypto API so this
instead.
I moved the digest field to keep all of the bpf program metadata in
the same cache line.
Cc: Daniel Borkmann <dan...@iogearbox.net>
Cc: Alexei Starovoitov <a...@kernel.org>
Signed-off-by: Andy Lutomirski <l...@kernel.org>
--
To unsubscribe from this list: send the line
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
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
mage
attacks/collision resistance, which siphash is not. I would prefer some
higher order SHA algorithm for that actually.
You mean:
commit 7bd509e311f408f7a5132fcdde2069af65fa05ae
Author: Daniel Borkmann <dan...@iogearbox.net>
Date: Sun Dec 4 23:19:41 2016 +0100
bpf: add prog_digest and ex
to define this
in compiler-gcc.h only.
Reference: https://llvm.org/bugs/show_bug.cgi?id=15495
Reported-by: Stephan Mueller smuel...@chronox.de
Signed-off-by: Daniel Borkmann dan...@iogearbox.net
Cc: Theodore Ts'o ty...@mit.edu
Cc: Stephan Mueller smuel...@chronox.de
Cc: Hannes Frederic Sowa han
On 04/27/2015 10:41 PM, Stephan Mueller wrote:
...
It seems you have the code already in mind, so please if you could write it
:-)
Ok, sure. I'll cook something by tomorrow morning.
Cheers,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a
On 04/27/2015 09:10 PM, Stephan Mueller wrote:
...
I posted the issue on the clang mailing list on April 10 -- no word so far. I
would interpret this as a sign that it is a no-issue for them.
Hm. ;)
Here's a bug report on the topic, gcc vs llvm:
https://llvm.org/bugs/show_bug.cgi?id=15495
On 04/22/2015 07:02 AM, Herbert Xu wrote:
There is currently a large ifdef FIPS code section in proc.c.
Ostensibly it's there because the fips_enabled sysctl sits under
/proc/sys/crypto. However, no other crypto sysctls exist.
In fact, the whole ethos of the crypto API is against such user
[ Cc'ing Cesar ]
On 03/18/2015 10:53 AM, mancha wrote:
Hi.
The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect
memory cleansing against things like dead store optimization:
void memzero_explicit(void *s, size_t count)
{
memset(s, 0, count);
On 03/18/2015 11:50 AM, Hannes Frederic Sowa wrote:
On Wed, Mar 18, 2015, at 10:53, mancha wrote:
Hi.
The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect
memory cleansing against things like dead store optimization:
void memzero_explicit(void *s, size_t count)
{
, Stephan Mueller wrote:
Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:
On 03/18/2015 11:50 AM, Hannes Frederic Sowa wrote:
On Wed, Mar 18, 2015, at 10:53, mancha wrote:
Hi.
The kernel RNG introduced memzero_explicit in d4c5efdb9777 to
protect
memory cleansing against things like
Signed-off-by: mancha security manc...@zoho.com
Signed-off-by: Daniel Borkmann dan...@iogearbox.net
---
Sending to Herbert as crypto/random are the main users.
Based against -crypto tree. Thanks!
lib/string.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/string.c b/lib
On 03/18/2015 06:14 PM, mancha wrote:
...
Patch 0001 fixes the dead store issue in memzero_explicit().
Thanks! I have issued the fix for the memzero bug to Herbert in
your authorship as discussed, also giving some more context.
For the 2nd issue, lets wait for Cesar.
Thanks again!
--
To
...@gondor.apana.org.au
Signed-off-by: Daniel Borkmann dbork...@redhat.com
---
[ Sending to -crypto as it's most relevant here and suggested by
Herbert anyway. ]
lib/string.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/string.c b/lib/string.c
index 1006330..d984ec4 100644
--- a/lib
On 11/12/2014 08:05 AM, Stephan Mueller wrote:
This patch adds the random number generator support for AF_ALG.
A random number generator's purpose is to generate data without
requiring the caller to provide any data. Therefore, the AF_ALG
interface handler for RNGs only implements a callback
On 11/12/2014 05:54 PM, Stephan Mueller wrote:
Am Mittwoch, 12. November 2014, 17:15:52 schrieb Daniel Borkmann:
On 11/12/2014 08:05 AM, Stephan Mueller wrote:
This patch adds the random number generator support for AF_ALG.
A random number generator's purpose is to generate data without
On 11/12/2014 06:46 PM, Stephan Mueller wrote:
...
* I unconditionally use the memset after memcpy as you indicated. Once
the cryptodev tree contains the memzero_explicit call, I will start
picking up that function.
Herbert merged it actually in this morning, so it's already part of
the
On 11/11/2014 05:16 AM, Stephan Mueller wrote:
...
That is a good idea.
Herbert: I can prepare a patch that uses memzero_explicit. However, your
current tree does not yet implement that function as it was added to Linus'
tree after you pulled from it.
Yep, Ted took it [1] on top of the random
Hi Stephan,
On 11/11/2014 05:37 AM, Stephan Mueller wrote:
Zeroize the buffer holding the message digest calculated for the
consumer before the buffer is released by the hash AF_ALG interface
handler.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
crypto/algif_hash.c | 2 ++
1 file
On 10/08/2014 04:30 AM, Sandy Harris wrote:
I have started a thread about this on the gcc help mailing list
https://gcc.gnu.org/ml/gcc-help/2014-10/msg00047.html
Great, perhaps you want to pass a patch proposal to gcc folks?
We might consider replacinging memzero_explicit with memset_s()
On 10/06/2014 08:52 PM, Sandy Harris wrote:
On Mon, Oct 6, 2014 at 1:44 PM, Jason Cooper ja...@lakedaemon.net wrote:
On Sat, Oct 04, 2014 at 11:09:40PM -0400, Sandy Harris wrote:
...
There was recently a patch to the random driver to replace memset()
because, according to the submitter, gcc
Hi Sandy,
On 10/05/2014 05:09 AM, Sandy Harris wrote:
There was recently a patch to the random driver to replace memset()
because, according to the submitter, gcc sometimes optimises memset()
away which might leave data unnecessarily exposed. The solution
suggested was a function called
Hi Ted,
On 09/15/2014 01:52 PM, Herbert Xu wrote:
On Sun, Sep 07, 2014 at 11:23:38PM +0200, Daniel Borkmann wrote:
Recently, in commit 13aa93c70e71 (random: add and use memzero_explicit()
for clearing data), we have found that GCC may optimize some memset()
cases away when it detects a stack
;
identifier s;
@@
T s[...];
... when any
memset(s,...);
... when != s
Therefore, make use of the drop-in replacement memzero_explicit() for
exactly such cases instead of using memset().
Signed-off-by: Daniel Borkmann dbork...@redhat.com
Cc: Julia Lawall julia.law...@lip6.fr
Cc: Herbert Xu herb
Hi Milan,
On 09/07/2014 07:15 PM, Milan Broz wrote:
On 09/07/2014 06:46 PM, Daniel Borkmann wrote:
Recently, in commit 13aa93c70e71 (random: add and use memzero_explicit()
for clearing data), we have found that GCC may optimize some memset()
cases away when it detects a stack variable
Replace remaining occurences (just as we did in crypto/) under arch/*/crypto/
that make use of memcmp() for comparing keys or authentication tags for
usage with crypto_memneq(). It can simply be used as a drop-in replacement
for the normal memcmp().
Signed-off-by: Daniel Borkmann dbork
: Cesar Eduardo Barros ces...@cesarb.eti.br
Signed-off-by: Daniel Borkmann dbork...@redhat.com
---
Sending stand-alone fix as original patch is already applied.
crypto/memneq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/memneq.c b/crypto/memneq.c
index 570f6f3
On 11/26/2013 10:44 PM, Cesar Eduardo Barros wrote:
Em 26-11-2013 17:27, Daniel Borkmann escreveu:
On 11/26/2013 01:00 AM, Cesar Eduardo Barros wrote:
Compile-tested on x86_64.
Actually with yet another version, I hoped that the compile-tested-only
statement would eventually disappear, ohh
On 11/26/2013 01:00 AM, Cesar Eduardo Barros wrote:
Disabling compiler optimizations can be fragile, since a new
optimization could be added to -O0 or -Os that breaks the assumptions
the code is making.
Instead of disabling compiler optimizations, use a dummy inline assembly
(based on
On 11/25/2013 04:59 PM, James Yonan wrote:
On 24/11/2013 14:12, Cesar Eduardo Barros wrote:
Disabling compiler optimizations can be fragile, since a new
optimization could be added to -O0 or -Os that breaks the assumptions
the code is making.
Instead of disabling compiler optimizations, use a
-independent timing) even if it is inlined at its call sites. That
can be done later in a followup patch.
Compile-tested on x86_64.
Signed-off-by: Cesar Eduardo Barros ces...@cesarb.eti.br
Acked-by: Daniel Borkmann dbork...@redhat.com
Looks good, thanks!
--
To unsubscribe from this list: send
On 09/19/2013 02:13 AM, James Yonan wrote:
[...]
We can easily specify -Os in the Makefile rather than depending on #pragma
optimize or __attribute__ optimize if they are considered broken.
Re: arch/*/crypto/... asm, not sure it's worth it given the extra effort to
develop, test, and maintain
On 09/16/2013 07:10 PM, James Yonan wrote:
On 16/09/2013 01:56, Daniel Borkmann wrote:
On 09/15/2013 06:59 PM, James Yonan wrote:
On 15/09/2013 09:45, Florian Weimer wrote:
* James Yonan:
+ * Constant-time equality testing of memory regions.
+ * Returns 0 when data is equal, non-zero
On 09/15/2013 06:59 PM, James Yonan wrote:
On 15/09/2013 09:45, Florian Weimer wrote:
* James Yonan:
+ * Constant-time equality testing of memory regions.
+ * Returns 0 when data is equal, non-zero otherwise.
+ * Fast path if size == 16.
+ */
+noinline unsigned long crypto_mem_not_equal(const
On 09/11/2013 07:20 PM, James Yonan wrote:
On 10/09/2013 12:57, Daniel Borkmann wrote:
There was a similar patch posted some time ago [1] on lkml, where
Florian (CC) made a good point in [2] that future compiler optimizations
could short circuit on this. This issue should probably be addressed
On 09/10/2013 08:38 PM, James Yonan wrote:
When comparing MAC hashes, AEAD authentication tags, or other hash
values in the context of authentication or integrity checking, it
is important not to leak timing information to a potential attacker.
Bytewise memory comparisons (such as memcmp) are
.
So the fix is to hold a reference count on the larval.
Cc: sta...@vger.kernel.org # 3.6+
Reported-by: Daniel Borkmann dbork...@redhat.com
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
Tested-by: Daniel Borkmann dbork...@redhat.com
This fixes the panic for me
. This is valid, because in case a signal is pending,
cryptomgr_probe() returns from probing anyway with properly calling
complete_all().
Signed-off-by: Daniel Borkmann dbork...@redhat.com
---
v1-v2:
- Submitting as non-RFC
- Slightly improving commit message
crypto/algboss.c | 2 +-
1 file changed, 1
. This is valid, because in case a signal is pending,
cryptomgr_probe() returns from probing anyway with properly calling
complete_all().
Signed-off-by: Daniel Borkmann dbork...@redhat.com
---
v1-v2:
- Submitting as non-RFC
- Slightly improving commit message
crypto/algboss.c | 2 +-
1 file changed, 1
-by: Daniel Borkmann dbork...@redhat.com
---
I'm not very familiar with the crypto subsystem and not entirely
sure if this is the best solution. However, it has fixed the panic
in my case.
crypto/algboss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/algboss.c b
45 matches
Mail list logo
