Hi, Michael & Herbert
Because the virtio-crypto device emulation had been in QEMU 2.8,
would you please merge the virtio-crypto driver for 4.10 if no other
comments? If so, Miachel pls ack and/or review the patch, then
Herbert will take it (I asked him last week). Thank you!
Ps: Note on 4.10 merg
Hey Linus,
On Mon, Dec 12, 2016 at 5:01 AM, Linus Torvalds
wrote:
> The above is extremely inefficient. Considering that most kernel data
> would be expected to be smallish, that matters (ie the usual benchmark
> would not be about hashing megabytes of data, but instead millions of
> hashes of sm
On Mon, Dec 12, 2016 at 04:48:17AM +0100, Jason A. Donenfeld wrote:
>
> diff --git a/lib/Makefile b/lib/Makefile
> index 50144a3aeebd..71d398b04a74 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -22,7 +22,8 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
>sha1.o chacha20.o md5.o
On Sun, Dec 11, 2016 at 7:48 PM, Jason A. Donenfeld wrote:
> + switch (left) {
> + case 7: b |= ((u64)data[6]) << 48;
> + case 6: b |= ((u64)data[5]) << 40;
> + case 5: b |= ((u64)data[4]) << 32;
> + case 4: b |= ((u64)data[3]) << 24;
>
SipHash is a 64-bit keyed hash function that is actually a
cryptographically secure PRF, like HMAC. Except SipHash is super fast,
and is meant to be used as a hashtable keyed lookup function.
SipHash isn't just some new trendy hash function. It's been around for a
while, and there really isn't any
Hello, Chandramouli
Sorry for last email.
These days we experienced 5 times kernel crash issue when using sha1 as
csums-alg for drbd on our CentOS7.2 3.10.0-327.el7.x86_64:
Kernel log as below:
[19839335.792807] BUG: unable to handle kernel paging request at
88007bd4f000
[19839335.793145]
On Sun, Dec 11, 2016 at 11:13:55AM -0800, Andy Lutomirski wrote:
> On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote:
> > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by
> > default on x86_64. This has been exposing a number of problems in which
> > on-stack buffers a
On Sun, Dec 11, 2016 at 04:30:31PM +0100, Jason A. Donenfeld wrote:
> Hi Greg,
>
> Thanks for the review. Responses to your suggestions are inline below:
>
> On Sat, Dec 10, 2016 at 1:37 PM, Greg KH wrote:
> > Please use u64 and u8 instead of the userspace uint64_t and uint8_t
> > types for kern
Hi,
The Linux kernel exports a network interface of type AF_ALG to allow user
space to utilize the kernel crypto API. libkcapi uses this network interface
and exports an easy to use API so that a developer does not need to consider
the low-level network interface handling.
The library does no
On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote:
> In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by
> default on x86_64. This has been exposing a number of problems in which
> on-stack buffers are being passed into the crypto API, which to support crypto
> accelerato
Hi Greg,
Thanks for the review. Responses to your suggestions are inline below:
On Sat, Dec 10, 2016 at 1:37 PM, Greg KH wrote:
> Please use u64 and u8 instead of the userspace uint64_t and uint8_t
> types for kernel code. Yes, the ship has probably sailed for trying to
> strictly enforce it, b
11 matches
Mail list logo
