Hi Linus:
Here is the crypto update for 2.6.34:
* New pcrypt module to spread crypto work across CPUs.
* Added RFC4543 GCM support.
* Added nomadik RNG driver.
* MD5 export/import support.
* Random fixes.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
or
On Thu, 25 Feb 2010, Mikael Pettersson wrote:
> > In the sha1_update() case I don't know whether the stack is recycled and
> > leaked - it may be dependent on the calling function, but isn't it
> > vulnerable?
>
> It's only vulnerable if the data leaks to a less trusted domain.
If it is anythi
> 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
Mikael Pettersson wrote:
> It's only vulnerable if the data leaks to a less trusted domain.
> There is no domain crossing in your user-space example.
> In the kernel case, the domain crossing would be as I wrote: leaking
> recycled and uninitialized memory to user-space (and those leaks of
> uninit
On Thu, Feb 25, 2010 at 10:56 AM, Mikael Pettersson wrote:
> Roel Kluin writes:
> > 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/da
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
Pekka Enberg writes:
> 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 rewrite the code abo
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 rewrite the code above as
>
> {
> u32 te
Roel Kluin writes:
>
> > > 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.
> >
> >
Roel Kluin writes:
> 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. C
From: roel kluin
Date: Thu, 25 Feb 2010 16:31:36 +0100
> 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
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-off-by: Roel Kluin
>
> Solution i
> > 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
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-off-by: Roel Kluin
Solution is wrong and overkill in my mind.
It's overkill because the whole
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/sha1_generic.
Roel Kluin writes:
> 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? T
17 matches
Mail list logo
