Re: [PATCH 1/4] HID: multitouch: fix Elan panels with 2 input modes declaration

> > This broke badly some recent Elan panels that now forget to send the > click button in some area of the touchpad. > > Fixes 7f81c8db5489 Please make sure that the 'Fixes:' tag is always in proper format. There are tools depending on that :) I'll fix that up manually. Thanks! -- Jiri Kosina SUSE Labs

RE: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

and 2/3 can be ignored / replaced by Casey's LSM stuff. Some form of 3/3 still should be merged independently on that. Thanks, -- Jiri Kosina SUSE Labs

RE: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

and 2/3 can be ignored / replaced by Casey's LSM stuff. Some form of 3/3 still should be merged independently on that. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

" idea, given how completely different in nature all the mitigations have been so far. I don't see that trying to abstract this somehow provides more clarity. So if this should be done in LSM, it'd probably have to be written by someone else than me :) who actually understands how the "sidechannel LSM" idea works. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

" idea, given how completely different in nature all the mitigations have been so far. I don't see that trying to abstract this somehow provides more clarity. So if this should be done in LSM, it'd probably have to be written by someone else than me :) who actually understands how the "sidechannel LSM" idea works. Thanks, -- Jiri Kosina SUSE Labs

[PATCH v3 3/3] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

From: Jiri Kosina STIBP is a feature provided by certain Intel ucodes / CPUs. This feature (once enabled) prevents cross-hyperthread control of decisions made by indirect branch predictors. Enable this feature if - the CPU is vulnerable to spectre v2 - the CPU supports SMT and has SMT

[PATCH v3 3/3] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

From: Jiri Kosina STIBP is a feature provided by certain Intel ucodes / CPUs. This feature (once enabled) prevents cross-hyperthread control of decisions made by indirect branch predictors. Enable this feature if - the CPU is vulnerable to spectre v2 - the CPU supports SMT and has SMT

[PATCH v3 2/3] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

From: Jiri Kosina Currently, we are issuing IBPB only in cases when switching into a non-dumpable process, the rationale being to protect such 'important and security sensitive' processess (such as GPG) from data leak into a different userspace process via spectre v2. This is however completely

[PATCH v3 2/3] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

From: Jiri Kosina Currently, we are issuing IBPB only in cases when switching into a non-dumpable process, the rationale being to protect such 'important and security sensitive' processess (such as GPG) from data leak into a different userspace process via spectre v2. This is however completely

[PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

From: Jiri Kosina Current ptrace_may_access() implementation assumes that the 'source' task is always the caller (current). Expose ___ptrace_may_access() that can be used to apply the check on arbitrary tasks. Originally-by: Tim Chen Signed-off-by: Jiri Kosina --- Sorry for the resend, my

[PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

From: Jiri Kosina Current ptrace_may_access() implementation assumes that the 'source' task is always the caller (current). Expose ___ptrace_may_access() that can be used to apply the check on arbitrary tasks. Originally-by: Tim Chen Signed-off-by: Jiri Kosina --- Sorry for the resend, my

[PATCH v3 3/3] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

From: Jiri Kosina STIBP is a feature provided by certain Intel ucodes / CPUs. This feature (once enabled) prevents cross-hyperthread control of decisions made by indirect branch predictors. Enable this feature if - the CPU is vulnerable to spectre v2 - the CPU supports SMT and has SMT

[PATCH v3 3/3] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

From: Jiri Kosina STIBP is a feature provided by certain Intel ucodes / CPUs. This feature (once enabled) prevents cross-hyperthread control of decisions made by indirect branch predictors. Enable this feature if - the CPU is vulnerable to spectre v2 - the CPU supports SMT and has SMT

[PATCH v3 2/3] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

From: Jiri Kosina Currently, we are issuing IBPB only in cases when switching into a non-dumpable process, the rationale being to protect such 'important and security sensitive' processess (such as GPG) from data leak into a different userspace process via spectre v2. This is however completely

[PATCH v3 2/3] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

From: Jiri Kosina Currently, we are issuing IBPB only in cases when switching into a non-dumpable process, the rationale being to protect such 'important and security sensitive' processess (such as GPG) from data leak into a different userspace process via spectre v2. This is however completely

[PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

From: Jiri Kosina Current ptrace_may_access() implementation assumes that the 'source' task is always the caller (current). Expose ___ptrace_may_access() that can be used to apply the check on arbitrary tasks. Originally-by: Tim Chen Signed-off-by: Jiri Kosina --- include/linux/ptrace.h

[PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

From: Jiri Kosina Current ptrace_may_access() implementation assumes that the 'source' task is always the caller (current). Expose ___ptrace_may_access() that can be used to apply the check on arbitrary tasks. Originally-by: Tim Chen Signed-off-by: Jiri Kosina --- include/linux/ptrace.h

[PATCH v3 0/3] Harden spectrev2 userspace-userspace protection

;v2: include IBPB changes v2->v3: fix IBPB 'who can trace who' semantics wire up STIBP flipping to SMT hotplug Jiri Kosina (3): ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks x86/speculation: Apply IBPB more strictly to avoid cross-process s

[PATCH v3 0/3] Harden spectrev2 userspace-userspace protection

;v2: include IBPB changes v2->v3: fix IBPB 'who can trace who' semantics wire up STIBP flipping to SMT hotplug Jiri Kosina (3): ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks x86/speculation: Apply IBPB more strictly to avoid cross-process s

Re: [PATCH v2 2/3] x86/speculation: Apply IBPB more strictly to avoid cross-process spectre v2 leak

ce @next, no? Good catch, it's the other way around, thanks. I'll wait for more review and send eventually v3 properly threaded (sorry for that as well ... not the best monday I've had today). -- Jiri Kosina SUSE Labs

Re: [PATCH v2 2/3] x86/speculation: Apply IBPB more strictly to avoid cross-process spectre v2 leak

ce @next, no? Good catch, it's the other way around, thanks. I'll wait for more review and send eventually v3 properly threaded (sorry for that as well ... not the best monday I've had today). -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: i2c-hid: enforce I2C_HID_QUIRK_RESEND_REPORT_DESCR

ght have found a better > solution. Simply not resetting the device after S3 might be the trick. Thanks for the heads up. In case that's the case, please also send a reference to the subsititute patch submission into this thread, so that archives to pick it up :) Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: i2c-hid: enforce I2C_HID_QUIRK_RESEND_REPORT_DESCR

ght have found a better > solution. Simply not resetting the device after S3 might be the trick. Thanks for the heads up. In case that's the case, please also send a reference to the subsititute patch submission into this thread, so that archives to pick it up :) Thanks, -- Jiri Kosina SUSE Labs

[PATCH v2 2/3] x86/speculation: Apply IBPB more strictly to avoid cross-process spectre v2 leak

From: Jiri Kosina Currently, we are issuing IBPB only in cases when switching into a non-dumpable process, the rationale being to protect such 'important and security sensitive' processess (such as GPG) from data leak into a different userspace process via spectre v2. This is however completely

[PATCH v2 3/3] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

From: Jiri Kosina STIBP is a feature provided by certain Intel ucodes / CPUs. This feature (once enabled) prevents cross-hyperthread control of decisions made by indirect branch predictors. Enable this feature if - the CPU is vulnerable to spectre v2 - the CPU supports SMT - spectre_v2

[PATCH v2 2/3] x86/speculation: Apply IBPB more strictly to avoid cross-process spectre v2 leak

From: Jiri Kosina Currently, we are issuing IBPB only in cases when switching into a non-dumpable process, the rationale being to protect such 'important and security sensitive' processess (such as GPG) from data leak into a different userspace process via spectre v2. This is however completely

[PATCH v2 3/3] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

From: Jiri Kosina STIBP is a feature provided by certain Intel ucodes / CPUs. This feature (once enabled) prevents cross-hyperthread control of decisions made by indirect branch predictors. Enable this feature if - the CPU is vulnerable to spectre v2 - the CPU supports SMT - spectre_v2

[PATCH v2 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

From: Jiri Kosina Current ptrace_may_access() implementation assumes that the 'source' task is always the caller (current). Expose ___ptrace_may_access() that can be used to apply the check on arbitrary tasks. Originally-by: Tim Chen Signed-off-by: Jiri Kosina --- include/linux/ptrace.h

[PATCH v2 0/3] Harden spectrev2 userspace-userspace protection

to today. Jiri Kosina (3): ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks x86/speculation: Apply IBPB more strictly to avoid cross-process spectre v2 leak x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation arch/x86/kernel/cpu

[PATCH v2 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

From: Jiri Kosina Current ptrace_may_access() implementation assumes that the 'source' task is always the caller (current). Expose ___ptrace_may_access() that can be used to apply the check on arbitrary tasks. Originally-by: Tim Chen Signed-off-by: Jiri Kosina --- include/linux/ptrace.h

[PATCH v2 0/3] Harden spectrev2 userspace-userspace protection

to today. Jiri Kosina (3): ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks x86/speculation: Apply IBPB more strictly to avoid cross-process spectre v2 leak x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation arch/x86/kernel/cpu

Re: [PATCH] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

On Fri, 31 Aug 2018, Jiri Kosina wrote: > From: Jiri Kosina > > STIBP is a feature provided by certain Intel ucodes / CPUs. This feature > (once enabled) prevents cross-hyperthread control of decisions made by > indirect branch predictors. > > Enable this feat

Re: [PATCH] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

On Fri, 31 Aug 2018, Jiri Kosina wrote: > From: Jiri Kosina > > STIBP is a feature provided by certain Intel ucodes / CPUs. This feature > (once enabled) prevents cross-hyperthread control of decisions made by > indirect branch predictors. > > Enable this feat

Re: Access to non-RAM pages

been hit by similar/related issue in practice, on x86 machines where GART aperture is being mapped over physical RAM. For the curious -- see commit 2a3e83c6f ("x86/gart: Exclude GART aperture from vmcore"). Thanks, -- Jiri Kosina SUSE Labs

Re: Access to non-RAM pages

been hit by similar/related issue in practice, on x86 machines where GART aperture is being mapped over physical RAM. For the curious -- see commit 2a3e83c6f ("x86/gart: Exclude GART aperture from vmcore"). Thanks, -- Jiri Kosina SUSE Labs

Re: Access to non-RAM pages

though. Thanks, -- Jiri Kosina SUSE Labs

Re: Access to non-RAM pages

though. Thanks, -- Jiri Kosina SUSE Labs

Re: Access to non-RAM pages

zation, as it's silently dangerous. Thanks, -- Jiri Kosina SUSE Labs

Re: Access to non-RAM pages

zation, as it's silently dangerous. Thanks, -- Jiri Kosina SUSE Labs

[PATCH] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

From: Jiri Kosina STIBP is a feature provided by certain Intel ucodes / CPUs. This feature (once enabled) prevents cross-hyperthread control of decisions made by indirect branch predictors. Enable this feature if - the CPU is vulnerable to spectre v2 - the CPU supports SMT - spectre_v2

[PATCH] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

From: Jiri Kosina STIBP is a feature provided by certain Intel ucodes / CPUs. This feature (once enabled) prevents cross-hyperthread control of decisions made by indirect branch predictors. Enable this feature if - the CPU is vulnerable to spectre v2 - the CPU supports SMT - spectre_v2

[tip:x86/urgent] x86/alternatives: Lockdep-enforce text_mutex in text_poke*()

Commit-ID: 9222f606506c5f8ca2c8b8c939d59ed3e6ac4148 Gitweb: https://git.kernel.org/tip/9222f606506c5f8ca2c8b8c939d59ed3e6ac4148 Author: Jiri Kosina AuthorDate: Tue, 28 Aug 2018 08:55:14 +0200 Committer: Thomas Gleixner CommitDate: Thu, 30 Aug 2018 13:02:30 +0200 x86/alternatives

[tip:x86/urgent] x86/alternatives: Lockdep-enforce text_mutex in text_poke*()

Commit-ID: 9222f606506c5f8ca2c8b8c939d59ed3e6ac4148 Gitweb: https://git.kernel.org/tip/9222f606506c5f8ca2c8b8c939d59ed3e6ac4148 Author: Jiri Kosina AuthorDate: Tue, 28 Aug 2018 08:55:14 +0200 Committer: Thomas Gleixner CommitDate: Thu, 30 Aug 2018 13:02:30 +0200 x86/alternatives

Re: [PATCH] HID: core: fix memory leak on probe

; [<1b053a89>] bus_for_each_drv+0x60/0xc0 > [<732716d8>] __device_attach+0xdc/0x144 > [] device_initial_probe+0x14/0x18 > [] bus_probe_device+0x90/0x98 > [] device_add+0x424/0x62c > [<46595a15>] hid_add_device+0x108/0x2b8 > [] usbhid_probe+0x2d4/0x3bc Also queued for 4.19. Thank you Stefan, -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: core: fix memory leak on probe

; [<1b053a89>] bus_for_each_drv+0x60/0xc0 > [<732716d8>] __device_attach+0xdc/0x144 > [] device_initial_probe+0x14/0x18 > [] bus_probe_device+0x90/0x98 > [] device_add+0x424/0x62c > [<46595a15>] hid_add_device+0x108/0x2b8 > [] usbhid_probe+0x2d4/0x3bc Also queued for 4.19. Thank you Stefan, -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: input: fix leaking custom input node name

1815,7 @@ void hidinput_disconnect(struct hid_device *hid) > input_unregister_device(hidinput->input); > else > input_free_device(hidinput->input); > + kfree(hidinput->name); > kfree(hidinput); Applied for 4.19, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: input: fix leaking custom input node name

1815,7 @@ void hidinput_disconnect(struct hid_device *hid) > input_unregister_device(hidinput->input); > else > input_free_device(hidinput->input); > + kfree(hidinput->name); > kfree(hidinput); Applied for 4.19, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] [v2] HID: add support for Apple Magic Keyboards

ric Keypad) > > Support already exists for the Magic Keyboard over USB connection. > Add support for the Magic Keyboard over Bluetooth connection, and for > the Magic Keyboard with Numeric Keypad over Bluetooth and USB > connection. > > Signed-off-by: Sean O'Brien Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] [v2] HID: add support for Apple Magic Keyboards

ric Keypad) > > Support already exists for the Magic Keyboard over USB connection. > Add support for the Magic Keyboard over Bluetooth connection, and for > the Magic Keyboard with Numeric Keypad over Bluetooth and USB > connection. > > Signed-off-by: Sean O'Brien Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: i2c-hid: Fix flooded incomplete report after S3 on Rayd touchscreen

report > (58/56059) > > Adding device ID, 04F3:30CC, to the quirk to re-send report description > after resume. > > Cc: sta...@vger.kernel.org > Signed-off-by: AceLan Kao Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: i2c-hid: Fix flooded incomplete report after S3 on Rayd touchscreen

report > (58/56059) > > Adding device ID, 04F3:30CC, to the quirk to re-send report description > after resume. > > Cc: sta...@vger.kernel.org > Signed-off-by: AceLan Kao Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: intel-ish-hid: Enable Sunrise Point-H ish driver

i_device_id ish_pci_tbl[] = { > {PCI_DEVICE(PCI_VENDOR_ID_INTEL, CNL_Ax_DEVICE_ID)}, > {PCI_DEVICE(PCI_VENDOR_ID_INTEL, GLK_Ax_DEVICE_ID)}, > {PCI_DEVICE(PCI_VENDOR_ID_INTEL, CNL_H_DEVICE_ID)}, > + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, SPT_H_DEVICE_ID)}, > {0, } Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: intel-ish-hid: Enable Sunrise Point-H ish driver

i_device_id ish_pci_tbl[] = { > {PCI_DEVICE(PCI_VENDOR_ID_INTEL, CNL_Ax_DEVICE_ID)}, > {PCI_DEVICE(PCI_VENDOR_ID_INTEL, GLK_Ax_DEVICE_ID)}, > {PCI_DEVICE(PCI_VENDOR_ID_INTEL, CNL_H_DEVICE_ID)}, > + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, SPT_H_DEVICE_ID)}, > {0, } Applied, thanks. -- Jiri Kosina SUSE Labs

[PATCH] x86/alternatives: lockdep-enforce text_mutex in text_poke*()

From: Jiri Kosina text_poke() and text_poke_bp() must be called with text_mutex held. Let's put proper lockdep anotation in place instead of just mentioning the requirement in comment. Reported-by: Peter Zijlstra Signed-off-by: Jiri Kosina --- arch/x86/kernel/alternative.c | 9 + 1

[PATCH] x86/alternatives: lockdep-enforce text_mutex in text_poke*()

From: Jiri Kosina text_poke() and text_poke_bp() must be called with text_mutex held. Let's put proper lockdep anotation in place instead of just mentioning the requirement in comment. Reported-by: Peter Zijlstra Signed-off-by: Jiri Kosina --- arch/x86/kernel/alternative.c | 9 + 1

[GIT PULL] livepatching

): livepatch: Remove reliable stacktrace check in klp_try_switch_task() livepatch: Validate module/old func name length kernel/livepatch/core.c | 6 ++ kernel/livepatch/transition.c | 7 --- 2 files changed, 6 insertions(+), 7 deletions(-) -- Jiri Kosina SUSE Labs

[GIT PULL] livepatching

): livepatch: Remove reliable stacktrace check in klp_try_switch_task() livepatch: Validate module/old func name length kernel/livepatch/core.c | 6 ++ kernel/livepatch/transition.c | 7 --- 2 files changed, 6 insertions(+), 7 deletions(-) -- Jiri Kosina SUSE Labs

[GIT PULL] HID

ged, 1824 insertions(+), 748 deletions(-) create mode 100644 drivers/hid/hid-cougar.c -- Jiri Kosina SUSE Labs

[GIT PULL] HID

ged, 1824 insertions(+), 748 deletions(-) create mode 100644 drivers/hid/hid-cougar.c -- Jiri Kosina SUSE Labs

Re: [PATCH v2] HID: intel_ish-hid: tx_buf memory leak on probe/remove

Vasilyev > Acked-by: Srinivas Pandruvada > --- > v2: Fix align for multi line statements Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH v2] HID: intel_ish-hid: tx_buf memory leak on probe/remove

Vasilyev > Acked-by: Srinivas Pandruvada > --- > v2: Fix align for multi line statements Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH v2] HID: intel-ish-hid: Prevent loading of driver on Mehlow

: Srinivas Pandruvada > --- > v2 > Replaced pci_get_device with pci_dev_present to check in a loop as > suggested by Benjamin. Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH v2] HID: intel-ish-hid: Prevent loading of driver on Mehlow

: Srinivas Pandruvada > --- > v2 > Replaced pci_get_device with pci_dev_present to check in a loop as > suggested by Benjamin. Applied, thanks. -- Jiri Kosina SUSE Labs

[tip:x86/pti] x86/speculation: Protect against userspace-userspace spectreRSB

Commit-ID: fdf82a7856b32d905c39afc85e34364491e46346 Gitweb: https://git.kernel.org/tip/fdf82a7856b32d905c39afc85e34364491e46346 Author: Jiri Kosina AuthorDate: Thu, 26 Jul 2018 13:14:55 +0200 Committer: Thomas Gleixner CommitDate: Tue, 31 Jul 2018 00:45:15 +0200 x86/speculation

[tip:x86/pti] x86/speculation: Protect against userspace-userspace spectreRSB

Commit-ID: fdf82a7856b32d905c39afc85e34364491e46346 Gitweb: https://git.kernel.org/tip/fdf82a7856b32d905c39afc85e34364491e46346 Author: Jiri Kosina AuthorDate: Thu, 26 Jul 2018 13:14:55 +0200 Committer: Thomas Gleixner CommitDate: Tue, 31 Jul 2018 00:45:15 +0200 x86/speculation

Re: cpu_no_speculation omissions?

ores are in order. When I did the original > list I didn't bother with all the 32bit cores as we didn't have any > 32bit mitigations then. Now that 32bit PTI is in tip, I believe refresh of that list would be justified. CCing Joerg. -- Jiri Kosina SUSE Labs

Re: cpu_no_speculation omissions?

ores are in order. When I did the original > list I didn't bother with all the 32bit cores as we didn't have any > 32bit mitigations then. Now that 32bit PTI is in tip, I believe refresh of that list would be justified. CCing Joerg. -- Jiri Kosina SUSE Labs

[PATCH v2] x86/bugs: protect against userspace-userspace spectreRSB

From: Jiri Kosina The article "Spectre Returns! Speculation Attacks using the Return Stack Buffer" [1] describes two new (sub-)variants of spectrev2-like attack, making use solely of the RSB contents even on CPUs that don't fallback to BTB on RSB underflow (Skylake+). Mitigate

[PATCH v2] x86/bugs: protect against userspace-userspace spectreRSB

From: Jiri Kosina The article "Spectre Returns! Speculation Attacks using the Return Stack Buffer" [1] describes two new (sub-)variants of spectrev2-like attack, making use solely of the RSB contents even on CPUs that don't fallback to BTB on RSB underflow (Skylake+). Mitigate

Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

STIBP is plugging much smaller hole than spectreRSB (as the bigger part is already plugged by IBPB), so I'd rather have that one in first, and look at improving STIBP later if noone beats me to it. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

STIBP is plugging much smaller hole than spectreRSB (as the bigger part is already plugged by IBPB), so I'd rather have that one in first, and look at improving STIBP later if noone beats me to it. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

to > > BTB on RSB underflow (Skylake+). > > > > Mitigate userspace-userspace attacks by always unconditionally filling RSB > > on > > context switch when generic spectrev2 mitigation has been enabled. > > > > [1] https://arxiv.org/pdf/1807.07940

Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

to > > BTB on RSB underflow (Skylake+). > > > > Mitigate userspace-userspace attacks by always unconditionally filling RSB > > on > > context switch when generic spectrev2 mitigation has been enabled. > > > > [1] https://arxiv.org/pdf/1807.07940

[PATCH] x86/bugs: protect against userspace-userspace spectreRSB

From: Jiri Kosina The article "Spectre Returns! Speculation Attacks using the Return Stack Buffer" [1] describes two new (sub-)variants of spectrev2-like attack, making use solely of the RSB contents even on CPUs that don't fallback to BTB on RSB underflow (Skylake+). Mitigate

[PATCH] x86/bugs: protect against userspace-userspace spectreRSB

From: Jiri Kosina The article "Spectre Returns! Speculation Attacks using the Return Stack Buffer" [1] describes two new (sub-)variants of spectrev2-like attack, making use solely of the RSB contents even on CPUs that don't fallback to BTB on RSB underflow (Skylake+). Mitigate

Re: [PATCH] livepatch: Validate module/old func name length

comparing them against a nonexisting function, > which can be avoided. > > The same issues apply, to misspelled/incorrect names. At least gatekeep > the modules with over the limit string length, by checking for their > length during livepatch module registration. > > Signed-off

Re: [PATCH] livepatch: Validate module/old func name length

comparing them against a nonexisting function, > which can be avoided. > > The same issues apply, to misspelled/incorrect names. At least gatekeep > the modules with over the limit string length, by checking for their > length during livepatch module registration. > > Signed-off

Re: [PATCH v4 00/12] Hid multitouch rewrite, support os system multi-axis devices, take 4

On Fri, 13 Jul 2018, Benjamin Tissoires wrote: > this is the v4 of my hid-multitouch rewrite series. Nice work, thanks a lot. Applied, -- Jiri Kosina SUSE Labs

Re: [PATCH v4 00/12] Hid multitouch rewrite, support os system multi-axis devices, take 4

On Fri, 13 Jul 2018, Benjamin Tissoires wrote: > this is the v4 of my hid-multitouch rewrite series. Nice work, thanks a lot. Applied, -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: roccat: Mark expected switch fall-through

ctual_profile = event->value; > break; I *think* the fall-through is correct thing to do here, but I'd like to get explicit Ack from Stefan. Stefan, please? -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: roccat: Mark expected switch fall-through

ctual_profile = event->value; > break; I *think* the fall-through is correct thing to do here, but I'd like to get explicit Ack from Stefan. Stefan, please? -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: intel-ish-hid: remove redundant variable num_frags

able] > > Signed-off-by: Colin Ian King Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: intel-ish-hid: remove redundant variable num_frags

able] > > Signed-off-by: Colin Ian King Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] Patch enabling Fn function keys for Laptop Asus G730 (keyboard 0x1869)

uld contain. Could you point me to a correct > guide for this ? Please read Documentation/process/submitting-patches.rst signoffs specifically are discussed in paragraph 11. Thanks! -- Jiri Kosina SUSE Labs

Re: [PATCH] Patch enabling Fn function keys for Laptop Asus G730 (keyboard 0x1869)

uld contain. Could you point me to a correct > guide for this ? Please read Documentation/process/submitting-patches.rst signoffs specifically are discussed in paragraph 11. Thanks! -- Jiri Kosina SUSE Labs

Re: [PATCH] livepatch: Remove reliable stacktrace check in klp_try_switch_task()

in klp_try_switch_task(), > as its not required. > > Signed-off-by: Kamalesh Babulal Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] livepatch: Remove reliable stacktrace check in klp_try_switch_task()

in klp_try_switch_task(), > as its not required. > > Signed-off-by: Kamalesh Babulal Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH 00/39 v7] PTI support for x86-32

and some issues have been identified since then because of that). So it (or its port to 3.0, to be more precise :p) already did receive some crowd-testing. -- Jiri Kosina SUSE Labs

Re: [PATCH 00/39 v7] PTI support for x86-32

and some issues have been identified since then because of that). So it (or its port to 3.0, to be more precise :p) already did receive some crowd-testing. -- Jiri Kosina SUSE Labs

[GIT PULL] HID fixes

- 6 files changed, 33 insertions(+), 6 deletions(-) -- Jiri Kosina SUSE Labs

[GIT PULL] HID fixes

- 6 files changed, 33 insertions(+), 6 deletions(-) -- Jiri Kosina SUSE Labs

Re: [PATCH] i2c-hid: Fix "incomplete report" noise

] i2c_hid i2c-ALP0017:00: i2c_hid_get_input: incomplete report > (30/2) > > Only print the message when ret_size is totally invalid and less than 2 > to cut down on the log spam. > > Reported-by: John Smith > Cc: sta...@vger.kernel.org > Signed-off-by: Jason Andryuk Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] i2c-hid: Fix "incomplete report" noise

] i2c_hid i2c-ALP0017:00: i2c_hid_get_input: incomplete report > (30/2) > > Only print the message when ret_size is totally invalid and less than 2 > to cut down on the log spam. > > Reported-by: John Smith > Cc: sta...@vger.kernel.org > Signed-off-by: Jason Andryuk Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: debug: check length before copy_to_user()

n Tissoires Indeed, thanks a lot for fixing this. Now queued, I'll push it for 4.18. -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: debug: check length before copy_to_user()

n Tissoires Indeed, thanks a lot for fixing this. Now queued, I'll push it for 4.18. -- Jiri Kosina SUSE Labs

Re: [PATCH] printk: remove unnecessary kmalloc() from syslog during clear

uplicate the check kfree() is doing anyway. -- Jiri Kosina SUSE Labs

Re: [PATCH] printk: remove unnecessary kmalloc() from syslog during clear

uplicate the check kfree() is doing anyway. -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: core: allow concurrent registration of drivers

c17a7476e4c4 ("HID: core: rewrite the hid-generic automatic unbind") > > Cc: sta...@vger.kernel.org # v4.17 > Signed-off-by: Benjamin Tissoires Now staged in for-4.18/upstream-fixes_v2, with the plan to send it to Linus this week. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: core: allow concurrent registration of drivers

c17a7476e4c4 ("HID: core: rewrite the hid-generic automatic unbind") > > Cc: sta...@vger.kernel.org # v4.17 > Signed-off-by: Benjamin Tissoires Now staged in for-4.18/upstream-fixes_v2, with the plan to send it to Linus this week. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: redragon: fix num lock and caps lock LEDs

5455dd906d. I have fixed that, added Fixes: tag, and applied. -- Jiri Kosina SUSE Labs

<    3   4   5   6   7   8   9   10   11   12   >