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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
duler context (wrt. locks), then it's all fine and I'll
happily drop that check.
Is it guaranteed?
Thanks,
--
Jiri Kosina
SUSE Labs
duler context (wrt. locks), then it's all fine and I'll
happily drop that check.
Is it guaranteed?
Thanks,
--
Jiri Kosina
SUSE Labs
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
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
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
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
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
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
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
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
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
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
ace check if !IBPB
v4->v5:
fix MSR writing logic (Thomas Gleixner, Josh Poimboeuf)
v5->v6:
propagate X86_FEATURE_RSB_CTXSW setting to sysfs
propagate STIBP setting to sysfs (Thomas Gleixner)
simplify arch_smt_update() (Thomas Gleixner)
Jiri Kosina (3):
ace check if !IBPB
v4->v5:
fix MSR writing logic (Thomas Gleixner, Josh Poimboeuf)
v5->v6:
propagate X86_FEATURE_RSB_CTXSW setting to sysfs
propagate STIBP setting to sysfs (Thomas Gleixner)
simplify arch_smt_update() (Thomas Gleixner)
Jiri Kosina (3):
deletions(-)
--
Jiri Kosina
SUSE Labs
deletions(-)
--
Jiri Kosina
SUSE Labs
.
But before all that is fixed / worked around in LSM/audit (and I don't
have spare cycles for doing that myself), why not take the simple aproach
for now?
Thanks,
--
Jiri Kosina
SUSE Labs
.
But before all that is fixed / worked around in LSM/audit (and I don't
have spare cycles for doing that myself), why not take the simple aproach
for now?
Thanks,
--
Jiri Kosina
SUSE Labs
IBPB patch
and why exactly, I am not seeing it yet.
Thanks,
--
Jiri Kosina
SUSE Labs
IBPB patch
and why exactly, I am not seeing it yet.
Thanks,
--
Jiri Kosina
SUSE Labs
with.
Yeah, that was indeed my concern.
So can we agree on doing this in the 2nd envisioned step, when this is
going to be replaced by LSM as discussed [1] previously?
[1]
http://lkml.kernel.org/r/99fc4b6efcefd44486c35f4c281dc67321447...@orsmsx107.amr.corp.intel.com
Thanks,
--
Jiri Kosina
SUSE Labs
with.
Yeah, that was indeed my concern.
So can we agree on doing this in the 2nd envisioned step, when this is
going to be replaced by LSM as discussed [1] previously?
[1]
http://lkml.kernel.org/r/99fc4b6efcefd44486c35f4c281dc67321447...@orsmsx107.amr.corp.intel.com
Thanks,
--
Jiri Kosina
SUSE Labs
t guarantees that none of the hooks that
security_ptrace_access_check() is invoking will not be taking locks (from
scheduler context in this case)?
Thanks,
--
Jiri Kosina
SUSE Labs
t guarantees that none of the hooks that
security_ptrace_access_check() is invoking will not be taking locks (from
scheduler context in this case)?
Thanks,
--
Jiri Kosina
SUSE Labs
On Mon, 10 Sep 2018, Jiri Kosina wrote:
> > That looks much more palatable. One missing piece is the sysfs
> > mitigation file for spectre v2. That should reflect STIPB state as well.
>
> FWIW, we're missing a bit more in that area, namely RSB stuffing on
> context switc
On Mon, 10 Sep 2018, Jiri Kosina wrote:
> > That looks much more palatable. One missing piece is the sysfs
> > mitigation file for spectre v2. That should reflect STIPB state as well.
>
> FWIW, we're missing a bit more in that area, namely RSB stuffing on
> context switc
h only around fw) and IBPB; those are
only signalled in dmesg during bootup.
Want to add all this stuff there?
Thanks,
--
Jiri Kosina
SUSE Labs
h only around fw) and IBPB; those are
only signalled in dmesg during bootup.
Want to add all this stuff there?
Thanks,
--
Jiri Kosina
SUSE Labs
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
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
ace check if !IBPB
v4->v5:
fix MSR writing logic (Thomas Gleixner, Josh Poimboeuf)
Jiri Kosina (2):
x86/speculation: apply IBPB more strictly to avoid cross-process data leak
x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation
arch/x86/kernel/cpu
ace check if !IBPB
v4->v5:
fix MSR writing logic (Thomas Gleixner, Josh Poimboeuf)
Jiri Kosina (2):
x86/speculation: apply IBPB more strictly to avoid cross-process data leak
x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation
arch/x86/kernel/cpu
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
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
On Sat, 8 Sep 2018, Thomas Gleixner wrote:
> If after changing the SMT to enable a normal hotplug operation happens
> then you need to update the MSR as well.
Ah, right you are, thanks. Will fix in v5.
--
Jiri Kosina
SUSE Labs
On Sat, 8 Sep 2018, Thomas Gleixner wrote:
> If after changing the SMT to enable a normal hotplug operation happens
> then you need to update the MSR as well.
Ah, right you are, thanks. Will fix in v5.
--
Jiri Kosina
SUSE Labs
e_ the loop then you spare 50% IPIs again because the
> siblings will do the right thing via x86_spec_ctrl_base.
So I will go through the whole codepath again, but I fear your suggestion
would not work -- see the check for cpu_smt_control in stibp_needed(). We
need to see the old (or new, depending on the direction of the transition)
value of cpu_smt_contol, which will break if we move
arch_smt_enable_errata() (and thus the check).
But I am not 100% sure about this now, will double-check it tomorrow.
Thanks,
--
Jiri Kosina
SUSE Labs
e_ the loop then you spare 50% IPIs again because the
> siblings will do the right thing via x86_spec_ctrl_base.
So I will go through the whole codepath again, but I fear your suggestion
would not work -- see the check for cpu_smt_control in stibp_needed(). We
need to see the old (or new, depending on the direction of the transition)
value of cpu_smt_contol, which will break if we move
arch_smt_enable_errata() (and thus the check).
But I am not 100% sure about this now, will double-check it tomorrow.
Thanks,
--
Jiri Kosina
SUSE Labs
oing reset. If any regression
> happens to other touchpanel vendors, we can use quirk for Raydium
> devices.
>
> There's still one device uses I2C_HID_QUIRK_RESEND_REPORT_DESCR so keep
> it there.
>
> Cc: Aaron Ma
> Cc: AceLan Kao
> Signed-off-by: Kai-Heng Feng
Queued in for-4.19/fixes. Thanks,
--
Jiri Kosina
SUSE Labs
oing reset. If any regression
> happens to other touchpanel vendors, we can use quirk for Raydium
> devices.
>
> There's still one device uses I2C_HID_QUIRK_RESEND_REPORT_DESCR so keep
> it there.
>
> Cc: Aaron Ma
> Cc: AceLan Kao
> Signed-off-by: Kai-Heng Feng
Queued in for-4.19/fixes. Thanks,
--
Jiri Kosina
SUSE Labs
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
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
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
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
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
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
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
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
ace check if !IBPB
Jiri Kosina (2):
x86/speculation: apply IBPB more strictly to avoid cross-process data leak
x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation
arch/x86/kernel/cpu/bugs.c | 63
+++
arch/x86
ace check if !IBPB
Jiri Kosina (2):
x86/speculation: apply IBPB more strictly to avoid cross-process data leak
x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation
arch/x86/kernel/cpu/bugs.c | 63
+++
arch/x86
cpu_startup_entry+0x184/0x290
> [ 1838.863637] [] start_secondary+0x1da/0x250
So yeah, current Linus' tree needs the same treatment -- we have to avoid
calling out to ptrace_has_cap() in PTRACE_MODE_NOACCESS_CHK cases.
I have updated the patch for v4. Thanks again,
--
Jiri Kosina
SUSE Labs
cpu_startup_entry+0x184/0x290
> [ 1838.863637] [] start_secondary+0x1da/0x250
So yeah, current Linus' tree needs the same treatment -- we have to avoid
calling out to ptrace_has_cap() in PTRACE_MODE_NOACCESS_CHK cases.
I have updated the patch for v4. Thanks again,
--
Jiri Kosina
SUSE Labs
On Wed, 5 Sep 2018, Andrea Arcangeli wrote:
> Perhaps you didn't sandbox KVM inside selinux by default?
We by default do not enable selinux, so that's probably why.
Thanks again, will go through the code in mainline and adapt the patch
before sending v4.
--
Jiri Kosina
SUSE Labs
On Wed, 5 Sep 2018, Andrea Arcangeli wrote:
> Perhaps you didn't sandbox KVM inside selinux by default?
We by default do not enable selinux, so that's probably why.
Thanks again, will go through the code in mainline and adapt the patch
before sending v4.
--
Jiri Kosina
SUSE Labs
g IBPB and STIBP is keeping the system plain vulnerable to
user-user attacks, and us not providing users with possibiliy to easily
mitigate, is a bit embarassing in my eyes.
Thanks,
--
Jiri Kosina
SUSE Labs
g IBPB and STIBP is keeping the system plain vulnerable to
user-user attacks, and us not providing users with possibiliy to easily
mitigate, is a bit embarassing in my eyes.
Thanks,
--
Jiri Kosina
SUSE Labs
(task)->user_ns, mode))) {
> rcu_read_unlock();
> return -EPERM;
I will look into this whether it's still applicable or not, thanks a lot
for the pointer.
(and no, my testing of the patch I sent on current tree didn't produce any
hangs -- was there a reliable way to trigger it on 3.10?).
Thanks,
--
Jiri Kosina
SUSE Labs
(task)->user_ns, mode))) {
> rcu_read_unlock();
> return -EPERM;
I will look into this whether it's still applicable or not, thanks a lot
for the pointer.
(and no, my testing of the patch I sent on current tree didn't produce any
hangs -- was there a reliable way to trigger it on 3.10?).
Thanks,
--
Jiri Kosina
SUSE Labs
GFP_ATOMIC.
>
> This bug is found by my static analysis tool DSAC.
Could you please rewrite the changelog so that it's human readable? The
above is a bit hard to understand, I think something along the lines of
"__hid_request() has to be allocating with GFP_ATOMIC because there are
the following callchains leading to __hid_request() being an atomic
context: ... a->b->c.._hid_request()" etc.
Thanks,
--
Jiri Kosina
SUSE Labs
GFP_ATOMIC.
>
> This bug is found by my static analysis tool DSAC.
Could you please rewrite the changelog so that it's human readable? The
above is a bit hard to understand, I think something along the lines of
"__hid_request() has to be allocating with GFP_ATOMIC because there are
the following callchains leading to __hid_request() being an atomic
context: ... a->b->c.._hid_request()" etc.
Thanks,
--
Jiri Kosina
SUSE Labs
On Wed, 15 Aug 2018, Andrey Smirnov wrote:
> This is v2 of the patches adding support for rumble for Xbox One S
> controller connected over Bluetooth. Hopefully all of the changes are
> pretty straightforward and self-explanatory.
Applied to for-4.20/microsoft branch. Thanks,
--
Ji
On Wed, 15 Aug 2018, Andrey Smirnov wrote:
> This is v2 of the patches adding support for rumble for Xbox One S
> controller connected over Bluetooth. Hopefully all of the changes are
> pretty straightforward and self-explanatory.
Applied to for-4.20/microsoft branch. Thanks,
--
Ji
ng failed at offset %d\n", (int)(end -
> start));
> err:
> kfree(parser->collection_stack);
> +alloc_err:
> vfree(parser);
> hid_close_report(device);
> return ret;
Queued in for-4.19/fixes. Thanks,
--
Jiri Kosina
SUSE Labs
ng failed at offset %d\n", (int)(end -
> start));
> err:
> kfree(parser->collection_stack);
> +alloc_err:
> vfree(parser);
> hid_close_report(device);
> return ret;
Queued in for-4.19/fixes. Thanks,
--
Jiri Kosina
SUSE Labs
On Wed, 5 Sep 2018, Peter Zijlstra wrote:
> On Tue, Sep 04, 2018 at 06:18:55PM +0200, Thomas Gleixner wrote:
> > On Tue, 4 Sep 2018, Jiri Kosina wrote:
> > > if (tsk && tsk->mm &&
> > > tsk->mm->context.ctx_id != las
On Wed, 5 Sep 2018, Peter Zijlstra wrote:
> On Tue, Sep 04, 2018 at 06:18:55PM +0200, Thomas Gleixner wrote:
> > On Tue, 4 Sep 2018, Jiri Kosina wrote:
> > > if (tsk && tsk->mm &&
> > > tsk->mm->context.ctx_id != las
y-picked
from original Tim's series, but it is indeed superfluous.
Thanks,
--
Jiri Kosina
SUSE Labs
y-picked
from original Tim's series, but it is indeed superfluous.
Thanks,
--
Jiri Kosina
SUSE Labs
!IBPB-capable systems), and we can then later see whether
the LSM implementation, once it exists, should be used instead.
Thanks,
--
Jiri Kosina
SUSE Labs
!IBPB-capable systems), and we can then later see whether
the LSM implementation, once it exists, should be used instead.
Thanks,
--
Jiri Kosina
SUSE Labs
> Patch 2 and 4 are just nice to have, so v4.20 should be fine.
And I've queued the patches exactly like that. Thanks,
--
Jiri Kosina
SUSE Labs
> Patch 2 and 4 are just nice to have, so v4.20 should be fine.
And I've queued the patches exactly like that. Thanks,
--
Jiri Kosina
SUSE Labs
>
> 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
601 - 700 of 6650 matches
Mail list logo
