Fix a PTR_ERR() return of the wrong pointer
Signed-off-by: Roel Kluin
---
drivers/crypto/mv_cesa.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 7d279e5..c99305a 100644
--- a/drivers/crypto/mv_cesa.c
+++ b
ng a variable, but has been confirmed to
work with gcc-3.2.3 up to gcc-4.4.3.
Many thanks to Mikael Pettersson and Andi Kleen.
Signed-off-by: Roel Kluin
---
I used a trick to prevent the assembly for Itanium, defining
fake_memory_use in instrinsics.h and checking its definition
in string.c, but
rst byte, via e.g. asm("" :: "m"(*(char*)p)), then the compiler
_will_ skip scrubbing bytes beyond the first. This works with
gcc-3.2.3 up to gcc-4.4.3.
Thanks to Mikael Pettersson for this information.
Signed-off-by: Roel Kluin
---
> You forgot to credit Mikael
Not
rst byte, via e.g. asm("" :: "m"(*(char*)p)), then the compiler
_will_ skip scrubbing bytes beyond the first. This works with
gcc-3.2.3 up to gcc-4.4.3.
Signed-off-by: Roel Kluin
---
include/linux/compiler-gcc.h | 11 +++
include/linux/compiler-intel.h |
> Also from that document:
>
> If you know how large the accessed memory is, you can add it as input or
> output but if this is not known, you should add memory. As an example, if
> you access ten bytes of a string, you can use a memory input like:
>
> {"m"( ({ struct { char x[10]; } *p = (v
Op 25-02-10 18:32, Brian Gerst schreef:
> On Thu, Feb 25, 2010 at 12:09 PM, Mikael Pettersson wrote:
>> Brian Gerst wrote:
>>> Would barrier() (which is a simple memory clobber) after the memset work?
>>
>> I don't know. It's implemented as an asm with a "memory" clobber,
>> but I wouldn't bet on
On Thu, Feb 25, 2010 at 5:16 PM, Pekka Enberg wrote:
> On Thu, Feb 25, 2010 at 5:56 PM, Mikael Pettersson wrote:
>> I fear that the only portable (across compiler versions) and safe
>> solution is to invoke an assembly-coded dummy function with prototype
>>
>> void use(void *p);
>>
>> and
On Thu, Feb 25, 2010 at 4:17 PM, David Miller wrote:
> From: Roel Kluin
> Date: Thu, 25 Feb 2010 16:10:27 +0100
>
>> Due to optimization A call to memset() may be removed as a dead store when
>> the buffer is not used after its value is overwritten.
>>
>> Signed
> > Does this optimization also occur during compilation of the Linux
> > kernel?
> Any such dead store removal is up to the compiler and the lifetime
> of the object being clobbered. For 'auto' objects the optimization
> is certainly likely.
>
> This is only a problem if the memory (a threa
Due to optimization A call to memset() may be removed as a dead store when
the buffer is not used after its value is overwritten.
Signed-off-by: Roel Kluin
---
see http://cwe.mitre.org/data/slices/2000.html#14
checkpatch.pl, compile and sparse tested. Comments?
diff --git a/crypto
According to http://cwe.mitre.org/data/slices/2000.html#14 due to optimization
A call to memset() can be removed as a dead store when the buffer is not used
after its value is overwritten. Does this optimization also occur during
compilation of the Linux kernel? Then I think I may have found some
v
a crypto_cipher cip member was set where a crypto_cipher blk members
should have been.
Signed-off-by: Roel Kluin
---
>> I think my previous patch missed one
>> blk to cip conversion in geode_setkey_cip():
>
> Please send an incremental patch. Thanks!
Ok, here's the mis
On Fri, Jan 29, 2010 at 3:51 PM, Sebastian Andrzej Siewior
wrote:
> * Roel Kluin | 2010-01-29 14:32:56 [+0100]:
>
>>This was already discussed in december/januari but I still cannot find it in
>>mainline, was it lost?
>
> Isn't this patch [0] and [1] in Herbert's
crypto_cipher cip members were set where crypto_cipher blk members should
have been, also the PTR_ERR of the wrong pointer was returned.
Signed-off-by: Roel Kluin
---
This was already discussed in december/januari but I still cannot find it in
mainline, was it lost?
diff --git a/arch/s390
Return the PTR_ERR of the correct pointer.
Signed-off-by: Roel Kluin
---
> This is correct however you missed one spot a few lines above that one.
> Sergey Mironov sent a patch a while ago unfortunatelly a mangled one and
> he hasn't resent it yet.
> Could you please look at [0
Return the PTR_ERR of the correct pointer.
Signed-off-by: Roel Kluin
---
drivers/crypto/geode-aes.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index 4801162..12cf864 100644
--- a/drivers/crypto/geode-aes.c
t; Hmm, if it's unneeded why don't we just kill it instead?
In that case:
-->8--8<-
size_t nbytes cannot be less than 0 and the test was redundant.
Acked-by: Neil Horman
Signed-off-by: Roel Kluin
---
diff --
size_t nbytes cannot be less than 0.
Signed-off-by: Roel Kluin
---
Or should this test be removed?
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index 3aa6e38..9162456 100644
--- a/crypto/ansi_cprng.c
+++ b/crypto/ansi_cprng.c
@@ -192,7 +192,7 @@ static int get_prng_bytes(char *buf
In crypto_aes_expand_key() loop8(i) writes up to ctx->key_enc[8*i+15], at most
63. ctx->key_enc has length (15*16)/4 == 60, so the last 16 bytes of key_enc
will overflow into ctx->key_dec.
Signed-off-by: Roel Kluin
---
Found with Parfait, http://research.sun.com/projects/parfait/
This
19 matches
Mail list logo
