Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode

2018-12-04 Thread Jiri Kosina
Intel > HW architects. This should also help answer some of the questions > from Thomas and others on STIBP's usages with IBPB and IBRS. Thanks a lot, this indeed does shed some light. I have one question though: [ ... snip ... ] > On processors with enhanced IBRS support, we recommend

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-30 Thread Jiri Kosina
(0xb2). > For all I know, the SMI handler will explode and the computer will catch > fire. Ha, therefore noone can't claim any more that SMIs are always harmful :) -- Jiri Kosina SUSE Labs

Re: [PATCH RFC 14/15] lib: replace **** with a hug

2018-11-30 Thread Jiri Kosina
gt; > For both patches, actually, I'd much rather see either deletion or a > rewrite over bleeping out words that somebody might not like. Exactly. Turning comments into something that often doesn't make sense to anybody at all is hardly productive. -- Jiri Kosina SUSE Labs

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Jiri Kosina
when I was preparing the original text_poke_bp() implementation, hpa had to provide some answers directly from inner depths of Intel ... see fd4363fff3 ("x86: Introduce int3 (breakpoint)-based instruction patching") for reference. -- Jiri Kosina SUSE Labs

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Jiri Kosina
ist any strong reasons for why it should NOT be an IST. It's CVE-2018-8897. -- Jiri Kosina SUSE Labs

Re: [patch 20/24] x86/speculation: Split out TIF update

2018-11-27 Thread Jiri Kosina
et the TIF_UPDATE > bit which is evaluated once. Yeah, that was a complete brainfart on my side, sorry for the noise, disregard that crap. I blame it all on the dentist appointment I went through before writing the patch :p Thanks, -- Jiri Kosina SUSE Labs

Re: [patch 20/24] x86/speculation: Split out TIF update

2018-11-27 Thread Jiri Kosina
On Tue, 27 Nov 2018, Jiri Kosina wrote: > > > static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl) > > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > > index 3f5e351bdd37..6c4fcef52b19 100644 > > > --- a/arch/x86/k

Re: [patch 20/24] x86/speculation: Split out TIF update

2018-11-27 Thread Jiri Kosina
t; next context switch? Does it really have to? We need this special handling only if the next task has TIF_SPEC_UPDATE set, which is one-off event globally (when seccomp marks all its threads so due to seccomp filter change), and once all the TIF_SPEC_UPDATE tasks schedule at least once, we're in a consistent state again and don't need this, as every running task will then have its TIF consistent with MSR value. Thanks, -- Jiri Kosina SUSE Labs

Re: [patch 20/24] x86/speculation: Split out TIF update

2018-11-27 Thread Jiri Kosina
On Tue, 27 Nov 2018, Jiri Kosina wrote: > --- a/arch/x86/kernel/process.c > +++ b/arch/x86/kernel/process.c > @@ -474,6 +474,21 @@ void __switch_to_xtra(struct task_struct *prev_p, struct > task_struct *next_p) > > tifn = READ_ONCE(task_thread_info(next_p)->

Re: [patch 20/24] x86/speculation: Split out TIF update

2018-11-27 Thread Jiri Kosina
On Tue, 27 Nov 2018, Jiri Kosina wrote: > > That's racy and does not prevent the situation because the TIF flags are > > updated befor the UPDATE bit is set. > > > So __speculation_ctrl_update() might see the new bits, but not > > TIF_SPEC_UPDATE. > > Hm, rig

Re: [patch 20/24] x86/speculation: Split out TIF update

2018-11-26 Thread Jiri Kosina
d need to do that before updating TIF_SPEC_IB in task_update_spec_tif(), but that has the opposite ordering issue. Thanks, -- Jiri Kosina SUSE Labs

Re: [patch 20/24] x86/speculation: Split out TIF update

2018-11-26 Thread Jiri Kosina
e. How about the minimalistic aproach below? (only compile tested so far, applies on top of your latest WIP.x86/pti branch). The downside of course is wasting another TIF bit. Thanks. From: Jiri Kosina Subject: [PATCH] x86/speculation: Always properly update SPEC_CTRL MSR for remote seccomp

Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode

2018-11-25 Thread Jiri Kosina
ding). Arjan, Tim, would you have a wording handy that would be guaranteed to describe the reality for the sake of changelog? Thanks, -- Jiri Kosina SUSE Labs

[GIT PULL] HID fixes

2018-11-24 Thread Jiri Kosina
id.c | 25 ++- include/linux/hid.h| 28 --- include/uapi/linux/input-event-codes.h | 10 -- 11 files changed, 159 insertions(+), 444 deletions(-) -- Jiri Kosina SUSE Labs

Re: [patch 21/24] x86/speculation: Prepare arch_smt_update() for PRCTL mode

2018-11-22 Thread Jiri Kosina
ed to the actual IBRS runtime operation effect. -- Jiri Kosina SUSE Labs

Re: [patch 17/24] x86/speculation: Move IBPB control out of switch_mm()

2018-11-21 Thread Jiri Kosina
+seccomp setup (irrespective of it's TIF flag value), as you have the extra overhead on each and every switch_to() (to check exactly for this back-to-back scheduling), or you penalize only those tasks that are penalized anyway by the IBPB flush. I think the latter (which is what this patch implements) makes more sense. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] x86/speculation: Revert turning on STIBP all the time

2018-11-21 Thread Jiri Kosina
e; > + return false; > } For -stable, which actually makes it to production, I already asked Greg to drop it. For -rc, I don't think we need to do this at this moment, given the prctl+seccomp fixup is basically ready, do we? Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH 0/7] HID: revert the Logitech High Resolution wheel support

2018-11-21 Thread Jiri Kosina
e for-linus branch. As discussed previously Acked-by: Jiri Kosina Thanks, -- Jiri Kosina SUSE Labs

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

2018-11-21 Thread Jiri Kosina
ull off. > > So till we have the accompanying patchset that only apply STIBP on processes > that really need it instead of universally, it should be withheld from > stable. Agreed; it will be trivially reintroduced with the rest, once it's ready. It's being built on top of that patch. Thanks, -- Jiri Kosina SUSE Labs

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

2018-11-21 Thread Jiri Kosina
On Sun, 11 Nov 2018, Greg Kroah-Hartman wrote: > 4.19-stable review patch. If anyone has any objections, please let me know. Greg, please drop this patch from all -stable for now. Version that wouldn't have such performance impact is being worked on. -- Jiri Kosina SUSE Labs

Re: [Patch v6 14/16] x86/speculation: Use STIBP to restrict speculation on non-dumpable task

2018-11-20 Thread Jiri Kosina
accept 'prctl' as the default mode. Namely: - the whole "proper gadgets need to be present in the process' .text" is dubious by itself - the unavoidable overhead it'd impose on network daemons that you can't really get rid of The distiled patchset that Thomas will be sending around today is not have the dumpability restriction in it. Thanks, -- Jiri Kosina SUSE Labs

Re: [Patch v6 12/16] x86/speculation: Add 'seccomp' Spectre v2 app to app protection mode

2018-11-20 Thread Jiri Kosina
k. > + seccomp - Same as "prctl" above, but all seccomp threads > + will disable SSB unless they explicitly opt > out. As Dave already pointed out elsewhere -- the "SSB" here is probably a copy/paste error. It should read something along the lines of "... will restrict indirect branch speculation ..." Thanks, -- Jiri Kosina SUSE Labs

Re: Re: STIBP by default.. Revert?

2018-11-20 Thread Jiri Kosina
/security-software-guidance/api-app/sites/default/files/336996-Speculative-Execution-Side-Channel-Mitigations.pdf?_gclid=5b78f4d130faf8.22277271-5b78f4d130fb70.17467890&_utm_source=xakep&_utm_campaign=mention17&_utm_medium=inline&_utm_content=lnk223716354570 Thanks, -- Jiri Kosina SUSE Labs

Re: STIBP by default.. Revert?

2018-11-20 Thread Jiri Kosina
Tim's set into mergeable state, I've just sent him small addition on top that makes IBPB also be controlled via the same toggle. That should make the whole 'spectre v2 userspace-to-userspace' mitigation control consistent and undestandable. And also give us even few more % back that are lost due to IBPB as well. -- Jiri Kosina SUSE Labs

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

2018-11-19 Thread Jiri Kosina
noid enough to ask for IBPB, > *and* they have SMT, they almost certainly want STIBP too. I think you are not lost :) and this is exactly what makes sense, and what Tim's patchset implements. -- Jiri Kosina SUSE Labs

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

2018-11-19 Thread Jiri Kosina
On Tue, 20 Nov 2018, Thomas Gleixner wrote: > What? IBPB makes tons of sense even without STIBP. On non-SMT, yes. But this patchset ties those two the other (sensible) way around AFAICS ("STIBP iff (IBPB && SMT)"). -- Jiri Kosina SUSE Labs

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

2018-11-19 Thread Jiri Kosina
her IBPB and STIBP pretty closely, which is IMO a good thing; there is no good reason why anone would want just one of those (or each in a different mode), at least before this magical coscheduling exists. But I guess this fact should be documented somewhere. -- Jiri Kosina SUSE Labs

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

2018-11-19 Thread Jiri Kosina
forcing > these decision at boot time only. Would be nice to add runtime tweak > options for at least STIBP and SSBD that aren't confined to the prctl. So if I understand you correctly, what you are proposing here is to keep the current code, but just switch the default, and make it runtime/boottime togglable? Thanks, -- Jiri Kosina SUSE Labs

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

2018-11-19 Thread Jiri Kosina
gt; That was my initial thought too. Ingo suggested to export it in > review of v2. Wonder Ingo has some reason? > > https://lore.kernel.org/patchwork/patch/991759/ But why does it have to be exported at all, irrespective whether _GPL() or not? Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: i2c-hid: Disable runtime PM for LG touchscreen

2018-11-19 Thread Jiri Kosina
I2C_HID_QUIRK_DELAY_AFTER_SLEEP }, > + { USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_8001, > + I2C_HID_QUIRK_NO_RUNTIME_PM }, > { 0, 0 } > }; Applied. -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: multitouch: Add pointstick support for Cirque Touchpad

2018-11-19 Thread Jiri Kosina
IN_8, > + I2C_VENDOR_ID_CIRQUE, > + I2C_PRODUCT_ID_CIRQUE_121F) }, > + > /* CJTouch panels */ > { .driver_data = MT_CLS_NSMU, > MT_USB_DEVICE(USB_VENDOR_ID_CJTOUCH, Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: steam: remove input device when a hid client is running.

2018-11-19 Thread Jiri Kosina
https://github.com/ValveSoftware/steam-for-linux/issues/5645 Applied to for-4.20/upstream-fixes. Thanks, -- Jiri Kosina SUSE Labs

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

2018-11-19 Thread Jiri Kosina
ther mail. Actually Tim's patchset seems to already deal with IBPB in a consistent way as well in [11/16] x86/speculation: Add Spectre v2 app to app protection modes but the fact that it's still using TIF_STIBP makes it a bit confusing and hidden. So I'd suggest to fold something like

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

2018-11-19 Thread Jiri Kosina
On Mon, 19 Nov 2018, Thomas Gleixner wrote: > > On Sat, 17 Nov 2018, Jiri Kosina wrote: > > > Subject: [PATCH] x86/speculation: enforce STIBP for SECCOMP tasks in lite > > mode > > > > If 'lite' mode of app2app protection from spectre_v2 is selected on > >

Re: [PATCH] l1tf: drop the swap storage limit restriction when l1tf=off

2018-11-19 Thread Jiri Kosina
n both > hypervisor and bare metal. > > Sounds better? > > > With that > > > > Acked-by: Jiri Kosina > > Thanks! Yes, I think that makes it absolutely clear. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] Revert "HID: uhid: use strlcpy() instead of strncpy()"

2018-11-19 Thread Jiri Kosina
strncpy(hid->phys, ev->u.create2.phys, len); > + len = min(sizeof(hid->uniq), sizeof(ev->u.create2.uniq)) - 1; > + strncpy(hid->uniq, ev->u.create2.uniq, len); Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH v2] HID: uhid: forbid UHID_CREATE under KERNEL_DS or elevated privileges

2018-11-19 Thread Jiri Kosina
overlooked that (valid) concern in the thread. Thanks for spotting that, Andy. I've now applied Eric's patch. Thanks everybody, -- Jiri Kosina SUSE Labs

Re: [PATCH v2] HID: uhid: forbid UHID_CREATE under KERNEL_DS or elevated privileges

2018-11-19 Thread Jiri Kosina
t;private_data; @@ -771,6 +780,7 @@ static const struct file_operations uhid_fops = { .release= uhid_char_release, .read = uhid_char_read, .write = uhid_char_write, + .splice_write = uhid_char_splice_write, .poll = uhid_char_poll, .llseek = no_llseek, }; -- Jiri Kosina SUSE Labs

Re: STIBP by default.. Revert?

2018-11-19 Thread Jiri Kosina
so it's going to be explicit an > explicit requirement. Do you already have an idea whether you'd proceed with Tim's patchset for current cycle? If so, great as far as I am concerned. If not, I'll send a patch that switches this to opt-in via kernel cmdline (+boot-time warning if not mitigated). Thanks, -- Jiri Kosina SUSE Labs

Re: STIBP by default.. Revert?

2018-11-18 Thread Jiri Kosina
On Sun, 18 Nov 2018, Jiri Kosina wrote: > It's probably not just browsers, but anything running JITed sandboxed > code. So the most straightforward way might be the prctl() aproach, where > userspace would claim "I do care about this, please fix it up for me". So > prc

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

2018-11-18 Thread Jiri Kosina
On Sat, 17 Nov 2018, Jiri Kosina wrote: > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > > b/Documentation/admin-guide/kernel-parameters.txt > > index 81d1d5a..9c306e3 100644 > > --- a/Documentation/admin-guide/kernel-parameters.txt > > +++ b/Do

Re: STIBP by default.. Revert?

2018-11-18 Thread Jiri Kosina
e consistent (and get even a few more % of performance back), but that's easy as well. Thanks, -- Jiri Kosina SUSE Labs

Re: STIBP by default.. Revert?

2018-11-18 Thread Jiri Kosina
than turning SMT off, which might possibly have even *worse* performance numbers depending on workload. [1] https://lore.kernel.org/lkml/?q=cover.1542418936.git.tim.c.chen%40linux.intel.com (*) no code to implement STIBP sanely, no recommendation about turning SMT off at least for some workloads Thanks, -- Jiri Kosina SUSE Labs

Re: [Patch v5 12/16] x86/speculation: Create PRCTL interface to restrict indirect branch speculation

2018-11-17 Thread Jiri Kosina
uot;indirect branch predictions" in general terms, but really controls only the SMT aspect of it (STIBP), as quite confusing. So I believe it should either be renamed, or actually control semantics of IBPB as well, no? Thanks, -- Jiri Kosina SUSE Labs

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

2018-11-17 Thread Jiri Kosina
indirect branch speculation via the > + PR_SET_SPECULATION_CTRL prctl(). Don't we also want to do the same for SECCOMP processess, analogically how we do it for SSBD? Thanks, -- Jiri Kosina SUSE Labs

Re: [Patch v5 00/16] Provide task property based options to enable Spectre v2 userspace-userspace protection

2018-11-17 Thread Jiri Kosina
t some of the lost performance back (I am pretty sure it will be taken for all -stable branches as well anyway). Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] l1tf: drop the swap storage limit restriction when l1tf=off

2018-11-13 Thread Jiri Kosina
o avoid any confusion (as otherwise the l1tf cmdline parameter is purely about hypervisor mitigations). With that Acked-by: Jiri Kosina Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: hidraw: enforce minors_lock locking via lockdep

2018-11-12 Thread Jiri Kosina
On Fri, 9 Nov 2018, Benjamin Tissoires wrote: > On Thu, Nov 8, 2018 at 10:38 PM Jiri Kosina wrote: > > > > From: Jiri Kosina > > > > lockdep is much more powerful enforcing the locking rules than code > > comments, > > so let's switch to

Re: [PATCH v4 01/10] Fix "x86/alternatives: Lockdep-enforce text_mutex in text_poke*()"

2018-11-12 Thread Jiri Kosina
emoved. For kgdb, the return > > value can actually be used. > > Hm, this looks reasonable and good to me. > > Reviewed-by: Masami Hiramatsu Yes, I guess this is much better than putting the 'enforcement by comment' back in place :) Acked-by: Jiri Kosina Thanks. -- Jiri Kosina SUSE Labs

[PATCH] HID: hidraw: enforce minors_lock locking via lockdep

2018-11-08 Thread Jiri Kosina
From: Jiri Kosina lockdep is much more powerful enforcing the locking rules than code comments, so let's switch to it. Signed-off-by: Jiri Kosina --- drivers/hid/hidraw.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c

[GIT PULL] HID fixes

2018-11-07 Thread Jiri Kosina
wiht CONFIG_ASUS_WMI disabled Benjamin Tissoires (2): Revert "HID: add NOGET quirk for Eaton Ellipse MAX UPS" HID: alps: allow incoming reports when only the trackstick is opened Breno Leitao (1): HID: hiddev: fix potential Spectre v1 Jiri Kosina (1): HID: movin

Re: [PATCH] HID: asus: fix build warning wiht CONFIG_ASUS_WMI disabled

2018-11-06 Thread Jiri Kosina
by WMI") > Signed-off-by: Arnd Bergmann Applied to for-4.20/upstream-fixes. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH v3 1/7] Fix "x86/alternatives: Lockdep-enforce text_mutex in text_poke*()"

2018-11-03 Thread Jiri Kosina
mmit. > > This partially reverts commit 9222f606506c ("x86/alternatives: > Lockdep-enforce text_mutex in text_poke*()") Alright, what can we do. It's probably better to have this, rather than to trying to work this around in kgdb to accomodate the rest of the world. > Cc: Jiri Kos

Re: [PATCH v4 1/3] arm64: implement ftrace with regs

2018-10-31 Thread Jiri Kosina
we use '-pg -mfentry', to make sure we hook the function *before* prologue. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH v2] HID: moving to group maintainership model

2018-10-29 Thread Jiri Kosina
On Mon, 29 Oct 2018, Benjamin Tissoires wrote: > > From: Jiri Kosina > > Date: Sat, 27 Oct 2018 14:16:13 +0200 > > Subject: [PATCH] HID: moving to group maintainership model > > > > Benjamin and myself will from now on be sharing maintainership > > responsi

Re: Logitech high-resolution scrolling..

2018-10-29 Thread Jiri Kosina
indicated that Peter probably has found the issue in the code (failure to properly reset on direction change) that might be causing this. Adding to CC. Peter? Thanks, -- Jiri Kosina SUSE Labs

Re: [Ksummit-discuss] The linux devs can rescind their license grant.

2018-10-27 Thread Jiri Kosina
ieve is a very noble and nice goal. But you really have to know at least a little bit who's there on the other end. Otherwise failure to communicate might be sort of inevitable. -- Jiri Kosina SUSE Labs

Re: Another HID problem this merge window..

2018-10-27 Thread Jiri Kosina
tely escaped attention. That should never ever have been set to default y, I take blame for not noticing that while applying the patch. Thanks, -- Jiri Kosina SUSE Labs

Re: Oops in current tree in i2c

2018-10-27 Thread Jiri Kosina
improve I guess; will fix that next week. Benjamin, do you have something for that in place already? Thanks, -- Jiri Kosina SUSE Labs

[PATCH v2] HID: moving to group maintainership model

2018-10-27 Thread Jiri Kosina
From: Jiri Kosina Date: Sat, 27 Oct 2018 14:16:13 +0200 Subject: [PATCH] HID: moving to group maintainership model Benjamin and myself will from now on be sharing maintainership responsibilities for hid.git. Update maintainers to reflect that change, and also move a git repository to shared

[PATCH] HID: moving to group maintainership model

2018-10-27 Thread Jiri Kosina
From: Jiri Kosina Benjamin and myself will from now on be sharing maintainership responsibilities for hid.git. Update maintainers to reflect that change, and also move a git repository to shared space at kernel.org. Signed-off-by: Jiri Kosina --- Stephen, could you please update

Re: [PATCH] HID: alps: allow incoming reports when only the trackstick is opened

2018-10-26 Thread Jiri Kosina
; while keeping the trackstick active. > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1559632 > Link: https://gitlab.gnome.org/GNOME/mutter/issues/128 > Signed-off-by: Benjamin Tissoires Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH 0/3] HID: debug: fix the ring buffer implementation

2018-10-26 Thread Jiri Kosina
modified kernel and fuzzer-reader > at: https://gist.github.com/nefigtut/33d56e3870b67493cc867344aed2a062 Vladis, thanks for cleaning it up. I actually like your rewrite quite a lot. Quick question -- how well was it tested in which scenarios? -- Jiri Kosina SUSE Labs

Re: [PATCH] Revert "HID: add NOGET quirk for Eaton Ellipse MAX UPS"

2018-10-26 Thread Jiri Kosina
> Reported-by: Laurent Bigonville > Signed-off-by: Benjamin Tissoires Ok, fingers crossed. Applied, -- Jiri Kosina SUSE Labs

Re: [PATCH v2] HID: i2c-hid: Add a small delay after sleep command for Raydium touchpanel

2018-10-26 Thread Jiri Kosina
; timeframe. So add a small delay to workaround the issue. > > Signed-off-by: Kai-Heng Feng > --- > v2: > - Use quirk to only match affected touchpanel > - Only delay the next power on if the time hasn't elapsed Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH AUTOSEL 4.4 08/65] btrfs: cleaner_kthread() doesn't need explicit freeze

2018-10-26 Thread Jiri Kosina
extent pages), so there is no need to leave any traces of > >> freezer in this kthread. > >> > >> Fixes: 80ad623edd2d ("Revert "btrfs: clear PF_NOFREEZE in > >> Fixes: cleaner_kthread()") > >> Fixes: 696249132158 ("btrfs: clear PF_NOFREEZE in cle

Re: Is Fixes line enough?

2018-10-23 Thread Jiri Kosina
new PCI/USB/ACPI IDs or DMI quirks are usually accepted > into stable but normally lack "Fixes" tag. That could easily be made an easily identifiable exception to the rule though. -- Jiri Kosina SUSE Labs

[GIT PULL] HID for 4.20

2018-10-23 Thread Jiri Kosina
ble high-resolution scrolling on Logitech mice HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice Hong Liu (2): HID: intel-ish-hid: use resource-managed api HID: intel-ish-hid: using list_head for ipc write queue Jason Gerecke (1): HID: wacom: Work around HID descripto

Re: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

2018-10-21 Thread Jiri Kosina
hat's currently being discussed) is eventually going to achieve. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: usbhid: Add quirk for Redragon/Dragonrise Seymur 2

2018-10-11 Thread Jiri Kosina
sue. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200995 > BugLink: https://bugs.launchpad.net/bugs/1793846 > Signed-off-by: Kai-Heng Feng Applied, thanks. -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: elan: fix spelling mistake "registred" -> "registered"

2018-10-09 Thread Jiri Kosina
return 0; > > if (!drvdata->input) { > - hid_err(hdev, "Input device is not registred\n"); > + hid_err(hdev, "Input device is not registered\n"); Applied, thanks. -- Jiri Kosina SUSE Labs

[PATCH] HID: google: drop superfluous const before SIMPLE_DEV_PM_OPS()

2018-10-09 Thread Jiri Kosina
From: Jiri Kosina SIMPLE_DEV_PM_OPS() already implies const for the type; drop the extra modifier. Fixes: eb1aac4c8744f75460c34d71b0c73bebf3e8ee5c ("HID: google: add support tablet mode switch for Whiskers") Signed-off-by: Jiri Kosina --- In hid.git#for-4.20/google drivers/hid/

Re: [PATCH v2 1/2] mfd: cros: add "base attached" MKBP switch definition

2018-10-09 Thread Jiri Kosina
okhov > > --- > > > > v2 changes: None > > > > Lee, I was wondering if it would be OK for cros_ec_commands.h to be > > merged through HID tree. > > Yes, so long as it goes through in this merge-window. > > Acked-by: Lee Jones Thanks; both patches now queued in hid.git#for-4.20/google -- Jiri Kosina SUSE Labs

Re: [POC][RFC][PATCH 1/2] jump_function: Addition of new feature "jump_function"

2018-10-08 Thread Jiri Kosina
y objtool at all anyway. -- Jiri Kosina SUSE Labs

Re: [PATCH v2] Input: reserve 2 events code because of HID

2018-10-04 Thread Jiri Kosina
ough your tree, as the input-event-codes > changes that introduce REL_WHEEL_HI_RES are in your for-4.20/logitech-highres. Applied, thanks Benjamin. -- Jiri Kosina SUSE Labs

Re: [PATCH V2] hid: hid-core: Fix a sleep-in-atomic-context bug in __hid_request()

2018-10-04 Thread Jiri Kosina
ge the two drivers, and explicitly anotate __hid_request() > with might_sleep(). Thanks. Are you planning to submit a patch to do that? -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: i2c-hid: Add a small delay after powering on/off the device

2018-10-03 Thread Jiri Kosina
g.\n"); > + else > + msleep(20); In case there really is no other way around it, at least please add comment explaining why this ugly msleep() is there. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] [v4] HID: add support for Apple Magic Trackpad 2

2018-10-03 Thread Jiri Kosina
B and bluetooth, putting > the device in multi-touch mode. Applied, thanks. -- Jiri Kosina SUSE Labs

[GIT PULL] HID fixes

2018-10-03 Thread Jiri Kosina
, 12 insertions(+), 18 deletions(-) -- Jiri Kosina SUSE Labs

Re: [PATCH 2/2] x86/speculation: Provide application property based STIBP protection

2018-10-02 Thread Jiri Kosina
ll probably agree. So > anyway, I encourage a pragmatic approach similar to that for SSBD. Which is what Tim's patchset is implementing on top. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH V2] hid: hid-core: Fix a sleep-in-atomic-context bug in __hid_request()

2018-09-29 Thread Jiri Kosina
ets on being able to allocate the buffer > > without sleeping, > > In my opinion, I prefer this way. Why? Forcing all the report buffer to be limited to be non-sleeping allocations just because of two drivers, looks like an overkill, and actually calls for more issues (as GFP_ATOMIC is of course in principle less likely to succeed). -- Jiri Kosina SUSE Labs

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

2018-09-26 Thread tip-bot for Jiri Kosina
Commit-ID: 53c613fe6349994f023245519265999eed75957f Gitweb: https://git.kernel.org/tip/53c613fe6349994f023245519265999eed75957f Author: Jiri Kosina AuthorDate: Tue, 25 Sep 2018 14:38:55 +0200 Committer: Thomas Gleixner CommitDate: Wed, 26 Sep 2018 14:26:52 +0200 x86/speculation

[tip:x86/pti] x86/speculation: Propagate information about RSB filling mitigation to sysfs

2018-09-26 Thread tip-bot for Jiri Kosina
Commit-ID: bb4b3b7762735cdaba5a40fd94c9303d9ffa147a Gitweb: https://git.kernel.org/tip/bb4b3b7762735cdaba5a40fd94c9303d9ffa147a Author: Jiri Kosina AuthorDate: Tue, 25 Sep 2018 14:39:28 +0200 Committer: Thomas Gleixner CommitDate: Wed, 26 Sep 2018 14:26:52 +0200 x86/speculation

[tip:x86/pti] x86/speculation: Apply IBPB more strictly to avoid cross-process data leak

2018-09-26 Thread tip-bot for Jiri Kosina
Commit-ID: dbfe2953f63c640463c630746cd5d9de8b2f63ae Gitweb: https://git.kernel.org/tip/dbfe2953f63c640463c630746cd5d9de8b2f63ae Author: Jiri Kosina AuthorDate: Tue, 25 Sep 2018 14:38:18 +0200 Committer: Thomas Gleixner CommitDate: Wed, 26 Sep 2018 14:26:51 +0200 x86/speculation: Apply

[PATCH v7 3/3] x86/speculation: Propagate information about RSB filling mitigation to sysfs

2018-09-25 Thread Jiri Kosina
From: Jiri Kosina If spectrev2 mitigation has been enabled, we're filling RSB on context switch in order to protect from various classess of spectrev2 attacks. If this mitigation is enabled, say so in sysfs for spectrev2. Signed-off-by: Jiri Kosina --- arch/x86/kernel/cpu/bugs.c | 3 ++- 1

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

2018-09-25 Thread Jiri Kosina
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 siblings

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

2018-09-25 Thread Jiri Kosina
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 v7 0/3] Harden spectrev2 userspace-userspace protection

2018-09-25 Thread Jiri Kosina
etting to sysfs propagate STIBP setting to sysfs (Thomas Gleixner) simplify arch_smt_update() (Thomas Gleixner) v6->v7: PTRACE_MODE_NOACCESS_CHK -> PTRACE_MODE_SCHED and PTRACE_MODE_IBPB (Thomas Gleixner) drop unnecessary x86_spec_ctrl_base mutex in cp

Re: INFO: task hung in fsnotify_connector_destroy_workfn (2)

2018-09-24 Thread Jiri Kosina
ted(&(hid)->dev, fmt, ##arg) #define hid_warn(hid, fmt, arg...) \ - dev_warn(&(hid)->dev, fmt, ##arg) + dev_warn_ratelimited(&(hid)->dev, fmt, ##arg) #define hid_info(hid, fmt, arg...) \ - dev_info(&(hid)->dev, fmt, ##arg) + dev_info_ratelimited(&(hid)->dev, fmt, ##arg) #define hid_dbg(hid, fmt, arg...) \ - dev_dbg(&(hid)->dev, fmt, ##arg) + dev_dbg_ratelimited(&(hid)->dev, fmt, ##arg) #endif -- Jiri Kosina SUSE Labs

Re: [PATCH] HID: intel-ish-hid: Enable Ice Lake mobile

2018-09-24 Thread Jiri Kosina
ICE(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, ICL_MOBILE_DEVICE_ID)}, > {0, } Applied to for-4.19/fixes. -- Jiri Kosina SUSE Labs

Re: [PATCH v2] HID: logitech: fix a used uninitialized GCC warning

2018-09-24 Thread Jiri Kosina
ized] > hidpp->vertical_wheel_counter.resolution_multiplier = multiplier; > > Signed-off-by: zhong jiang > --- > v1->v2: > According to Benjamin's suggestion, To initialize the value > and remove the duplicated assignement. Applied to for-4.20/logitech-highres. Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH V2] hid: hid-core: Fix a sleep-in-atomic-context bug in __hid_request()

2018-09-24 Thread Jiri Kosina
being able to allocate the buffer without sleeping, or actually fix the few drivers (it's just lg4ff and picolcd at the end of the day) not to do that, and explicitly anotate __hid_request() with might_sleep(). Hmm? Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH] hyper-v: Fix wakeup from suspend-to-idle

2018-09-24 Thread Jiri Kosina
spurious SCI wakeups from > suspend-to-idle) > Signed-off-by: Vitaly Kuznetsov > --- > drivers/hid/hid-hyperv.c | 2 +- Acked-by: Jiri Kosina for the above. I guess this'd better go through ACPI tree? Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH 0/9] HID: intel ISH: Cleanup patches

2018-09-24 Thread Jiri Kosina
h > hid: intel-ish-hid: use helper function to search client id > > Hong Liu (2): > HID: intel-ish-hid: use resource-managed api > HID: intel-ish-hid: using list_head for ipc write queue > > Srinivas Pandruvada (1): > HID: intel_ish-hid: Enhance API to get ring buffer sizes Applied to for-4.20/ish. -- Jiri Kosina SUSE Labs

Re: [PATCH v6 0/3] Harden spectrev2 userspace-userspace protection

2018-09-24 Thread Jiri Kosina
On Sat, 22 Sep 2018, Thomas Gleixner wrote: > Lunch and coffee indeed made brain work better. The simple solution was way > too obvious. Ah, cool, I like it a lot. Do you want me to fold this into v7, or are you on it already? Thanks, -- Jiri Kosina SUSE Labs

Re: [PATCH v6 0/3] Harden spectrev2 userspace-userspace protection

2018-09-22 Thread Jiri Kosina
the scheduler's raw_spinlock_t, which are invalid lock nestings. Agreed. Therefore, if the current form (v6) of the patches is merged, the check before security_ptrace_access_check() should stay. Once all the LSM callbacks are potentially audited, it could then go in second phase. Is there anything else blocking v6 being merged? (and then Tim's set on top I guess, once the details are sorted out there). Thanks, -- Jiri Kosina SUSE Labs

RE: [PATCH v6 1/3] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

2018-09-14 Thread Jiri Kosina
duler context (wrt. locks), then it's all fine and I'll happily drop that check. Is it guaranteed? Thanks, -- Jiri Kosina SUSE Labs

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

2018-09-12 Thread Jiri Kosina
t should work. It all should be digestible by "linux end-users" (where users are also super-advanced sysadmins) easily. We currently have "I do care about spectrev2 / I don't care about spectrev2" boot-time switch, and I don't see us going any deeper / more fine-grained without sacrificing clarity and sanity. Or do you see a way how to do that nicely? Thanks, -- Jiri Kosina SUSE Labs

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

2018-09-12 Thread Jiri Kosina
g is overkill. It's a read after all and if there > is a concurrent SMT control fiddling going on then you have a chance of > getting the wrong information as well. Yeah; I was just happy to be able to stick second use of it there, with the first one being basically useless as well :) > I'll zap it. Absolutely feel free to. Thanks, -- Jiri Kosina SUSE Labs

[PATCH v6 3/3] x86/speculation: Propagate information about RSB filling mitigation to sysfs

2018-09-12 Thread Jiri Kosina
From: Jiri Kosina If spectrev2 mitigation has been enabled, we're filling RSB on context switch in order to protect from various classess of spectrev2 attacks. If this mitigation is enabled, say so in sysfs for spectrev2. Signed-off-by: Jiri Kosina --- arch/x86/kernel/cpu/bugs.c | 3 ++- 1

  1   2   3   4   5   6   7   8   9   10   >