Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Changes in 4.4.191 HID: Add 044f:b320 ThrustMaster, Inc. 2 in 1 DT MIPS: kernel: only use i8253 clocksource with periodic clockevent netfilter: ebtables: fix a memory leak bug in compat bonding: Force slave speed check after link state recovery for 802.3ad can: dev: call netif_carrier_off() in register_candev() st21nfca_connectivity_event_received: null check the allocation st_nci_hci_connectivity_event_received: null check the allocation ASoC: ti: davinci-mcasp: Correct slot_width posed constraint net: usb: qmi_wwan: Add the BroadMobi BM818 card isdn: mISDN: hfcsusb: Fix possible null-pointer dereferences in start_isoc_chain() isdn: hfcsusb: Fix mISDN driver crash caused by transfer buffer on the stack perf bench numa: Fix cpu0 binding can: sja1000: force the string buffer NULL-terminated can: peak_usb: force the string buffer NULL-terminated NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim() net: cxgb3_main: Fix a resource leak in a error path in 'init_one()' net: hisilicon: make hip04_tx_reclaim non-reentrant net: hisilicon: fix hip04-xmit never return TX_BUSY net: hisilicon: Fix dma_map_single failed on arm64 libata: add SG safety checks in SFF pio transfers selftests: kvm: Adding config fragments HID: wacom: correct misreported EKR ring values Revert "dm bufio: fix deadlock with loop device" userfaultfd_release: always remove uffd flags and clear vm_userfaultfd_ctx x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386 x86/apic: Handle missing global clockevent gracefully x86/boot: Save fields explicitly, zero out everything else x86/boot: Fix boot regression caused by bootparam sanitizing dm btree: fix order of block initialization in btree_split_beneath dm space map metadata: fix missing store of apply_bops() return value dm table: fix invalid memory accesses with too high sector number cgroup: Disable IRQs while holding css_set_lock GFS2: don't set rgrp gl_object until it's inserted into rgrp tree net: arc_emac: fix koops caused by sk_buff free vhost-net: set packet weight of tx polling to 2 * vq size vhost_net: use packet weight for rx handler, too vhost_net: introduce vhost_exceeds_weight() vhost: introduce vhost_exceeds_weight() vhost_net: fix possible infinite loop vhost: scsi: add weight support siphash: add cryptographically secure PRF siphash: implement HalfSipHash1-3 for hash tables inet: switch IP ID generator to siphash netfilter: ctnetlink: don't use conntrack/expect object addresses as id netfilter: conntrack: Use consistent ct id hash calculation Revert "perf test 6: Fix missing kvm module load for s390" x86/pm: Introduce quirk framework to save/restore extra MSR registers around suspend/resume x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h scsi: ufs: Fix NULL pointer dereference in ufshcd_config_vreg_hpm() dmaengine: ste_dma40: fix unneeded variable warning usb: gadget: composite: Clear "suspended" on reset/disconnect usb: host: fotg2: restart hcd after port reset tools: hv: fix KVP and VSS daemons exit code watchdog: bcm2835_wdt: Fix module autoload tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit tcp: make sure EPOLLOUT wont be missed ALSA: seq: Fix potential concurrent access to the deleted pool KVM: x86: Don't update RIP or do single-step on faulting emulation x86/apic: Do not initialize LDR and DFR for bigsmp x86/apic: Include the LDR when clearing out APIC registers usb-storage: Add new JMS567 revision to unusual_devs USB: cdc-wdm: fix race between write and disconnect due to flag abuse usb: host: ohci: fix a race condition between shutdown and irq USB: storage: ums-realtek: Update module parameter description for auto_delink_en USB: storage: ums-realtek: Whitelist auto-delink support ptrace,x86: Make user_64bit_mode() available to 32-bit builds uprobes/x86: Fix detection of 32-bit user mode mmc: sdhci-of-at91: add quirk for broken HS200 mmc: core: Fix init of SD cards reporting an invalid VDD range stm class: Fix a double free of stm_source_device VMCI: Release resource if the work is already queued Revert "cfg80211: fix processing world regdomain when non modular" mac80211: fix possible sta leak x86/ptrace: fix up botched merge of spectrev1 fix Linux 4.4.191 Change-Id: I9c9b3ec748ba2977b818fd569d1788ed5da295b2 Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
- Loading branch information
Showing
85 changed files
with
1,947 additions
and
251 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,175 @@ | ||
SipHash - a short input PRF | ||
----------------------------------------------- | ||
Written by Jason A. Donenfeld <jason@zx2c4.com> | ||
|
||
SipHash is a cryptographically secure PRF -- a keyed hash function -- that | ||
performs very well for short inputs, hence the name. It was designed by | ||
cryptographers Daniel J. Bernstein and Jean-Philippe Aumasson. It is intended | ||
as a replacement for some uses of: `jhash`, `md5_transform`, `sha_transform`, | ||
and so forth. | ||
|
||
SipHash takes a secret key filled with randomly generated numbers and either | ||
an input buffer or several input integers. It spits out an integer that is | ||
indistinguishable from random. You may then use that integer as part of secure | ||
sequence numbers, secure cookies, or mask it off for use in a hash table. | ||
|
||
1. Generating a key | ||
|
||
Keys should always be generated from a cryptographically secure source of | ||
random numbers, either using get_random_bytes or get_random_once: | ||
|
||
siphash_key_t key; | ||
get_random_bytes(&key, sizeof(key)); | ||
|
||
If you're not deriving your key from here, you're doing it wrong. | ||
|
||
2. Using the functions | ||
|
||
There are two variants of the function, one that takes a list of integers, and | ||
one that takes a buffer: | ||
|
||
u64 siphash(const void *data, size_t len, const siphash_key_t *key); | ||
|
||
And: | ||
|
||
u64 siphash_1u64(u64, const siphash_key_t *key); | ||
u64 siphash_2u64(u64, u64, const siphash_key_t *key); | ||
u64 siphash_3u64(u64, u64, u64, const siphash_key_t *key); | ||
u64 siphash_4u64(u64, u64, u64, u64, const siphash_key_t *key); | ||
u64 siphash_1u32(u32, const siphash_key_t *key); | ||
u64 siphash_2u32(u32, u32, const siphash_key_t *key); | ||
u64 siphash_3u32(u32, u32, u32, const siphash_key_t *key); | ||
u64 siphash_4u32(u32, u32, u32, u32, const siphash_key_t *key); | ||
|
||
If you pass the generic siphash function something of a constant length, it | ||
will constant fold at compile-time and automatically choose one of the | ||
optimized functions. | ||
|
||
3. Hashtable key function usage: | ||
|
||
struct some_hashtable { | ||
DECLARE_HASHTABLE(hashtable, 8); | ||
siphash_key_t key; | ||
}; | ||
|
||
void init_hashtable(struct some_hashtable *table) | ||
{ | ||
get_random_bytes(&table->key, sizeof(table->key)); | ||
} | ||
|
||
static inline hlist_head *some_hashtable_bucket(struct some_hashtable *table, struct interesting_input *input) | ||
{ | ||
return &table->hashtable[siphash(input, sizeof(*input), &table->key) & (HASH_SIZE(table->hashtable) - 1)]; | ||
} | ||
|
||
You may then iterate like usual over the returned hash bucket. | ||
|
||
4. Security | ||
|
||
SipHash has a very high security margin, with its 128-bit key. So long as the | ||
key is kept secret, it is impossible for an attacker to guess the outputs of | ||
the function, even if being able to observe many outputs, since 2^128 outputs | ||
is significant. | ||
|
||
Linux implements the "2-4" variant of SipHash. | ||
|
||
5. Struct-passing Pitfalls | ||
|
||
Often times the XuY functions will not be large enough, and instead you'll | ||
want to pass a pre-filled struct to siphash. When doing this, it's important | ||
to always ensure the struct has no padding holes. The easiest way to do this | ||
is to simply arrange the members of the struct in descending order of size, | ||
and to use offsetendof() instead of sizeof() for getting the size. For | ||
performance reasons, if possible, it's probably a good thing to align the | ||
struct to the right boundary. Here's an example: | ||
|
||
const struct { | ||
struct in6_addr saddr; | ||
u32 counter; | ||
u16 dport; | ||
} __aligned(SIPHASH_ALIGNMENT) combined = { | ||
.saddr = *(struct in6_addr *)saddr, | ||
.counter = counter, | ||
.dport = dport | ||
}; | ||
u64 h = siphash(&combined, offsetofend(typeof(combined), dport), &secret); | ||
|
||
6. Resources | ||
|
||
Read the SipHash paper if you're interested in learning more: | ||
https://131002.net/siphash/siphash.pdf | ||
|
||
|
||
~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ | ||
|
||
HalfSipHash - SipHash's insecure younger cousin | ||
----------------------------------------------- | ||
Written by Jason A. Donenfeld <jason@zx2c4.com> | ||
|
||
On the off-chance that SipHash is not fast enough for your needs, you might be | ||
able to justify using HalfSipHash, a terrifying but potentially useful | ||
possibility. HalfSipHash cuts SipHash's rounds down from "2-4" to "1-3" and, | ||
even scarier, uses an easily brute-forcable 64-bit key (with a 32-bit output) | ||
instead of SipHash's 128-bit key. However, this may appeal to some | ||
high-performance `jhash` users. | ||
|
||
Danger! | ||
|
||
Do not ever use HalfSipHash except for as a hashtable key function, and only | ||
then when you can be absolutely certain that the outputs will never be | ||
transmitted out of the kernel. This is only remotely useful over `jhash` as a | ||
means of mitigating hashtable flooding denial of service attacks. | ||
|
||
1. Generating a key | ||
|
||
Keys should always be generated from a cryptographically secure source of | ||
random numbers, either using get_random_bytes or get_random_once: | ||
|
||
hsiphash_key_t key; | ||
get_random_bytes(&key, sizeof(key)); | ||
|
||
If you're not deriving your key from here, you're doing it wrong. | ||
|
||
2. Using the functions | ||
|
||
There are two variants of the function, one that takes a list of integers, and | ||
one that takes a buffer: | ||
|
||
u32 hsiphash(const void *data, size_t len, const hsiphash_key_t *key); | ||
|
||
And: | ||
|
||
u32 hsiphash_1u32(u32, const hsiphash_key_t *key); | ||
u32 hsiphash_2u32(u32, u32, const hsiphash_key_t *key); | ||
u32 hsiphash_3u32(u32, u32, u32, const hsiphash_key_t *key); | ||
u32 hsiphash_4u32(u32, u32, u32, u32, const hsiphash_key_t *key); | ||
|
||
If you pass the generic hsiphash function something of a constant length, it | ||
will constant fold at compile-time and automatically choose one of the | ||
optimized functions. | ||
|
||
3. Hashtable key function usage: | ||
|
||
struct some_hashtable { | ||
DECLARE_HASHTABLE(hashtable, 8); | ||
hsiphash_key_t key; | ||
}; | ||
|
||
void init_hashtable(struct some_hashtable *table) | ||
{ | ||
get_random_bytes(&table->key, sizeof(table->key)); | ||
} | ||
|
||
static inline hlist_head *some_hashtable_bucket(struct some_hashtable *table, struct interesting_input *input) | ||
{ | ||
return &table->hashtable[hsiphash(input, sizeof(*input), &table->key) & (HASH_SIZE(table->hashtable) - 1)]; | ||
} | ||
|
||
You may then iterate like usual over the returned hash bucket. | ||
|
||
4. Performance | ||
|
||
HalfSipHash is roughly 3 times slower than JenkinsHash. For many replacements, | ||
this will not be a problem, as the hashtable lookup isn't the bottleneck. And | ||
in general, this is probably a good sacrifice to make for the security and DoS | ||
resistance of HalfSipHash. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,6 @@ | ||
VERSION = 4 | ||
PATCHLEVEL = 4 | ||
SUBLEVEL = 190 | ||
SUBLEVEL = 191 | ||
EXTRAVERSION = | ||
NAME = Blurry Fish Butt | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.