On Sun, Jan 22, 2017 at 05:28:42PM -0500, Theodore Ts'o wrote:
> On Sun, Jan 22, 2017 at 04:20:04PM +0100, Greg Kroah-Hartman wrote:
> > > The core stuff is not in the networking tree. This is nothing to do
> > > with the networking tree in any way at all. There might be some
> > > confusion becaus
On Sun, Jan 22, 2017 at 11:49:00PM +0100, Jason A. Donenfeld wrote:
> On Sun, Jan 22, 2017 at 11:28 PM, Theodore Ts'o wrote:
> > If there are other changes to the relevant lines from the networking
> > tree, sure.
>
> This patch set has *nothing* to do with the networking tree. That just
> a topi
On Sun, Jan 22, 2017 at 11:28 PM, Theodore Ts'o wrote:
> If there are other changes to the relevant lines from the networking
> tree, sure.
This patch set has *nothing* to do with the networking tree. That just
a topic confusion. There shouldn't be more discussion about
networking, because it doe
On Sun, Jan 22, 2017 at 04:20:04PM +0100, Greg Kroah-Hartman wrote:
> > The core stuff is not in the networking tree. This is nothing to do
> > with the networking tree in any way at all. There might be some
> > confusion because the initial discussions came from the siphash stuff,
> > which is in
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a va
On Sun, Jan 22, 2017 at 01:21:39PM +0100, Jason A. Donenfeld wrote:
> Hey Greg,
>
> On Sun, Jan 22, 2017 at 12:24 PM, Greg Kroah-Hartman
> wrote:
> > On Sat, Jan 21, 2017 at 03:08:12PM +0100, Jason A. Donenfeld wrote:
> >> Hi Ted,
> >>
> >> On Sat, Jan 21, 2017 at 7:24 AM, Theodore Ts'o wrote:
>
Hey Greg,
On Sun, Jan 22, 2017 at 12:24 PM, Greg Kroah-Hartman
wrote:
> On Sat, Jan 21, 2017 at 03:08:12PM +0100, Jason A. Donenfeld wrote:
>> Hi Ted,
>>
>> On Sat, Jan 21, 2017 at 7:24 AM, Theodore Ts'o wrote:
>> > Oh, I see.
>> >
>> > So that's not how I would do things, but it's fine.
>>
>>
>
On Sat, Jan 21, 2017 at 03:08:12PM +0100, Jason A. Donenfeld wrote:
> Hi Ted,
>
> On Sat, Jan 21, 2017 at 7:24 AM, Theodore Ts'o wrote:
> > Oh, I see.
> >
> > So that's not how I would do things, but it's fine.
>
>
> Great, alright. In what tree should I look for these two commits? Or
> should
Hi Ted,
On Sat, Jan 21, 2017 at 7:24 AM, Theodore Ts'o wrote:
> Oh, I see.
>
> So that's not how I would do things, but it's fine.
Great, alright. In what tree should I look for these two commits? Or
should I send it to the drivers/char maintainer (now CCd)?
Jason
On Sat, Jan 21, 2017 at 01:16:56AM +0100, Jason A. Donenfeld wrote:
> On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o wrote:
> > But there is a shared pointer, which is used both for the dedicated
> > u32 array and the dedicated u64 array. So when you increment the
> > pointer for the get_random_u
On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o wrote:
> But there is a shared pointer, which is used both for the dedicated
> u32 array and the dedicated u64 array. So when you increment the
> pointer for the get_random_u32, the corresponding entry in the u64
> array is wasted, no?
No, it is not
On Fri, Jan 20, 2017 at 04:47:42PM +0100, Jason A. Donenfeld wrote:
>
> What do you mean? Nothing is wasted right now. The u64 function only
> gets u64s from a dedicated u64 array. The u32 function only gets u32s
> from a dedicated u32 array. There are separate batched entropy arrays
> for each fu
Hi Ted,
On Sat, Jan 21, 2017 at 1:10 AM, Theodore Ts'o wrote:
> Why would there be an unaligned access? What I was suggesting was an
> array of u32, and we just do two separate u32 accesses with a shift in
> the case of get_random_u64. There's nothing illegal about that.
>
> u64 retval;
>
>
On Fri, Jan 20, 2017 at 04:38:59PM +0100, Jason A. Donenfeld wrote:
> I was thinking that the issue isn't merely cache line and a slow down,
> but that on some platforms, this could be an _illegal unaligned
> access_. That means we'd need to rewrite the code to use the unaligned
> access helpers or
On Fri, Jan 20, 2017 at 3:28 PM, Theodore Ts'o wrote:
> Compare that to the fact that you're wasting up to 66% of the
> generated words in the batched entropy array, and certainly on average
> you're wasting CPU cycles, even if you are reducing the cost of
> calling get_random_u{32,64} by a handfu
Hi Ted,
On Fri, Jan 20, 2017 at 3:28 PM, Theodore Ts'o wrote:
> What I would probably do is just use one array and one array index,
> denominated in 32-bit words, and just grab two 32-bit words for the
> 64-bit case. Optimizing away the overhead of assembling two 32-bit
> words for a 64-bit word
On Fri, Jan 20, 2017 at 06:27:19AM +0100, Jason A. Donenfeld wrote:
> This is most certainly not the case. Read closely.
>
> I use a different variable for each function. get_random_u32 only
> touches batched_entropy_u32, and get_random_u64 only touches
> bached_entropy_u64. Under no circumstances
Hi Ted,
On Wed, Jan 18, 2017 at 4:49 AM, Theodore Ts'o wrote:
> You're using a union for the entropy_u64 and entropy_u32 arrays, and
> the position field is used to indexed into those two arrays.
>
> So if the first caller calls get_random_u64 with position=0, it will
> get the first 64 bits out
Hi Jason,
I've been taking a look at your patch, and i think it's... problematic.
You're using a union for the entropy_u64 and entropy_u32 arrays, and
the position field is used to indexed into those two arrays.
So if the first caller calls get_random_u64 with position=0, it will
get the first 6
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a va
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a va
21 matches
Mail list logo
