summaryrefslogtreecommitdiff
path: root/configure
diff options
context:
space:
mode:
authorTobias Klauser <tklauser@distanz.ch>2015-10-13 15:56:03 +0200
committerTobias Klauser <tklauser@distanz.ch>2015-10-13 15:56:03 +0200
commitdaac1198c011aa122cf52004629dd77b4e99ae7d (patch)
tree06fb0b6fdb82728d462e82b9018fe12ca0eae226 /configure
parentadb9677639193700ed7777f1ee085fa7539f8d90 (diff)
trafgen: Make xmit_packet_precheck() return void
The return value of xmit_packet_precheck() is always 0 and it calls panic() in any error cases, so its return value isn't of any use. Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Diffstat (limited to 'configure')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-09-19 10:25:40 +0000
vector. Currently hashtables use jhash, which is fast but not secure, and some kind of rotating key scheme (or none at all, which isn't good). SipHash is meant as a replacement for jhash in these cases. There are a modicum of places in the kernel that are vulnerable to hashtable poisoning attacks, either via userspace vectors or network vectors, and there's not a reliable mechanism inside the kernel at the moment to fix it. The first step toward fixing these issues is actually getting a secure primitive into the kernel for developers to use. Then we can, bit by bit, port things over to it as deemed appropriate. While SipHash is extremely fast for a cryptographically secure function, it is likely a bit slower than the insecure jhash, and so replacements will be evaluated on a case-by-case basis based on whether or not the difference in speed is negligible and whether or not the current jhash usage poses a real security risk. For the second usage: A few places in the kernel are using MD5 or SHA1 for creating secure sequence numbers, syn cookies, port numbers, or fast random numbers. SipHash is a faster and more fitting, and more secure replacement for MD5 in those situations. Replacing MD5 and SHA1 with SipHash for these uses is obvious and straight-forward, and so is submitted along with this patch series. There shouldn't be much of a debate over its efficacy. Dozens of languages are already using this internally for their hash tables and PRFs. Some of the BSDs already use this in their kernels. SipHash is a widely known high-speed solution to a widely known set of problems, and it's time we catch-up. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Eric Biggers <ebiggers3@gmail.com> Cc: David Laight <David.Laight@aculab.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/siphash.txt100
1 files changed, 100 insertions, 0 deletions
diff --git a/Documentation/siphash.txt b/Documentation/siphash.txt
new file mode 100644