On 19/03/15 13:02, Andre Wolokita wrote:
> Hi guys,
>
> I'm experiencing a strange issue when booting up u-boot on my older ezkit
> (red board, pre-1.0). Yesterday I updated u-boot and openocd to the 1.0.0.BR
> tag and build u-boot. I tried running u-boot on a 1.0 ezkit but found that
> the bo
Hi guys,
I'm experiencing a strange issue when booting up u-boot on my older ezkit (red
board, pre-1.0). Yesterday I updated u-boot and openocd to the 1.0.0.BR tag and
build u-boot. I tried running u-boot on a 1.0 ezkit but found that the board
was faulty. Then I went back to using the old ezki
On 18-03-2015 14:14, mancha wrote:
On Wed, Mar 18, 2015 at 05:02:01PM +0100, Stephan Mueller wrote:
Am Mittwoch, 18. März 2015, 16:09:34 schrieb Hannes Frederic Sowa:
Seems like just using barrier() is the best and easiest option.
However, if the idea is to use barrier() instead of OPTIMIZER_
From: Tadeusz Struk
Date: Wed, 18 Mar 2015 13:59:30 -0700
> What's your take on this patch set?
I'm really busy so waiting for Al to give some feedback first.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More maj
On Wed, Mar 18, 2015 at 01:02:14PM +, James Hartley wrote:
>
> Herbert: should I send you a patch to address the issues above, or resubmit
> the series with the fixes incorporated?
James, your patch has already been merged so please send any
fixes on top of the cryptodev tree.
Thanks,
--
Em
Am Mittwoch, 18. März 2015, 18:47:25 schrieb Daniel Borkmann:
Hi Daniel,
> From: mancha security
>
> OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to
> ensure protection from dead store optimization.
>
> For the random driver and crypto drivers, calls are emitted ...
>
>
On 03/16/2015 09:15 AM, Tadeusz Struk wrote:
> After the iocb parameter has been removed from sendmsg() and recvmsg() ops
> the socket layer, and the network stack no longer support async operations.
> This patch set adds support for asynchronous operations on sockets back.
>
> --
> Tadeusz Struk
On Wed, Mar 18, 2015 at 06:49:55PM +0100, Daniel Borkmann wrote:
> 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 c
On Wed, Mar 18, 2015, at 18:47, Daniel Borkmann wrote:
> From: mancha security
>
> OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to
> ensure protection from dead store optimization.
>
> For the random driver and crypto drivers, calls are emitted ...
>
> $ gdb vmlinux
> (g
On Tue, Mar 17, 2015 at 10:25 PM, Herbert Xu
wrote:
> Hi Linus:
>
> On Mon, Mar 09, 2015 at 04:19:50PM +1100, Herbert Xu wrote:
>>
>> This push fixes a bug in the ARM XTS implementation that can
>> cause failures to in decrypting encrypted disks.
>
> For some reason this didn't get pulled so I'm r
On Wed, Mar 18, 2015 at 06:56:19PM +0100, Hannes Frederic Sowa wrote:
>
> Maybe a BUILD_BUGON: ;)
Even better! :-)
- Ted
>
> __label__ l1, l2;
> char buffer[1024];
> l1:
> memset(buffer, 0, 1024);
> l2:
> BUILD_BUGON(&&l1 == &&l2);
>
--
To unsubscribe fr
On Wed, Mar 18, 2015, at 18:41, Theodore Ts'o wrote:
> Maybe we should add a kernel self-test that automatically checks
> whether or not memset_explicit() gets optimized away? Otherwise we
> might not notice when gcc or how we implement barrier() or whatever
> else we end up using ends up changing
From: mancha security
OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to
ensure protection from dead store optimization.
For the random driver and crypto drivers, calls are emitted ...
$ gdb vmlinux
(gdb) disassemble memzero_explicit
Dump of assembler code for function me
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 unsub
Maybe we should add a kernel self-test that automatically checks
whether or not memset_explicit() gets optimized away? Otherwise we
might not notice when gcc or how we implement barrier() or whatever
else we end up using ends up changing.
It shold be something that is really fast, so it might be
On Wed, Mar 18, 2015 at 05:02:01PM +0100, Stephan Mueller wrote:
> Am Mittwoch, 18. März 2015, 16:09:34 schrieb Hannes Frederic Sowa:
>
> Hi Hannes,
>
> >On Wed, Mar 18, 2015, at 13:42, Daniel Borkmann wrote:
> >> On 03/18/2015 01:20 PM, Stephan Mueller wrote:
> >> > Am Mittwoch, 18. März 2015, 1
Am Mittwoch, 18. März 2015, 16:09:34 schrieb Hannes Frederic Sowa:
Hi Hannes,
>On Wed, Mar 18, 2015, at 13:42, Daniel Borkmann wrote:
>> On 03/18/2015 01:20 PM, Stephan Mueller wrote:
>> > Am Mittwoch, 18. März 2015, 13:19:07 schrieb Hannes Frederic Sowa:
>> My proposal would be to add a
>>
On Wed, Mar 18, 2015, at 13:42, Daniel Borkmann wrote:
> On 03/18/2015 01:20 PM, Stephan Mueller wrote:
> > Am Mittwoch, 18. März 2015, 13:19:07 schrieb Hannes Frederic Sowa:
> My proposal would be to add a
>
> #define OPTIMIZER_HIDE_MEM(ptr, len) __asm__ __volatile__ ("" : :
> >>>
On Wed, Mar 18, 2015 at 01:02:12PM +0100, Hannes Frederic Sowa wrote:
> On Wed, Mar 18, 2015, at 12:09, 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 wro
Hi Valentin,
> On 18 Mar 2015, at 01:35, Valentin Rothberg
> wrote:
>
> Hi James,
>
> your commit d358f1abbf71 ("crypto: img-hash - Add Imagination
> Technologies hw hash accelerator") adds two selects on undefined
> Kconfig symbols, namely CRYPTO_ALG_API and CRYPTO_SHA224.
>
> The first sym
On 03/18/2015 01:20 PM, Stephan Mueller wrote:
Am Mittwoch, 18. März 2015, 13:19:07 schrieb Hannes Frederic Sowa:
Hi Hannes,
On Wed, Mar 18, 2015, at 13:14, Stephan Mueller wrote:
Am Mittwoch, 18. März 2015, 13:02:12 schrieb Hannes Frederic Sowa:
Hi Hannes,
On Wed, Mar 18, 2015, at 12:09,
Am Mittwoch, 18. März 2015, 13:19:07 schrieb Hannes Frederic Sowa:
Hi Hannes,
>On Wed, Mar 18, 2015, at 13:14, Stephan Mueller wrote:
>> Am Mittwoch, 18. März 2015, 13:02:12 schrieb Hannes Frederic Sowa:
>>
>> Hi Hannes,
>>
>> >On Wed, Mar 18, 2015, at 12:09, Stephan Mueller wrote:
>> >> Am Mit
On Wed, Mar 18, 2015, at 13:14, Stephan Mueller wrote:
> Am Mittwoch, 18. März 2015, 13:02:12 schrieb Hannes Frederic Sowa:
>
> Hi Hannes,
>
> >On Wed, Mar 18, 2015, at 12:09, Stephan Mueller wrote:
> >> Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:
> >> >On 03/18/2015 11:50 AM,
Am Mittwoch, 18. März 2015, 13:02:12 schrieb Hannes Frederic Sowa:
Hi Hannes,
>On Wed, Mar 18, 2015, at 12:09, 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, manc
On Wed, Mar 18, 2015, at 12:09, 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 d4c5e
Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:
Hi Daniel,
>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 again
[ 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);
OPT
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)
{
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)
>{
>memset(s, 0, count);
>
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);
OPTIMIZER_HIDE_VAR(s);
}
OPTIMIZER_HIDE_VAR, introduced in fe
On Wed, Mar 18, 2015 at 12:17:00AM -0700, Keith Packard wrote:
> Hardware random number quality is measured from 0 (no entropy) to 1024
> (perfect entropy). Allow hardware devices to assert the full range by
> truncating the device-provided value at 1024 instead of 1023.
>
> Signed-off-by: Keith P
Hi James,
your commit d358f1abbf71 ("crypto: img-hash - Add Imagination
Technologies hw hash accelerator") adds two selects on undefined
Kconfig symbols, namely CRYPTO_ALG_API and CRYPTO_SHA224.
The first symbols looks like a typo since there is an option
CRYPTO_ALGAPI defined in crypto/Kconfig.
Hardware random number quality is measured from 0 (no entropy) to 1024
(perfect entropy). Allow hardware devices to assert the full range by
truncating the device-provided value at 1024 instead of 1023.
Signed-off-by: Keith Packard
---
drivers/char/hw_random/core.c | 3 ++-
1 file changed, 2 ins
33 matches
Mail list logo
