linux-kernel - RE: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB025AC4D@AcuExch.aculab.com>
Date:   Mon, 9 Jan 2017 13:18:09 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Eric Biggers' <ebiggers3@...il.com>,
        David Miller <davem@...emloft.net>
CC:     "Jason@...c4.com" <Jason@...c4.com>,
        "jeanphilippe.aumasson@...il.com" <jeanphilippe.aumasson@...il.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "tom@...bertland.com" <tom@...bertland.com>,
        "hannes@...essinduktion.org" <hannes@...essinduktion.org>,
        "eric.dumazet@...il.com" <eric.dumazet@...il.com>,
        "luto@...nel.org" <luto@...nel.org>
Subject: RE: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

From: Eric Biggers
> Sent: 07 January 2017 22:09
..
> Out of curiosity, is this actually a solvable problem, e.g. by making the code
> using the XMM registers responsible for saving and restoring the ones clobbered,
> or by optimizing kernel_fpu_begin()/kernel_fpu_end()?  Or does it in fact remain
> impractical for such instructions to be used for applications like this one?

I think it should be possible to fast-save a couple of FP registers
by telling the IPI save code where to save them from (to load
into a different cpu).
But there might be issues with other parts of the FP state.
This might be ok provided the kernel doesn't actually use FP instructions.

(I thought about this when adding AVX support to NetBSD.)

	David