Re: [PATCH 1/4] HID: multitouch: fix Elan panels with 2 input modes declaration
On Tue, 4 Sep 2018, Benjamin Tissoires wrote:
> When implementing commit 7f81c8db5489 ("HID: multitouch: simplify
> the settings of the various features"), I wrongly removed a test
> that made sure we never try to set the second InputMode feature
> to something else than 0.
>
> 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
On Tue, 4 Sep 2018, Schaufler, Casey wrote: > > 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. > > Yes. That would be me. Ok, cool. Then 1/2 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
On Tue, 4 Sep 2018, Schaufler, Casey wrote: > > 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. > > Yes. That would be me. Ok, cool. Then 1/2 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
On Tue, 4 Sep 2018, Tim Chen wrote: > > 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. > > Casey recently has proposed putting the decision making of whether to > do IBPB in the security module. > > https://lwn.net/ml/kernel-hardening/20180815235355.14908-4-casey.schauf...@intel.com/ > > That will have the advantage of giving the administrator a more flexibility > of when to turn on IBPB. The policy is very similar to what you have > proposed here > but I think the security module is a more appropriate place for the security > policy. Yeah, well, honestly, I have a bit hard time buying the "generic sidechannel prevention security module" 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
On Tue, 4 Sep 2018, Tim Chen wrote: > > 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. > > Casey recently has proposed putting the decision making of whether to > do IBPB in the security module. > > https://lwn.net/ml/kernel-hardening/20180815235355.14908-4-casey.schauf...@intel.com/ > > That will have the advantage of giving the administrator a more flexibility > of when to turn on IBPB. The policy is very similar to what you have > proposed here > but I think the security module is a more appropriate place for the security > policy. Yeah, well, honestly, I have a bit hard time buying the "generic sidechannel prevention security module" 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 siblings online
- spectre_v2 mitigation autoselection is enabled (default)
After some previous discussion, this patch leaves STIBP on all the time,
as wrmsr on crossing kernel boundary is a no-no. This could perhaps later
be a bit more optimized (like disabling it in NOHZ, experiment with
disabling it in idle, etc) if needed.
Note: the code could be made less awkward if it'd be guaranteed that STIBP
could be kept on on a primary thread with SMT sibling being offline,
without potentially imposing performance penalty. This doesn't seem to be
defined anywhere though, so let's better be safe then sorry and always
flip STIBP both on primary and sibling threads on hotplug transitions.
Cc: sta...@vger.kernel.org
Signed-off-by: Jiri Kosina
---
Sorry for the resend, my pine is buggered and broke threading.
arch/x86/kernel/cpu/bugs.c | 63 ++
kernel/cpu.c | 13 +-
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 40bdaea97fe7..ba3df0a49a2e 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -325,6 +325,56 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
+static bool stibp_needed(void)
+{
+ if (spectre_v2_enabled == SPECTRE_V2_NONE)
+ return false;
+
+ if (cpu_smt_control != CPU_SMT_ENABLED)
+ return false;
+
+ if (!boot_cpu_has(X86_FEATURE_STIBP))
+ return false;
+
+ return true;
+}
+
+/*
+ * The read-modify-write of the MSR doesn't need any race protection here,
+ * as we're running in atomic context.
+ */
+static void enable_stibp(void *info)
+{
+ u64 mask;
+ rdmsrl(MSR_IA32_SPEC_CTRL, mask);
+ mask |= SPEC_CTRL_STIBP;
+ wrmsrl(MSR_IA32_SPEC_CTRL, mask);
+}
+
+static void disable_stibp(void *info)
+{
+ u64 mask;
+ rdmsrl(MSR_IA32_SPEC_CTRL, mask);
+ mask &= ~SPEC_CTRL_STIBP;
+ wrmsrl(MSR_IA32_SPEC_CTRL, mask);
+}
+
+void arch_smt_enable_errata(void)
+{
+ if (stibp_needed()) {
+ pr_info("Spectre v2 cross-process SMT mitigation: Enabling
STIBP\n");
+ on_each_cpu(enable_stibp, NULL, 1);
+ }
+}
+
+void arch_smt_disable_errata(void)
+{
+ if (stibp_needed()) {
+ pr_info("Spectre v2 cross-process SMT mitigation: Disabling
STIBP\n");
+ on_each_cpu(disable_stibp, NULL, 1);
+ }
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -424,6 +474,9 @@ static void __init spectre_v2_select_mitigation(void)
setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW);
pr_info("Enabling Restricted Speculation for firmware calls\n");
}
+
+ /* Enable STIBP on BP if needed */
+ arch_smt_enable_errata();
}
#undef pr_fmt
@@ -655,6 +708,16 @@ void x86_spec_ctrl_setup_ap(void)
if (ssb_mode == SPEC_STORE_BYPASS_DISABLE)
x86_amd_ssb_disable();
+
+ /*
+* If we are here during system bootup, enable STIBP.
+*
+* If we are here because of SMT hotplug, STIBP will be enabled by the
+* SMT control code (enabling here would not be sufficient, as it
+* needs to happen on primary threads as well).
+*/
+ if (stibp_needed() && system_state < SYSTEM_RUNNING)
+ enable_stibp(NULL);
}
#undef pr_fmt
diff --git a/kernel/cpu.c b/kernel/cpu.c
index aa7fe85ad62e..d3613d546829 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2025,17 +2025,27 @@ static void cpuhp_online_cpu_device(unsigned int cpu)
kobject_uevent(>kobj, KOBJ_ONLINE);
}
+/*
+ * Architectures that need SMT-specific errata handling during SMT hotplug
+ * should override these.
+ */
+void __weak arch_smt_enable_errata(void) { };
+void __weak arch_smt_disable_errata(void) { };
+
static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
{
int cpu, ret = 0;
cpu_maps_update_begin();
+ arch_smt_disable_errata();
for_each_online_cpu(cpu) {
if (topology_is_primary_thread(cpu))
continue;
ret = cpu_down_maps_locked(cpu, CPUHP_OFFLINE);
- if (ret)
+ if (ret) {
+ arch_smt_enable_errata();
break;
+ }
/*
* As this needs to hold the cpu maps lock it's impossible
* to call device_offline()
[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 siblings online
- spectre_v2 mitigation autoselection is enabled (default)
After some previous discussion, this patch leaves STIBP on all the time,
as wrmsr on crossing kernel boundary is a no-no. This could perhaps later
be a bit more optimized (like disabling it in NOHZ, experiment with
disabling it in idle, etc) if needed.
Note: the code could be made less awkward if it'd be guaranteed that STIBP
could be kept on on a primary thread with SMT sibling being offline,
without potentially imposing performance penalty. This doesn't seem to be
defined anywhere though, so let's better be safe then sorry and always
flip STIBP both on primary and sibling threads on hotplug transitions.
Cc: sta...@vger.kernel.org
Signed-off-by: Jiri Kosina
---
Sorry for the resend, my pine is buggered and broke threading.
arch/x86/kernel/cpu/bugs.c | 63 ++
kernel/cpu.c | 13 +-
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 40bdaea97fe7..ba3df0a49a2e 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -325,6 +325,56 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
+static bool stibp_needed(void)
+{
+ if (spectre_v2_enabled == SPECTRE_V2_NONE)
+ return false;
+
+ if (cpu_smt_control != CPU_SMT_ENABLED)
+ return false;
+
+ if (!boot_cpu_has(X86_FEATURE_STIBP))
+ return false;
+
+ return true;
+}
+
+/*
+ * The read-modify-write of the MSR doesn't need any race protection here,
+ * as we're running in atomic context.
+ */
+static void enable_stibp(void *info)
+{
+ u64 mask;
+ rdmsrl(MSR_IA32_SPEC_CTRL, mask);
+ mask |= SPEC_CTRL_STIBP;
+ wrmsrl(MSR_IA32_SPEC_CTRL, mask);
+}
+
+static void disable_stibp(void *info)
+{
+ u64 mask;
+ rdmsrl(MSR_IA32_SPEC_CTRL, mask);
+ mask &= ~SPEC_CTRL_STIBP;
+ wrmsrl(MSR_IA32_SPEC_CTRL, mask);
+}
+
+void arch_smt_enable_errata(void)
+{
+ if (stibp_needed()) {
+ pr_info("Spectre v2 cross-process SMT mitigation: Enabling
STIBP\n");
+ on_each_cpu(enable_stibp, NULL, 1);
+ }
+}
+
+void arch_smt_disable_errata(void)
+{
+ if (stibp_needed()) {
+ pr_info("Spectre v2 cross-process SMT mitigation: Disabling
STIBP\n");
+ on_each_cpu(disable_stibp, NULL, 1);
+ }
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -424,6 +474,9 @@ static void __init spectre_v2_select_mitigation(void)
setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW);
pr_info("Enabling Restricted Speculation for firmware calls\n");
}
+
+ /* Enable STIBP on BP if needed */
+ arch_smt_enable_errata();
}
#undef pr_fmt
@@ -655,6 +708,16 @@ void x86_spec_ctrl_setup_ap(void)
if (ssb_mode == SPEC_STORE_BYPASS_DISABLE)
x86_amd_ssb_disable();
+
+ /*
+* If we are here during system bootup, enable STIBP.
+*
+* If we are here because of SMT hotplug, STIBP will be enabled by the
+* SMT control code (enabling here would not be sufficient, as it
+* needs to happen on primary threads as well).
+*/
+ if (stibp_needed() && system_state < SYSTEM_RUNNING)
+ enable_stibp(NULL);
}
#undef pr_fmt
diff --git a/kernel/cpu.c b/kernel/cpu.c
index aa7fe85ad62e..d3613d546829 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2025,17 +2025,27 @@ static void cpuhp_online_cpu_device(unsigned int cpu)
kobject_uevent(>kobj, KOBJ_ONLINE);
}
+/*
+ * Architectures that need SMT-specific errata handling during SMT hotplug
+ * should override these.
+ */
+void __weak arch_smt_enable_errata(void) { };
+void __weak arch_smt_disable_errata(void) { };
+
static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
{
int cpu, ret = 0;
cpu_maps_update_begin();
+ arch_smt_disable_errata();
for_each_online_cpu(cpu) {
if (topology_is_primary_thread(cpu))
continue;
ret = cpu_down_maps_locked(cpu, CPUHP_OFFLINE);
- if (ret)
+ if (ret) {
+ arch_smt_enable_errata();
break;
+ }
/*
* As this needs to hold the cpu maps lock it's impossible
* to call device_offline()
[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 insufficient to provide proper userspace-to-userpace
spectrev2 protection, as any process can poison branch buffers before being
scheduled out, and the newly scheduled process immediately becomes spectrev2
victim.
In order to minimize the performance impact (for usecases that do require
spectrev2 protection), issue the barrier only in cases when switching between
processess where the victim can't be ptraced by the potential attacker (as in
such cases, the attacker doesn't have to bother with branch buffers at all).
Fixes: 18bf3c3ea8 ("x86/speculation: Use Indirect Branch Prediction Barrier in
context switch")
Originally-by: Tim Chen
Signed-off-by: Jiri Kosina
---
Sorry for the resend, my pine is buggered and broke threading.
arch/x86/mm/tlb.c | 15 ++-
include/linux/ptrace.h | 3 +++
kernel/ptrace.c| 4 +++-
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index e96b99eb800c..ce33e58b9327 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -262,18 +263,14 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
* one process from doing Spectre-v2 attacks on another.
*
* As an optimization, flush indirect branches only when
-* switching into processes that disable dumping. This
-* protects high value processes like gpg, without having
-* too high performance overhead. IBPB is *expensive*!
-*
-* This will not flush branches when switching into kernel
-* threads. It will also not flush if we switch to idle
-* thread and back to the same process. It will flush if we
-* switch to a different non-dumpable process.
+* switching into a processes that can't be ptrace by the
+* current one (as in such case, attacker has much more
+* convenient way how to tamper with the next process than
+* branch buffer poisoning).
*/
if (tsk && tsk->mm &&
tsk->mm->context.ctx_id != last_ctx_id &&
- get_dumpable(tsk->mm) != SUID_DUMP_USER)
+ ___ptrace_may_access(current, tsk, PTRACE_MODE_IBPB))
indirect_branch_prediction_barrier();
if (IS_ENABLED(CONFIG_VMAP_STACK)) {
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 09744d4113fb..adab379b5456 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -64,12 +64,15 @@ extern void exit_ptrace(struct task_struct *tracer, struct
list_head *dead);
#define PTRACE_MODE_NOAUDIT0x04
#define PTRACE_MODE_FSCREDS 0x08
#define PTRACE_MODE_REALCREDS 0x10
+#define PTRACE_MODE_NOACCESS_CHK 0x20
/* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
#define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
#define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
PTRACE_MODE_REALCREDS)
+#define PTRACE_MODE_IBPB (PTRACE_MODE_ATTACH | PTRACE_MODE_NOAUDIT \
+ | PTRACE_MODE_NOACCESS_CHK | PTRACE_MODE_REALCREDS)
/**
* ptrace_may_access - check whether the caller is permitted to access
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 07ff6685ebed..b41c37f44c32 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -330,7 +330,9 @@ int ___ptrace_may_access(struct task_struct *curr, struct
task_struct *task,
!ptrace_has_cap(mm->user_ns, mode)))
return -EPERM;
- return security_ptrace_access_check(task, mode);
+ if (!(mode & PTRACE_MODE_NOACCESS_CHK))
+ return security_ptrace_access_check(task, mode);
+ return 0;
}
static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
--
Jiri Kosina
SUSE Labs
[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 insufficient to provide proper userspace-to-userpace
spectrev2 protection, as any process can poison branch buffers before being
scheduled out, and the newly scheduled process immediately becomes spectrev2
victim.
In order to minimize the performance impact (for usecases that do require
spectrev2 protection), issue the barrier only in cases when switching between
processess where the victim can't be ptraced by the potential attacker (as in
such cases, the attacker doesn't have to bother with branch buffers at all).
Fixes: 18bf3c3ea8 ("x86/speculation: Use Indirect Branch Prediction Barrier in
context switch")
Originally-by: Tim Chen
Signed-off-by: Jiri Kosina
---
Sorry for the resend, my pine is buggered and broke threading.
arch/x86/mm/tlb.c | 15 ++-
include/linux/ptrace.h | 3 +++
kernel/ptrace.c| 4 +++-
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index e96b99eb800c..ce33e58b9327 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -262,18 +263,14 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
* one process from doing Spectre-v2 attacks on another.
*
* As an optimization, flush indirect branches only when
-* switching into processes that disable dumping. This
-* protects high value processes like gpg, without having
-* too high performance overhead. IBPB is *expensive*!
-*
-* This will not flush branches when switching into kernel
-* threads. It will also not flush if we switch to idle
-* thread and back to the same process. It will flush if we
-* switch to a different non-dumpable process.
+* switching into a processes that can't be ptrace by the
+* current one (as in such case, attacker has much more
+* convenient way how to tamper with the next process than
+* branch buffer poisoning).
*/
if (tsk && tsk->mm &&
tsk->mm->context.ctx_id != last_ctx_id &&
- get_dumpable(tsk->mm) != SUID_DUMP_USER)
+ ___ptrace_may_access(current, tsk, PTRACE_MODE_IBPB))
indirect_branch_prediction_barrier();
if (IS_ENABLED(CONFIG_VMAP_STACK)) {
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 09744d4113fb..adab379b5456 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -64,12 +64,15 @@ extern void exit_ptrace(struct task_struct *tracer, struct
list_head *dead);
#define PTRACE_MODE_NOAUDIT0x04
#define PTRACE_MODE_FSCREDS 0x08
#define PTRACE_MODE_REALCREDS 0x10
+#define PTRACE_MODE_NOACCESS_CHK 0x20
/* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
#define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
#define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
PTRACE_MODE_REALCREDS)
+#define PTRACE_MODE_IBPB (PTRACE_MODE_ATTACH | PTRACE_MODE_NOAUDIT \
+ | PTRACE_MODE_NOACCESS_CHK | PTRACE_MODE_REALCREDS)
/**
* ptrace_may_access - check whether the caller is permitted to access
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 07ff6685ebed..b41c37f44c32 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -330,7 +330,9 @@ int ___ptrace_may_access(struct task_struct *curr, struct
task_struct *task,
!ptrace_has_cap(mm->user_ns, mode)))
return -EPERM;
- return security_ptrace_access_check(task, mode);
+ if (!(mode & PTRACE_MODE_NOACCESS_CHK))
+ return security_ptrace_access_check(task, mode);
+ return 0;
}
static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
--
Jiri Kosina
SUSE Labs
[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 pine is buggered and broke threading.
include/linux/ptrace.h | 12
kernel/ptrace.c| 13 ++---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 4f36431c380b..09744d4113fb 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -87,6 +87,18 @@ extern void exit_ptrace(struct task_struct *tracer, struct
list_head *dead);
*/
extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
+/**
+ * ___ptrace_may_access - variant of ptrace_may_access that can be used
+ * between two arbitrary tasks
+ * @curr: source task
+ * @task: target task
+ * @mode: selects type of access and caller credentials
+ *
+ * Returns true on success, false on denial.
+ */
+extern int ___ptrace_may_access(struct task_struct *curr, struct task_struct
*task,
+ unsigned int mode);
+
static inline int ptrace_reparented(struct task_struct *child)
{
return !same_thread_group(child->real_parent, child->parent);
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 21fec73d45d4..07ff6685ebed 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -268,9 +268,10 @@ static int ptrace_has_cap(struct user_namespace *ns,
unsigned int mode)
}
/* Returns 0 on success, -errno on denial. */
-static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+int ___ptrace_may_access(struct task_struct *curr, struct task_struct *task,
+ unsigned int mode)
{
- const struct cred *cred = current_cred(), *tcred;
+ const struct cred *cred, *tcred;
struct mm_struct *mm;
kuid_t caller_uid;
kgid_t caller_gid;
@@ -290,9 +291,10 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
*/
/* Don't let security modules deny introspection */
- if (same_thread_group(task, current))
+ if (same_thread_group(task, curr))
return 0;
rcu_read_lock();
+ cred = __task_cred(curr);
if (mode & PTRACE_MODE_FSCREDS) {
caller_uid = cred->fsuid;
caller_gid = cred->fsgid;
@@ -331,6 +333,11 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
return security_ptrace_access_check(task, mode);
}
+static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+{
+ return ___ptrace_may_access(current, task, mode);
+}
+
bool ptrace_may_access(struct task_struct *task, unsigned int mode)
{
int err;
--
Jiri Kosina
SUSE Labs
[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 pine is buggered and broke threading.
include/linux/ptrace.h | 12
kernel/ptrace.c| 13 ++---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 4f36431c380b..09744d4113fb 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -87,6 +87,18 @@ extern void exit_ptrace(struct task_struct *tracer, struct
list_head *dead);
*/
extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
+/**
+ * ___ptrace_may_access - variant of ptrace_may_access that can be used
+ * between two arbitrary tasks
+ * @curr: source task
+ * @task: target task
+ * @mode: selects type of access and caller credentials
+ *
+ * Returns true on success, false on denial.
+ */
+extern int ___ptrace_may_access(struct task_struct *curr, struct task_struct
*task,
+ unsigned int mode);
+
static inline int ptrace_reparented(struct task_struct *child)
{
return !same_thread_group(child->real_parent, child->parent);
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 21fec73d45d4..07ff6685ebed 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -268,9 +268,10 @@ static int ptrace_has_cap(struct user_namespace *ns,
unsigned int mode)
}
/* Returns 0 on success, -errno on denial. */
-static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+int ___ptrace_may_access(struct task_struct *curr, struct task_struct *task,
+ unsigned int mode)
{
- const struct cred *cred = current_cred(), *tcred;
+ const struct cred *cred, *tcred;
struct mm_struct *mm;
kuid_t caller_uid;
kgid_t caller_gid;
@@ -290,9 +291,10 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
*/
/* Don't let security modules deny introspection */
- if (same_thread_group(task, current))
+ if (same_thread_group(task, curr))
return 0;
rcu_read_lock();
+ cred = __task_cred(curr);
if (mode & PTRACE_MODE_FSCREDS) {
caller_uid = cred->fsuid;
caller_gid = cred->fsgid;
@@ -331,6 +333,11 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
return security_ptrace_access_check(task, mode);
}
+static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+{
+ return ___ptrace_may_access(current, task, mode);
+}
+
bool ptrace_may_access(struct task_struct *task, unsigned int mode)
{
int err;
--
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 siblings online
- spectre_v2 mitigation autoselection is enabled (default)
After some previous discussion, this patch leaves STIBP on all the time,
as wrmsr on crossing kernel boundary is a no-no. This could perhaps later
be a bit more optimized (like disabling it in NOHZ, experiment with
disabling it in idle, etc) if needed.
Note: the code could be made less awkward if it'd be guaranteed that STIBP
could be kept on on a primary thread with SMT sibling being offline,
without potentially imposing performance penalty. This doesn't seem to be
defined anywhere though, so let's better be safe then sorry and always
flip STIBP both on primary and sibling threads on hotplug transitions.
Cc: sta...@vger.kernel.org
Signed-off-by: Jiri Kosina
---
arch/x86/kernel/cpu/bugs.c | 63 ++
kernel/cpu.c | 13 +-
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 40bdaea97fe7..ba3df0a49a2e 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -325,6 +325,56 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
+static bool stibp_needed(void)
+{
+ if (spectre_v2_enabled == SPECTRE_V2_NONE)
+ return false;
+
+ if (cpu_smt_control != CPU_SMT_ENABLED)
+ return false;
+
+ if (!boot_cpu_has(X86_FEATURE_STIBP))
+ return false;
+
+ return true;
+}
+
+/*
+ * The read-modify-write of the MSR doesn't need any race protection here,
+ * as we're running in atomic context.
+ */
+static void enable_stibp(void *info)
+{
+ u64 mask;
+ rdmsrl(MSR_IA32_SPEC_CTRL, mask);
+ mask |= SPEC_CTRL_STIBP;
+ wrmsrl(MSR_IA32_SPEC_CTRL, mask);
+}
+
+static void disable_stibp(void *info)
+{
+ u64 mask;
+ rdmsrl(MSR_IA32_SPEC_CTRL, mask);
+ mask &= ~SPEC_CTRL_STIBP;
+ wrmsrl(MSR_IA32_SPEC_CTRL, mask);
+}
+
+void arch_smt_enable_errata(void)
+{
+ if (stibp_needed()) {
+ pr_info("Spectre v2 cross-process SMT mitigation: Enabling
STIBP\n");
+ on_each_cpu(enable_stibp, NULL, 1);
+ }
+}
+
+void arch_smt_disable_errata(void)
+{
+ if (stibp_needed()) {
+ pr_info("Spectre v2 cross-process SMT mitigation: Disabling
STIBP\n");
+ on_each_cpu(disable_stibp, NULL, 1);
+ }
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -424,6 +474,9 @@ static void __init spectre_v2_select_mitigation(void)
setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW);
pr_info("Enabling Restricted Speculation for firmware calls\n");
}
+
+ /* Enable STIBP on BP if needed */
+ arch_smt_enable_errata();
}
#undef pr_fmt
@@ -655,6 +708,16 @@ void x86_spec_ctrl_setup_ap(void)
if (ssb_mode == SPEC_STORE_BYPASS_DISABLE)
x86_amd_ssb_disable();
+
+ /*
+* If we are here during system bootup, enable STIBP.
+*
+* If we are here because of SMT hotplug, STIBP will be enabled by the
+* SMT control code (enabling here would not be sufficient, as it
+* needs to happen on primary threads as well).
+*/
+ if (stibp_needed() && system_state < SYSTEM_RUNNING)
+ enable_stibp(NULL);
}
#undef pr_fmt
diff --git a/kernel/cpu.c b/kernel/cpu.c
index aa7fe85ad62e..d3613d546829 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2025,17 +2025,27 @@ static void cpuhp_online_cpu_device(unsigned int cpu)
kobject_uevent(>kobj, KOBJ_ONLINE);
}
+/*
+ * Architectures that need SMT-specific errata handling during SMT hotplug
+ * should override these.
+ */
+void __weak arch_smt_enable_errata(void) { };
+void __weak arch_smt_disable_errata(void) { };
+
static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
{
int cpu, ret = 0;
cpu_maps_update_begin();
+ arch_smt_disable_errata();
for_each_online_cpu(cpu) {
if (topology_is_primary_thread(cpu))
continue;
ret = cpu_down_maps_locked(cpu, CPUHP_OFFLINE);
- if (ret)
+ if (ret) {
+ arch_smt_enable_errata();
break;
+ }
/*
* As this needs to hold the cpu maps lock it's impossible
* to call device_offline() because that ends up calling
@@ -2073,6 +2083,7 @@ static int cpuhp
[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 siblings online
- spectre_v2 mitigation autoselection is enabled (default)
After some previous discussion, this patch leaves STIBP on all the time,
as wrmsr on crossing kernel boundary is a no-no. This could perhaps later
be a bit more optimized (like disabling it in NOHZ, experiment with
disabling it in idle, etc) if needed.
Note: the code could be made less awkward if it'd be guaranteed that STIBP
could be kept on on a primary thread with SMT sibling being offline,
without potentially imposing performance penalty. This doesn't seem to be
defined anywhere though, so let's better be safe then sorry and always
flip STIBP both on primary and sibling threads on hotplug transitions.
Cc: sta...@vger.kernel.org
Signed-off-by: Jiri Kosina
---
arch/x86/kernel/cpu/bugs.c | 63 ++
kernel/cpu.c | 13 +-
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 40bdaea97fe7..ba3df0a49a2e 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -325,6 +325,56 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
+static bool stibp_needed(void)
+{
+ if (spectre_v2_enabled == SPECTRE_V2_NONE)
+ return false;
+
+ if (cpu_smt_control != CPU_SMT_ENABLED)
+ return false;
+
+ if (!boot_cpu_has(X86_FEATURE_STIBP))
+ return false;
+
+ return true;
+}
+
+/*
+ * The read-modify-write of the MSR doesn't need any race protection here,
+ * as we're running in atomic context.
+ */
+static void enable_stibp(void *info)
+{
+ u64 mask;
+ rdmsrl(MSR_IA32_SPEC_CTRL, mask);
+ mask |= SPEC_CTRL_STIBP;
+ wrmsrl(MSR_IA32_SPEC_CTRL, mask);
+}
+
+static void disable_stibp(void *info)
+{
+ u64 mask;
+ rdmsrl(MSR_IA32_SPEC_CTRL, mask);
+ mask &= ~SPEC_CTRL_STIBP;
+ wrmsrl(MSR_IA32_SPEC_CTRL, mask);
+}
+
+void arch_smt_enable_errata(void)
+{
+ if (stibp_needed()) {
+ pr_info("Spectre v2 cross-process SMT mitigation: Enabling
STIBP\n");
+ on_each_cpu(enable_stibp, NULL, 1);
+ }
+}
+
+void arch_smt_disable_errata(void)
+{
+ if (stibp_needed()) {
+ pr_info("Spectre v2 cross-process SMT mitigation: Disabling
STIBP\n");
+ on_each_cpu(disable_stibp, NULL, 1);
+ }
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -424,6 +474,9 @@ static void __init spectre_v2_select_mitigation(void)
setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW);
pr_info("Enabling Restricted Speculation for firmware calls\n");
}
+
+ /* Enable STIBP on BP if needed */
+ arch_smt_enable_errata();
}
#undef pr_fmt
@@ -655,6 +708,16 @@ void x86_spec_ctrl_setup_ap(void)
if (ssb_mode == SPEC_STORE_BYPASS_DISABLE)
x86_amd_ssb_disable();
+
+ /*
+* If we are here during system bootup, enable STIBP.
+*
+* If we are here because of SMT hotplug, STIBP will be enabled by the
+* SMT control code (enabling here would not be sufficient, as it
+* needs to happen on primary threads as well).
+*/
+ if (stibp_needed() && system_state < SYSTEM_RUNNING)
+ enable_stibp(NULL);
}
#undef pr_fmt
diff --git a/kernel/cpu.c b/kernel/cpu.c
index aa7fe85ad62e..d3613d546829 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2025,17 +2025,27 @@ static void cpuhp_online_cpu_device(unsigned int cpu)
kobject_uevent(>kobj, KOBJ_ONLINE);
}
+/*
+ * Architectures that need SMT-specific errata handling during SMT hotplug
+ * should override these.
+ */
+void __weak arch_smt_enable_errata(void) { };
+void __weak arch_smt_disable_errata(void) { };
+
static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
{
int cpu, ret = 0;
cpu_maps_update_begin();
+ arch_smt_disable_errata();
for_each_online_cpu(cpu) {
if (topology_is_primary_thread(cpu))
continue;
ret = cpu_down_maps_locked(cpu, CPUHP_OFFLINE);
- if (ret)
+ if (ret) {
+ arch_smt_enable_errata();
break;
+ }
/*
* As this needs to hold the cpu maps lock it's impossible
* to call device_offline() because that ends up calling
@@ -2073,6 +2083,7 @@ static int cpuhp
[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 insufficient to provide proper userspace-to-userpace
spectrev2 protection, as any process can poison branch buffers before being
scheduled out, and the newly scheduled process immediately becomes spectrev2
victim.
In order to minimize the performance impact (for usecases that do require
spectrev2 protection), issue the barrier only in cases when switching between
processess where the victim can't be ptraced by the potential attacker (as in
such cases, the attacker doesn't have to bother with branch buffers at all).
Fixes: 18bf3c3ea8 ("x86/speculation: Use Indirect Branch Prediction Barrier in
context switch")
Originally-by: Tim Chen
Signed-off-by: Jiri Kosina
---
arch/x86/mm/tlb.c | 15 ++-
include/linux/ptrace.h | 3 +++
kernel/ptrace.c| 4 +++-
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index e96b99eb800c..ce33e58b9327 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -262,18 +263,14 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
* one process from doing Spectre-v2 attacks on another.
*
* As an optimization, flush indirect branches only when
-* switching into processes that disable dumping. This
-* protects high value processes like gpg, without having
-* too high performance overhead. IBPB is *expensive*!
-*
-* This will not flush branches when switching into kernel
-* threads. It will also not flush if we switch to idle
-* thread and back to the same process. It will flush if we
-* switch to a different non-dumpable process.
+* switching into a processes that can't be ptrace by the
+* current one (as in such case, attacker has much more
+* convenient way how to tamper with the next process than
+* branch buffer poisoning).
*/
if (tsk && tsk->mm &&
tsk->mm->context.ctx_id != last_ctx_id &&
- get_dumpable(tsk->mm) != SUID_DUMP_USER)
+ ___ptrace_may_access(current, tsk, PTRACE_MODE_IBPB))
indirect_branch_prediction_barrier();
if (IS_ENABLED(CONFIG_VMAP_STACK)) {
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 09744d4113fb..adab379b5456 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -64,12 +64,15 @@ extern void exit_ptrace(struct task_struct *tracer, struct
list_head *dead);
#define PTRACE_MODE_NOAUDIT0x04
#define PTRACE_MODE_FSCREDS 0x08
#define PTRACE_MODE_REALCREDS 0x10
+#define PTRACE_MODE_NOACCESS_CHK 0x20
/* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
#define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
#define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
PTRACE_MODE_REALCREDS)
+#define PTRACE_MODE_IBPB (PTRACE_MODE_ATTACH | PTRACE_MODE_NOAUDIT \
+ | PTRACE_MODE_NOACCESS_CHK | PTRACE_MODE_REALCREDS)
/**
* ptrace_may_access - check whether the caller is permitted to access
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 07ff6685ebed..b41c37f44c32 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -330,7 +330,9 @@ int ___ptrace_may_access(struct task_struct *curr, struct
task_struct *task,
!ptrace_has_cap(mm->user_ns, mode)))
return -EPERM;
- return security_ptrace_access_check(task, mode);
+ if (!(mode & PTRACE_MODE_NOACCESS_CHK))
+ return security_ptrace_access_check(task, mode);
+ return 0;
}
static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
--
Jiri Kosina
SUSE Labs
[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 insufficient to provide proper userspace-to-userpace
spectrev2 protection, as any process can poison branch buffers before being
scheduled out, and the newly scheduled process immediately becomes spectrev2
victim.
In order to minimize the performance impact (for usecases that do require
spectrev2 protection), issue the barrier only in cases when switching between
processess where the victim can't be ptraced by the potential attacker (as in
such cases, the attacker doesn't have to bother with branch buffers at all).
Fixes: 18bf3c3ea8 ("x86/speculation: Use Indirect Branch Prediction Barrier in
context switch")
Originally-by: Tim Chen
Signed-off-by: Jiri Kosina
---
arch/x86/mm/tlb.c | 15 ++-
include/linux/ptrace.h | 3 +++
kernel/ptrace.c| 4 +++-
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index e96b99eb800c..ce33e58b9327 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -262,18 +263,14 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
* one process from doing Spectre-v2 attacks on another.
*
* As an optimization, flush indirect branches only when
-* switching into processes that disable dumping. This
-* protects high value processes like gpg, without having
-* too high performance overhead. IBPB is *expensive*!
-*
-* This will not flush branches when switching into kernel
-* threads. It will also not flush if we switch to idle
-* thread and back to the same process. It will flush if we
-* switch to a different non-dumpable process.
+* switching into a processes that can't be ptrace by the
+* current one (as in such case, attacker has much more
+* convenient way how to tamper with the next process than
+* branch buffer poisoning).
*/
if (tsk && tsk->mm &&
tsk->mm->context.ctx_id != last_ctx_id &&
- get_dumpable(tsk->mm) != SUID_DUMP_USER)
+ ___ptrace_may_access(current, tsk, PTRACE_MODE_IBPB))
indirect_branch_prediction_barrier();
if (IS_ENABLED(CONFIG_VMAP_STACK)) {
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 09744d4113fb..adab379b5456 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -64,12 +64,15 @@ extern void exit_ptrace(struct task_struct *tracer, struct
list_head *dead);
#define PTRACE_MODE_NOAUDIT0x04
#define PTRACE_MODE_FSCREDS 0x08
#define PTRACE_MODE_REALCREDS 0x10
+#define PTRACE_MODE_NOACCESS_CHK 0x20
/* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
#define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
#define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
PTRACE_MODE_REALCREDS)
+#define PTRACE_MODE_IBPB (PTRACE_MODE_ATTACH | PTRACE_MODE_NOAUDIT \
+ | PTRACE_MODE_NOACCESS_CHK | PTRACE_MODE_REALCREDS)
/**
* ptrace_may_access - check whether the caller is permitted to access
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 07ff6685ebed..b41c37f44c32 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -330,7 +330,9 @@ int ___ptrace_may_access(struct task_struct *curr, struct
task_struct *task,
!ptrace_has_cap(mm->user_ns, mode)))
return -EPERM;
- return security_ptrace_access_check(task, mode);
+ if (!(mode & PTRACE_MODE_NOACCESS_CHK))
+ return security_ptrace_access_check(task, mode);
+ return 0;
}
static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
--
Jiri Kosina
SUSE Labs
[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 | 12
kernel/ptrace.c| 13 ++---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 4f36431c380b..09744d4113fb 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -87,6 +87,18 @@ extern void exit_ptrace(struct task_struct *tracer, struct
list_head *dead);
*/
extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
+/**
+ * ___ptrace_may_access - variant of ptrace_may_access that can be used
+ * between two arbitrary tasks
+ * @curr: source task
+ * @task: target task
+ * @mode: selects type of access and caller credentials
+ *
+ * Returns true on success, false on denial.
+ */
+extern int ___ptrace_may_access(struct task_struct *curr, struct task_struct
*task,
+ unsigned int mode);
+
static inline int ptrace_reparented(struct task_struct *child)
{
return !same_thread_group(child->real_parent, child->parent);
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 21fec73d45d4..07ff6685ebed 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -268,9 +268,10 @@ static int ptrace_has_cap(struct user_namespace *ns,
unsigned int mode)
}
/* Returns 0 on success, -errno on denial. */
-static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+int ___ptrace_may_access(struct task_struct *curr, struct task_struct *task,
+ unsigned int mode)
{
- const struct cred *cred = current_cred(), *tcred;
+ const struct cred *cred, *tcred;
struct mm_struct *mm;
kuid_t caller_uid;
kgid_t caller_gid;
@@ -290,9 +291,10 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
*/
/* Don't let security modules deny introspection */
- if (same_thread_group(task, current))
+ if (same_thread_group(task, curr))
return 0;
rcu_read_lock();
+ cred = __task_cred(curr);
if (mode & PTRACE_MODE_FSCREDS) {
caller_uid = cred->fsuid;
caller_gid = cred->fsgid;
@@ -331,6 +333,11 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
return security_ptrace_access_check(task, mode);
}
+static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+{
+ return ___ptrace_may_access(current, task, mode);
+}
+
bool ptrace_may_access(struct task_struct *task, unsigned int mode)
{
int err;
--
Jiri Kosina
SUSE Labs
[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 | 12
kernel/ptrace.c| 13 ++---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 4f36431c380b..09744d4113fb 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -87,6 +87,18 @@ extern void exit_ptrace(struct task_struct *tracer, struct
list_head *dead);
*/
extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
+/**
+ * ___ptrace_may_access - variant of ptrace_may_access that can be used
+ * between two arbitrary tasks
+ * @curr: source task
+ * @task: target task
+ * @mode: selects type of access and caller credentials
+ *
+ * Returns true on success, false on denial.
+ */
+extern int ___ptrace_may_access(struct task_struct *curr, struct task_struct
*task,
+ unsigned int mode);
+
static inline int ptrace_reparented(struct task_struct *child)
{
return !same_thread_group(child->real_parent, child->parent);
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 21fec73d45d4..07ff6685ebed 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -268,9 +268,10 @@ static int ptrace_has_cap(struct user_namespace *ns,
unsigned int mode)
}
/* Returns 0 on success, -errno on denial. */
-static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+int ___ptrace_may_access(struct task_struct *curr, struct task_struct *task,
+ unsigned int mode)
{
- const struct cred *cred = current_cred(), *tcred;
+ const struct cred *cred, *tcred;
struct mm_struct *mm;
kuid_t caller_uid;
kgid_t caller_gid;
@@ -290,9 +291,10 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
*/
/* Don't let security modules deny introspection */
- if (same_thread_group(task, current))
+ if (same_thread_group(task, curr))
return 0;
rcu_read_lock();
+ cred = __task_cred(curr);
if (mode & PTRACE_MODE_FSCREDS) {
caller_uid = cred->fsuid;
caller_gid = cred->fsgid;
@@ -331,6 +333,11 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
return security_ptrace_access_check(task, mode);
}
+static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+{
+ return ___ptrace_may_access(current, task, mode);
+}
+
bool ptrace_may_access(struct task_struct *task, unsigned int mode)
{
int err;
--
Jiri Kosina
SUSE Labs
[PATCH v3 0/3] Harden spectrev2 userspace-userspace protection
Currently, linux kernel is basically not preventing userspace-userspace spectrev2 attack, because: - IBPB is basically unused (issued only for tasks that marked themselves explicitly non-dumpable, which is absolutely negligible minority of all software out there), therefore cross-process branch buffer posioning using spectrev2 is possible - STIBP is completely unused, therefore cross-process branch buffer poisoning using spectrev2 between processess running on two HT siblings thread s is possible This patchset changes IBPB semantics, so that it's now applied whenever context-switching between processess that can't use ptrace() to achieve the same. This admittedly comes with extra overhad on a context switch; systems that don't care about could disable the mitigation using nospectre_v2 boot option. The IBPB implementaion is heavily based on original patches by Tim Chen. In addition to that, we unconditionally turn STIBP on so that HT siblings always have separate branch buffers. We've been carrying IBPB implementation with the same semantics in our (SUSE) trees since january disclosure; STIBP was more or less ignored up to today. v1->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 spectre v2 leak x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation arch/x86/kernel/cpu/bugs.c | 63 +++ arch/x86/mm/tlb.c | 15 ++- include/linux/ptrace.h | 15 +++ kernel/cpu.c | 13 - kernel/ptrace.c| 17 + 5 files changed, 109 insertions(+), 14 deletions(-) -- Jiri Kosina SUSE Labs
[PATCH v3 0/3] Harden spectrev2 userspace-userspace protection
Currently, linux kernel is basically not preventing userspace-userspace spectrev2 attack, because: - IBPB is basically unused (issued only for tasks that marked themselves explicitly non-dumpable, which is absolutely negligible minority of all software out there), therefore cross-process branch buffer posioning using spectrev2 is possible - STIBP is completely unused, therefore cross-process branch buffer poisoning using spectrev2 between processess running on two HT siblings thread s is possible This patchset changes IBPB semantics, so that it's now applied whenever context-switching between processess that can't use ptrace() to achieve the same. This admittedly comes with extra overhad on a context switch; systems that don't care about could disable the mitigation using nospectre_v2 boot option. The IBPB implementaion is heavily based on original patches by Tim Chen. In addition to that, we unconditionally turn STIBP on so that HT siblings always have separate branch buffers. We've been carrying IBPB implementation with the same semantics in our (SUSE) trees since january disclosure; STIBP was more or less ignored up to today. v1->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 spectre v2 leak x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation arch/x86/kernel/cpu/bugs.c | 63 +++ arch/x86/mm/tlb.c | 15 ++- include/linux/ptrace.h | 15 +++ kernel/cpu.c | 13 - kernel/ptrace.c| 17 + 5 files changed, 109 insertions(+), 14 deletions(-) -- Jiri Kosina SUSE Labs
Re: [PATCH v2 2/3] x86/speculation: Apply IBPB more strictly to avoid cross-process spectre v2 leak
On Mon, 3 Sep 2018, Peter Zijlstra wrote: > > if (tsk && tsk->mm && > > tsk->mm->context.ctx_id != last_ctx_id && > > - get_dumpable(tsk->mm) != SUID_DUMP_USER) > > + ___ptrace_may_access(tsk, current, PTRACE_MODE_IBPB)) > > indirect_branch_prediction_barrier(); > > So the question posed here is: can @next ptrace @prev? > > Which confuses me greatly; it is @prev doing the BTB poisoning for > @next, so we want to know if @prev can ptrace @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
On Mon, 3 Sep 2018, Peter Zijlstra wrote: > > if (tsk && tsk->mm && > > tsk->mm->context.ctx_id != last_ctx_id && > > - get_dumpable(tsk->mm) != SUID_DUMP_USER) > > + ___ptrace_may_access(tsk, current, PTRACE_MODE_IBPB)) > > indirect_branch_prediction_barrier(); > > So the question posed here is: can @next ptrace @prev? > > Which confuses me greatly; it is @prev doing the BTB poisoning for > @next, so we want to know if @prev can ptrace @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
On Mon, 3 Sep 2018, Benjamin Tissoires wrote: > > > The spec states that the HID devices should allow > > > the host to query the HID descriptor at any time. > > > > > > Some devices require the HID descriptor to be set > > > on resume, or they will fail. > > > > > > Instead of having a growing list of blacklisted devices > > > make the call part of the general resume process > > > so we can remove this list. > > > > > > Tested on a Dell XPS 9360 and a Surface 3. > > > > > > link: https://bugzilla.redhat.com/show_bug.cgi?id=1622695 > > > > > > Signed-off-by: Benjamin Tissoires > > > > I agree we should just do this everywhere: > > > > Acked-by: Hans de Goede > > Jiri, please hold with this patch, Canonical might 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
On Mon, 3 Sep 2018, Benjamin Tissoires wrote: > > > The spec states that the HID devices should allow > > > the host to query the HID descriptor at any time. > > > > > > Some devices require the HID descriptor to be set > > > on resume, or they will fail. > > > > > > Instead of having a growing list of blacklisted devices > > > make the call part of the general resume process > > > so we can remove this list. > > > > > > Tested on a Dell XPS 9360 and a Surface 3. > > > > > > link: https://bugzilla.redhat.com/show_bug.cgi?id=1622695 > > > > > > Signed-off-by: Benjamin Tissoires > > > > I agree we should just do this everywhere: > > > > Acked-by: Hans de Goede > > Jiri, please hold with this patch, Canonical might 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 insufficient to provide proper userspace-to-userpace
spectrev2 protection, as any process can poison branch buffers before being
scheduled out, and the newly scheduled process immediately becomes spectrev2
victim.
In order to minimize the performance impact (for usecases that do require
spectrev2 protection), issue the barrier only in cases when switching between
processess where the victim can't be ptraced by the potential attacker (as in
such cases, the attacker doesn't have to bother with branch buffers at all).
Fixes: 18bf3c3ea8 ("x86/speculation: Use Indirect Branch Prediction Barrier in
context switch")
Originally-by: Tim Chen
Signed-off-by: Jiri Kosina
---
arch/x86/mm/tlb.c | 15 ++-
include/linux/ptrace.h | 3 +++
kernel/ptrace.c| 4 +++-
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index e96b99eb800c..4a9503ca173a 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -262,18 +263,14 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
* one process from doing Spectre-v2 attacks on another.
*
* As an optimization, flush indirect branches only when
-* switching into processes that disable dumping. This
-* protects high value processes like gpg, without having
-* too high performance overhead. IBPB is *expensive*!
-*
-* This will not flush branches when switching into kernel
-* threads. It will also not flush if we switch to idle
-* thread and back to the same process. It will flush if we
-* switch to a different non-dumpable process.
+* switching into a processes that can't be ptrace by the
+* current one (as in such case, attacker has much more
+* convenient way how to tamper with the next process than
+* branch buffer poisoning).
*/
if (tsk && tsk->mm &&
tsk->mm->context.ctx_id != last_ctx_id &&
- get_dumpable(tsk->mm) != SUID_DUMP_USER)
+ ___ptrace_may_access(tsk, current, PTRACE_MODE_IBPB))
indirect_branch_prediction_barrier();
if (IS_ENABLED(CONFIG_VMAP_STACK)) {
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 09744d4113fb..adab379b5456 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -64,12 +64,15 @@ extern void exit_ptrace(struct task_struct *tracer, struct
list_head *dead);
#define PTRACE_MODE_NOAUDIT0x04
#define PTRACE_MODE_FSCREDS 0x08
#define PTRACE_MODE_REALCREDS 0x10
+#define PTRACE_MODE_NOACCESS_CHK 0x20
/* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
#define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
#define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
PTRACE_MODE_REALCREDS)
+#define PTRACE_MODE_IBPB (PTRACE_MODE_ATTACH | PTRACE_MODE_NOAUDIT \
+ | PTRACE_MODE_NOACCESS_CHK | PTRACE_MODE_REALCREDS)
/**
* ptrace_may_access - check whether the caller is permitted to access
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 07ff6685ebed..b41c37f44c32 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -330,7 +330,9 @@ int ___ptrace_may_access(struct task_struct *curr, struct
task_struct *task,
!ptrace_has_cap(mm->user_ns, mode)))
return -EPERM;
- return security_ptrace_access_check(task, mode);
+ if (!(mode & PTRACE_MODE_NOACCESS_CHK))
+ return security_ptrace_access_check(task, mode);
+ return 0;
}
static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
--
Jiri Kosina
SUSE Labs
[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 mitigation autoselection is enabled (default)
After some previous discussion, this patch leaves STIBP on all the time,
as wrmsr on crossing kernel boundary is a no-no. This could perhaps later
be a bit more optimized (like disabling it in NOHZ, experiment with
disabling it in idle, etc) if needed.
Cc: sta...@vger.kernel.org
Signed-off-by: Jiri Kosina
---
arch/x86/kernel/cpu/bugs.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 40bdaea97fe7..535b006dc50d 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -325,6 +325,12 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
+static bool __init stibp_needed(void)
+{
+ return (cpu_smt_control != CPU_SMT_NOT_SUPPORTED &&
+ boot_cpu_has(X86_FEATURE_STIBP));
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -344,6 +350,12 @@ static void __init spectre_v2_select_mitigation(void)
case SPECTRE_V2_CMD_FORCE:
case SPECTRE_V2_CMD_AUTO:
+ if (stibp_needed()) {
+ /* Enable STIBP on SMT-capable systems */
+ pr_info("Spectre v2 cross-process SMT mitigation:
Enabling STIBP\n");
+ x86_spec_ctrl_base |= SPEC_CTRL_STIBP;
+ wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
+ }
if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED)) {
mode = SPECTRE_V2_IBRS_ENHANCED;
/* Force it so VMEXIT will restore correctly */
--
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 insufficient to provide proper userspace-to-userpace
spectrev2 protection, as any process can poison branch buffers before being
scheduled out, and the newly scheduled process immediately becomes spectrev2
victim.
In order to minimize the performance impact (for usecases that do require
spectrev2 protection), issue the barrier only in cases when switching between
processess where the victim can't be ptraced by the potential attacker (as in
such cases, the attacker doesn't have to bother with branch buffers at all).
Fixes: 18bf3c3ea8 ("x86/speculation: Use Indirect Branch Prediction Barrier in
context switch")
Originally-by: Tim Chen
Signed-off-by: Jiri Kosina
---
arch/x86/mm/tlb.c | 15 ++-
include/linux/ptrace.h | 3 +++
kernel/ptrace.c| 4 +++-
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index e96b99eb800c..4a9503ca173a 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -262,18 +263,14 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
* one process from doing Spectre-v2 attacks on another.
*
* As an optimization, flush indirect branches only when
-* switching into processes that disable dumping. This
-* protects high value processes like gpg, without having
-* too high performance overhead. IBPB is *expensive*!
-*
-* This will not flush branches when switching into kernel
-* threads. It will also not flush if we switch to idle
-* thread and back to the same process. It will flush if we
-* switch to a different non-dumpable process.
+* switching into a processes that can't be ptrace by the
+* current one (as in such case, attacker has much more
+* convenient way how to tamper with the next process than
+* branch buffer poisoning).
*/
if (tsk && tsk->mm &&
tsk->mm->context.ctx_id != last_ctx_id &&
- get_dumpable(tsk->mm) != SUID_DUMP_USER)
+ ___ptrace_may_access(tsk, current, PTRACE_MODE_IBPB))
indirect_branch_prediction_barrier();
if (IS_ENABLED(CONFIG_VMAP_STACK)) {
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 09744d4113fb..adab379b5456 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -64,12 +64,15 @@ extern void exit_ptrace(struct task_struct *tracer, struct
list_head *dead);
#define PTRACE_MODE_NOAUDIT0x04
#define PTRACE_MODE_FSCREDS 0x08
#define PTRACE_MODE_REALCREDS 0x10
+#define PTRACE_MODE_NOACCESS_CHK 0x20
/* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
#define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
#define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
PTRACE_MODE_REALCREDS)
+#define PTRACE_MODE_IBPB (PTRACE_MODE_ATTACH | PTRACE_MODE_NOAUDIT \
+ | PTRACE_MODE_NOACCESS_CHK | PTRACE_MODE_REALCREDS)
/**
* ptrace_may_access - check whether the caller is permitted to access
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 07ff6685ebed..b41c37f44c32 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -330,7 +330,9 @@ int ___ptrace_may_access(struct task_struct *curr, struct
task_struct *task,
!ptrace_has_cap(mm->user_ns, mode)))
return -EPERM;
- return security_ptrace_access_check(task, mode);
+ if (!(mode & PTRACE_MODE_NOACCESS_CHK))
+ return security_ptrace_access_check(task, mode);
+ return 0;
}
static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
--
Jiri Kosina
SUSE Labs
[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 mitigation autoselection is enabled (default)
After some previous discussion, this patch leaves STIBP on all the time,
as wrmsr on crossing kernel boundary is a no-no. This could perhaps later
be a bit more optimized (like disabling it in NOHZ, experiment with
disabling it in idle, etc) if needed.
Cc: sta...@vger.kernel.org
Signed-off-by: Jiri Kosina
---
arch/x86/kernel/cpu/bugs.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 40bdaea97fe7..535b006dc50d 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -325,6 +325,12 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
+static bool __init stibp_needed(void)
+{
+ return (cpu_smt_control != CPU_SMT_NOT_SUPPORTED &&
+ boot_cpu_has(X86_FEATURE_STIBP));
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -344,6 +350,12 @@ static void __init spectre_v2_select_mitigation(void)
case SPECTRE_V2_CMD_FORCE:
case SPECTRE_V2_CMD_AUTO:
+ if (stibp_needed()) {
+ /* Enable STIBP on SMT-capable systems */
+ pr_info("Spectre v2 cross-process SMT mitigation:
Enabling STIBP\n");
+ x86_spec_ctrl_base |= SPEC_CTRL_STIBP;
+ wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
+ }
if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED)) {
mode = SPECTRE_V2_IBRS_ENHANCED;
/* Force it so VMEXIT will restore correctly */
--
Jiri Kosina
SUSE Labs
[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 | 12
kernel/ptrace.c| 13 ++---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 4f36431c380b..09744d4113fb 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -87,6 +87,18 @@ extern void exit_ptrace(struct task_struct *tracer, struct
list_head *dead);
*/
extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
+/**
+ * ___ptrace_may_access - variant of ptrace_may_access that can be used
+ * between two arbitrary tasks
+ * @curr: source task
+ * @task: target task
+ * @mode: selects type of access and caller credentials
+ *
+ * Returns true on success, false on denial.
+ */
+extern int ___ptrace_may_access(struct task_struct *curr, struct task_struct
*task,
+ unsigned int mode);
+
static inline int ptrace_reparented(struct task_struct *child)
{
return !same_thread_group(child->real_parent, child->parent);
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 21fec73d45d4..07ff6685ebed 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -268,9 +268,10 @@ static int ptrace_has_cap(struct user_namespace *ns,
unsigned int mode)
}
/* Returns 0 on success, -errno on denial. */
-static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+int ___ptrace_may_access(struct task_struct *curr, struct task_struct *task,
+ unsigned int mode)
{
- const struct cred *cred = current_cred(), *tcred;
+ const struct cred *cred, *tcred;
struct mm_struct *mm;
kuid_t caller_uid;
kgid_t caller_gid;
@@ -290,9 +291,10 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
*/
/* Don't let security modules deny introspection */
- if (same_thread_group(task, current))
+ if (same_thread_group(task, curr))
return 0;
rcu_read_lock();
+ cred = __task_cred(curr);
if (mode & PTRACE_MODE_FSCREDS) {
caller_uid = cred->fsuid;
caller_gid = cred->fsgid;
@@ -331,6 +333,11 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
return security_ptrace_access_check(task, mode);
}
+static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+{
+ return ___ptrace_may_access(current, task, mode);
+}
+
bool ptrace_may_access(struct task_struct *task, unsigned int mode)
{
int err;
--
Jiri Kosina
SUSE Labs
[PATCH v2 0/3] Harden spectrev2 userspace-userspace protection
[ added a few more CCs for v2 ] Currently, linux kernel is basically not preventing userspace-userspace spectrev2 attack, because: - IBPB is basically unused (issued only for tasks that marked themselves explicitly non-dumpable, which is absolutely negligible minority of all software out there), therefore cross-process branch buffer posioning using spectrev2 is possible - STIBP is completely unused, therefore cross-process branch buffer poisoning using spectrev2 between processess running on two HT siblings thread s is possible This patchset changes IBPB semantics, so that it's now applied whenever context-switching between processess that can't use ptrace() to achieve the same. This admittedly comes with extra overhad on a context switch; systems that don't care about could disable the mitigation using nospectre_v2 boot option. The IBPB implementaion is heavily based on original patches by Tim Chen. In addition to that, we unconditionally turn STIBP on so that HT siblings always have separate branch buffers. We've been carrying IBPB implementation with the same semantics in our (SUSE) trees since january disclosure; STIBP was more or less ignored up 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/bugs.c | 12 arch/x86/mm/tlb.c | 15 ++- include/linux/ptrace.h | 15 +++ kernel/ptrace.c| 17 + 4 files changed, 46 insertions(+), 13 deletions(-) -- Jiri Kosina SUSE Labs
[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 | 12
kernel/ptrace.c| 13 ++---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 4f36431c380b..09744d4113fb 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -87,6 +87,18 @@ extern void exit_ptrace(struct task_struct *tracer, struct
list_head *dead);
*/
extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
+/**
+ * ___ptrace_may_access - variant of ptrace_may_access that can be used
+ * between two arbitrary tasks
+ * @curr: source task
+ * @task: target task
+ * @mode: selects type of access and caller credentials
+ *
+ * Returns true on success, false on denial.
+ */
+extern int ___ptrace_may_access(struct task_struct *curr, struct task_struct
*task,
+ unsigned int mode);
+
static inline int ptrace_reparented(struct task_struct *child)
{
return !same_thread_group(child->real_parent, child->parent);
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 21fec73d45d4..07ff6685ebed 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -268,9 +268,10 @@ static int ptrace_has_cap(struct user_namespace *ns,
unsigned int mode)
}
/* Returns 0 on success, -errno on denial. */
-static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+int ___ptrace_may_access(struct task_struct *curr, struct task_struct *task,
+ unsigned int mode)
{
- const struct cred *cred = current_cred(), *tcred;
+ const struct cred *cred, *tcred;
struct mm_struct *mm;
kuid_t caller_uid;
kgid_t caller_gid;
@@ -290,9 +291,10 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
*/
/* Don't let security modules deny introspection */
- if (same_thread_group(task, current))
+ if (same_thread_group(task, curr))
return 0;
rcu_read_lock();
+ cred = __task_cred(curr);
if (mode & PTRACE_MODE_FSCREDS) {
caller_uid = cred->fsuid;
caller_gid = cred->fsgid;
@@ -331,6 +333,11 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
return security_ptrace_access_check(task, mode);
}
+static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+{
+ return ___ptrace_may_access(current, task, mode);
+}
+
bool ptrace_may_access(struct task_struct *task, unsigned int mode)
{
int err;
--
Jiri Kosina
SUSE Labs
[PATCH v2 0/3] Harden spectrev2 userspace-userspace protection
[ added a few more CCs for v2 ] Currently, linux kernel is basically not preventing userspace-userspace spectrev2 attack, because: - IBPB is basically unused (issued only for tasks that marked themselves explicitly non-dumpable, which is absolutely negligible minority of all software out there), therefore cross-process branch buffer posioning using spectrev2 is possible - STIBP is completely unused, therefore cross-process branch buffer poisoning using spectrev2 between processess running on two HT siblings thread s is possible This patchset changes IBPB semantics, so that it's now applied whenever context-switching between processess that can't use ptrace() to achieve the same. This admittedly comes with extra overhad on a context switch; systems that don't care about could disable the mitigation using nospectre_v2 boot option. The IBPB implementaion is heavily based on original patches by Tim Chen. In addition to that, we unconditionally turn STIBP on so that HT siblings always have separate branch buffers. We've been carrying IBPB implementation with the same semantics in our (SUSE) trees since january disclosure; STIBP was more or less ignored up 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/bugs.c | 12 arch/x86/mm/tlb.c | 15 ++- include/linux/ptrace.h | 15 +++ kernel/ptrace.c| 17 + 4 files changed, 46 insertions(+), 13 deletions(-) -- Jiri Kosina SUSE Labs
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 feature if > > - the CPU is vulnerable to spectre v2 > - the CPU supports SMT > - spectre_v2 mitigation autoselection is enabled (default) > > After some previous discussion, this patch leaves STIBP on all the time, > as wrmsr on crossing kernel boundary is a no-no. This could perhaps later > be a bit more optimized (like disabling it in NOHZ, experiment with > disabling it in idle, etc) if needed. > > Cc: sta...@vger.kernel.org > Signed-off-by: Jiri Kosina > --- > > Let's add the most basic STIBP support, as it has been kind of lost in all > the previous noise. After some discussions with Peter, this actually makes a little sense with the IBPB implementation we currently have upstream, as that's basically never used (I thought upstream had the same what distros had -- IBPB issued in cases where tasks can't ptrace each other, but that apparently got ditched in the process for some reason). If the argument was that this is too expensive performance-wise, well, then there is nospectre_v2 for those who are fine with that. Given the fact that the attack is real, I think we should default to STIBP+IBPB in the non-ptrace-capable case. Some distros (SUSE for example) do issue the IBPB in such a way. I'll submit v2 with that later today. -- Jiri Kosina SUSE Labs
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 feature if > > - the CPU is vulnerable to spectre v2 > - the CPU supports SMT > - spectre_v2 mitigation autoselection is enabled (default) > > After some previous discussion, this patch leaves STIBP on all the time, > as wrmsr on crossing kernel boundary is a no-no. This could perhaps later > be a bit more optimized (like disabling it in NOHZ, experiment with > disabling it in idle, etc) if needed. > > Cc: sta...@vger.kernel.org > Signed-off-by: Jiri Kosina > --- > > Let's add the most basic STIBP support, as it has been kind of lost in all > the previous noise. After some discussions with Peter, this actually makes a little sense with the IBPB implementation we currently have upstream, as that's basically never used (I thought upstream had the same what distros had -- IBPB issued in cases where tasks can't ptrace each other, but that apparently got ditched in the process for some reason). If the argument was that this is too expensive performance-wise, well, then there is nospectre_v2 for those who are fine with that. Given the fact that the attack is real, I think we should default to STIBP+IBPB in the non-ptrace-capable case. Some distros (SUSE for example) do issue the IBPB in such a way. I'll submit v2 with that later today. -- Jiri Kosina SUSE Labs
Re: Access to non-RAM pages
On Sun, 2 Sep 2018, Linus Torvalds wrote:
> Which basically doesn't happen on x86 in reality. BIOSes just don't put
> MMIO right after the last page of RAM. I think this is why it only
> triggered on Xen, due to some crazy "Xen reacts badly" case where we do
> the speculation into a balloon address.
>
> So _practically_ this is just a Xen bug, nothing more.
Yeah, and Xen guys are already working on fixing that AFAIK.
> But since in _theory_ you could have MMIO abut regular RAM directly,
> it's worth maybe making sure it's purely theory.
Well, we've 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
On Sun, 2 Sep 2018, Linus Torvalds wrote:
> Which basically doesn't happen on x86 in reality. BIOSes just don't put
> MMIO right after the last page of RAM. I think this is why it only
> triggered on Xen, due to some crazy "Xen reacts badly" case where we do
> the speculation into a balloon address.
>
> So _practically_ this is just a Xen bug, nothing more.
Yeah, and Xen guys are already working on fixing that AFAIK.
> But since in _theory_ you could have MMIO abut regular RAM directly,
> it's worth maybe making sure it's purely theory.
Well, we've 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
On Sat, 1 Sep 2018, Al Viro wrote: > IMO that's crap. In absolute majority of cases there is a guaranteed gap > between the end of accessed object and the next page boundary. So if that's the case, you're absolutely right. But I am unable to find any such guarantee in our current code though. Thanks, -- Jiri Kosina SUSE Labs
Re: Access to non-RAM pages
On Sat, 1 Sep 2018, Al Viro wrote: > IMO that's crap. In absolute majority of cases there is a guaranteed gap > between the end of accessed object and the next page boundary. So if that's the case, you're absolutely right. But I am unable to find any such guarantee in our current code though. Thanks, -- Jiri Kosina SUSE Labs
Re: Access to non-RAM pages
On Wed, 29 Aug 2018, Juergen Gross wrote: > While being very unlikely I still believe this is possible. Any > thoughts? So in theory we should somehow test whether the next page is some form of mmio/gart/... mapping, but I guess that by itself would kill the performance advantage of the whole load_unaligned_zeropad() trick. And yes, the sideffects of reading from mmio mapping is a real thing -- see for example the issue fixed by 2a3e83c6f9. If noone has any clever idea how to work this around (I don't), I am afraid we'd have to ditch the whole DCACHE_WORD_ACCESS optimization, as it's silently dangerous. Thanks, -- Jiri Kosina SUSE Labs
Re: Access to non-RAM pages
On Wed, 29 Aug 2018, Juergen Gross wrote: > While being very unlikely I still believe this is possible. Any > thoughts? So in theory we should somehow test whether the next page is some form of mmio/gart/... mapping, but I guess that by itself would kill the performance advantage of the whole load_unaligned_zeropad() trick. And yes, the sideffects of reading from mmio mapping is a real thing -- see for example the issue fixed by 2a3e83c6f9. If noone has any clever idea how to work this around (I don't), I am afraid we'd have to ditch the whole DCACHE_WORD_ACCESS optimization, 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 mitigation autoselection is enabled (default)
After some previous discussion, this patch leaves STIBP on all the time,
as wrmsr on crossing kernel boundary is a no-no. This could perhaps later
be a bit more optimized (like disabling it in NOHZ, experiment with
disabling it in idle, etc) if needed.
Cc: sta...@vger.kernel.org
Signed-off-by: Jiri Kosina
---
Let's add the most basic STIBP support, as it has been kind of lost in all
the previous noise.
arch/x86/kernel/cpu/bugs.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 4c2313d0b9ca..02edf8a6ced7 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -325,6 +325,12 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
+static bool __init stibp_needed(void)
+{
+ return (cpu_smt_control != CPU_SMT_NOT_SUPPORTED &&
+ boot_cpu_has(X86_FEATURE_STIBP));
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -344,6 +350,12 @@ static void __init spectre_v2_select_mitigation(void)
case SPECTRE_V2_CMD_FORCE:
case SPECTRE_V2_CMD_AUTO:
+ if (stibp_needed()) {
+ /* Enable STIBP on SMT-capable systems */
+ pr_info("Spectre v2 cross-process SMT mitigation:
Enabling STIBP\n");
+ x86_spec_ctrl_base |= SPEC_CTRL_STIBP;
+ wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
+ }
if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED)) {
mode = SPECTRE_V2_IBRS_ENHANCED;
/* Force it so VMEXIT will restore correctly */
--
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 mitigation autoselection is enabled (default)
After some previous discussion, this patch leaves STIBP on all the time,
as wrmsr on crossing kernel boundary is a no-no. This could perhaps later
be a bit more optimized (like disabling it in NOHZ, experiment with
disabling it in idle, etc) if needed.
Cc: sta...@vger.kernel.org
Signed-off-by: Jiri Kosina
---
Let's add the most basic STIBP support, as it has been kind of lost in all
the previous noise.
arch/x86/kernel/cpu/bugs.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 4c2313d0b9ca..02edf8a6ced7 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -325,6 +325,12 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
+static bool __init stibp_needed(void)
+{
+ return (cpu_smt_control != CPU_SMT_NOT_SUPPORTED &&
+ boot_cpu_has(X86_FEATURE_STIBP));
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -344,6 +350,12 @@ static void __init spectre_v2_select_mitigation(void)
case SPECTRE_V2_CMD_FORCE:
case SPECTRE_V2_CMD_AUTO:
+ if (stibp_needed()) {
+ /* Enable STIBP on SMT-capable systems */
+ pr_info("Spectre v2 cross-process SMT mitigation:
Enabling STIBP\n");
+ x86_spec_ctrl_base |= SPEC_CTRL_STIBP;
+ wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
+ }
if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED)) {
mode = SPECTRE_V2_IBRS_ENHANCED;
/* Force it so VMEXIT will restore correctly */
--
Jiri Kosina
SUSE Labs
[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: Lockdep-enforce text_mutex in text_poke*()
text_poke() and text_poke_bp() must be called with text_mutex held.
Put proper lockdep anotation in place instead of just mentioning the
requirement in a comment.
Reported-by: Peter Zijlstra
Signed-off-by: Jiri Kosina
Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra (Intel)
Acked-by: Masami Hiramatsu
Cc: Andy Lutomirski
Link:
https://lkml.kernel.org/r/nycvar.yfh.7.76.1808280853520.25...@cbobk.fhfr.pm
---
arch/x86/kernel/alternative.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 014f214da581..b9d5e7c9ef43 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -684,8 +684,6 @@ void *__init_or_module text_poke_early(void *addr, const
void *opcode,
* It means the size must be writable atomically and the address must be
aligned
* in a way that permits an atomic write. It also makes sure we fit on a single
* page.
- *
- * Note: Must be called under text_mutex.
*/
void *text_poke(void *addr, const void *opcode, size_t len)
{
@@ -700,6 +698,8 @@ void *text_poke(void *addr, const void *opcode, size_t len)
*/
BUG_ON(!after_bootmem);
+ lockdep_assert_held(_mutex);
+
if (!core_kernel_text((unsigned long)addr)) {
pages[0] = vmalloc_to_page(addr);
pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
@@ -782,8 +782,6 @@ int poke_int3_handler(struct pt_regs *regs)
* - replace the first byte (int3) by the first byte of
* replacing opcode
* - sync cores
- *
- * Note: must be called under text_mutex.
*/
void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler)
{
@@ -792,6 +790,9 @@ void *text_poke_bp(void *addr, const void *opcode, size_t
len, void *handler)
bp_int3_handler = handler;
bp_int3_addr = (u8 *)addr + sizeof(int3);
bp_patching_in_progress = true;
+
+ lockdep_assert_held(_mutex);
+
/*
* Corresponding read barrier in int3 notifier for making sure the
* in_progress and handler are correctly ordered wrt. patching.
[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: Lockdep-enforce text_mutex in text_poke*()
text_poke() and text_poke_bp() must be called with text_mutex held.
Put proper lockdep anotation in place instead of just mentioning the
requirement in a comment.
Reported-by: Peter Zijlstra
Signed-off-by: Jiri Kosina
Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra (Intel)
Acked-by: Masami Hiramatsu
Cc: Andy Lutomirski
Link:
https://lkml.kernel.org/r/nycvar.yfh.7.76.1808280853520.25...@cbobk.fhfr.pm
---
arch/x86/kernel/alternative.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 014f214da581..b9d5e7c9ef43 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -684,8 +684,6 @@ void *__init_or_module text_poke_early(void *addr, const
void *opcode,
* It means the size must be writable atomically and the address must be
aligned
* in a way that permits an atomic write. It also makes sure we fit on a single
* page.
- *
- * Note: Must be called under text_mutex.
*/
void *text_poke(void *addr, const void *opcode, size_t len)
{
@@ -700,6 +698,8 @@ void *text_poke(void *addr, const void *opcode, size_t len)
*/
BUG_ON(!after_bootmem);
+ lockdep_assert_held(_mutex);
+
if (!core_kernel_text((unsigned long)addr)) {
pages[0] = vmalloc_to_page(addr);
pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
@@ -782,8 +782,6 @@ int poke_int3_handler(struct pt_regs *regs)
* - replace the first byte (int3) by the first byte of
* replacing opcode
* - sync cores
- *
- * Note: must be called under text_mutex.
*/
void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler)
{
@@ -792,6 +790,9 @@ void *text_poke_bp(void *addr, const void *opcode, size_t
len, void *handler)
bp_int3_handler = handler;
bp_int3_addr = (u8 *)addr + sizeof(int3);
bp_patching_in_progress = true;
+
+ lockdep_assert_held(_mutex);
+
/*
* Corresponding read barrier in int3 notifier for making sure the
* in_progress and handler are correctly ordered wrt. patching.
Re: [PATCH] HID: core: fix memory leak on probe
On Tue, 28 Aug 2018, Stefan Agner wrote:
> The dynamically allocted collection stack does not get freed in
> all situations. Make sure to also free the collection stack when
> using the parser in hid_open_report().
>
> Fixes: 08a8a7cf1459 ("HID: core: do not upper bound the collection stack")
> Signed-off-by: Stefan Agner
> ---
> Found with kmemleak:
>
> unreferenced object 0xc57f0700 (size 64):
> comm "kworker/0:1", pid 20, jiffies 131383 (age 28.750s)
> hex dump (first 32 bytes):
> 02 00 00 00 00 02 00 00 00 00 00 00 00 68 80 c5 .h..
> 80 07 7f c5 01 00 00 00 08 48 80 c5 08 48 80 c5 .H...H..
> backtrace:
> [<1b437483>] __kmalloc_track_caller+0x1dc/0x300
> [] krealloc+0x54/0xc0
> [] hid_parser_main+0x258/0x2c8
> [<210b9aaa>] hid_open_report+0x134/0x2ac
> [<61cd8964>] hid_generic_probe+0x20/0x38
> [] hid_device_probe+0xdc/0x13c
> [<334f035e>] really_probe+0x1d8/0x2c4
> [<351dc2c0>] driver_probe_device+0x68/0x184
> [<7e3e3d3c>] __device_attach_driver+0xa0/0xd4
> [<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
On Tue, 28 Aug 2018, Stefan Agner wrote:
> The dynamically allocted collection stack does not get freed in
> all situations. Make sure to also free the collection stack when
> using the parser in hid_open_report().
>
> Fixes: 08a8a7cf1459 ("HID: core: do not upper bound the collection stack")
> Signed-off-by: Stefan Agner
> ---
> Found with kmemleak:
>
> unreferenced object 0xc57f0700 (size 64):
> comm "kworker/0:1", pid 20, jiffies 131383 (age 28.750s)
> hex dump (first 32 bytes):
> 02 00 00 00 00 02 00 00 00 00 00 00 00 68 80 c5 .h..
> 80 07 7f c5 01 00 00 00 08 48 80 c5 08 48 80 c5 .H...H..
> backtrace:
> [<1b437483>] __kmalloc_track_caller+0x1dc/0x300
> [] krealloc+0x54/0xc0
> [] hid_parser_main+0x258/0x2c8
> [<210b9aaa>] hid_open_report+0x134/0x2ac
> [<61cd8964>] hid_generic_probe+0x20/0x38
> [] hid_device_probe+0xdc/0x13c
> [<334f035e>] really_probe+0x1d8/0x2c4
> [<351dc2c0>] driver_probe_device+0x68/0x184
> [<7e3e3d3c>] __device_attach_driver+0xa0/0xd4
> [<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
On Tue, 28 Aug 2018, Stefan Agner wrote:
> Make sure to free the custom input node name on disconnect.
>
> Cc: sta...@vger.kernel.org # v4.18+
> Fixes: c554bb045511 ("HID: input: append a suffix matching the application")
> Signed-off-by: Stefan Agner
> ---
> Found with kmemleak, after unplugging a Logitech Unifying receiver:
>
> unreferenced object 0xc2345b80 (size 64):
> comm "kworker/0:1", pid 20, jiffies 4294955181 (age 320.740s)
> hex dump (first 32 bytes):
> 4c 6f 67 69 74 65 63 68 20 55 53 42 20 52 65 63 Logitech USB Rec
> 65 69 76 65 72 20 53 79 73 74 65 6d 20 43 6f 6e eiver System Con
> backtrace:
> [<8fec5a71>] __kmalloc_track_caller+0x1dc/0x300
> [<5b926275>] kvasprintf+0x60/0xcc
> [<21fc360f>] kasprintf+0x38/0x54
> [<3b6ce9f0>] hidinput_connect+0x23a8/0x4c60
> [] hid_connect+0x30c/0x38c
> [<5a28f7c9>] hid_hw_start+0x44/0x64
> [<267d70e8>] hid_generic_probe+0x34/0x38
> [] hid_device_probe+0xdc/0x13c
> [<09414e91>] really_probe+0x1d8/0x2c4
> [] driver_probe_device+0x68/0x184
> [<1def17c8>] __device_attach_driver+0xa0/0xd4
> [] bus_for_each_drv+0x60/0xc0
> [<379d02f8>] __device_attach+0xdc/0x144
> [<7026ace5>] device_initial_probe+0x14/0x18
> [<44527d01>] bus_probe_device+0x90/0x98
> [] device_add+0x424/0x62c
>
> drivers/hid/hid-input.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 4e94ea3e280a..ac201817a2dd 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1815,6 +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
On Tue, 28 Aug 2018, Stefan Agner wrote:
> Make sure to free the custom input node name on disconnect.
>
> Cc: sta...@vger.kernel.org # v4.18+
> Fixes: c554bb045511 ("HID: input: append a suffix matching the application")
> Signed-off-by: Stefan Agner
> ---
> Found with kmemleak, after unplugging a Logitech Unifying receiver:
>
> unreferenced object 0xc2345b80 (size 64):
> comm "kworker/0:1", pid 20, jiffies 4294955181 (age 320.740s)
> hex dump (first 32 bytes):
> 4c 6f 67 69 74 65 63 68 20 55 53 42 20 52 65 63 Logitech USB Rec
> 65 69 76 65 72 20 53 79 73 74 65 6d 20 43 6f 6e eiver System Con
> backtrace:
> [<8fec5a71>] __kmalloc_track_caller+0x1dc/0x300
> [<5b926275>] kvasprintf+0x60/0xcc
> [<21fc360f>] kasprintf+0x38/0x54
> [<3b6ce9f0>] hidinput_connect+0x23a8/0x4c60
> [] hid_connect+0x30c/0x38c
> [<5a28f7c9>] hid_hw_start+0x44/0x64
> [<267d70e8>] hid_generic_probe+0x34/0x38
> [] hid_device_probe+0xdc/0x13c
> [<09414e91>] really_probe+0x1d8/0x2c4
> [] driver_probe_device+0x68/0x184
> [<1def17c8>] __device_attach_driver+0xa0/0xd4
> [] bus_for_each_drv+0x60/0xc0
> [<379d02f8>] __device_attach+0xdc/0x144
> [<7026ace5>] device_initial_probe+0x14/0x18
> [<44527d01>] bus_probe_device+0x90/0x98
> [] device_add+0x424/0x62c
>
> drivers/hid/hid-input.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 4e94ea3e280a..ac201817a2dd 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1815,6 +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
On Mon, 27 Aug 2018, Sean O'Brien wrote: > USB device > Vendor 05ac (Apple) > Device 026c (Magic Keyboard with Numeric Keypad) > > Bluetooth devices > Vendor 004c (Apple) > Device 0267 (Magic Keyboard) > Device 026c (Magic Keyboard with Numeric 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
On Mon, 27 Aug 2018, Sean O'Brien wrote: > USB device > Vendor 05ac (Apple) > Device 026c (Magic Keyboard with Numeric Keypad) > > Bluetooth devices > Vendor 004c (Apple) > Device 0267 (Magic Keyboard) > Device 026c (Magic Keyboard with Numeric 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
On Tue, 21 Aug 2018, AceLan Kao wrote: > The incomplete report flooded after S3 and touchscreen becomes > malfunctioned. > [ 1367.646244] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete report > (58/18785) > [ 1367.649471] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete report > (58/28743) > [ 1367.651092] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete report > (58/26757) > [ 1367.652658] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete report > (58/52280) > [ 1367.654287] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete 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
On Tue, 21 Aug 2018, AceLan Kao wrote: > The incomplete report flooded after S3 and touchscreen becomes > malfunctioned. > [ 1367.646244] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete report > (58/18785) > [ 1367.649471] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete report > (58/28743) > [ 1367.651092] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete report > (58/26757) > [ 1367.652658] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete report > (58/52280) > [ 1367.654287] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete 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
On Fri, 17 Aug 2018, Andreas Bosch wrote:
> Added PCI ID for Sunrise Point-H ISH.
>
> Signed-off-by: Andreas Bosch
> ---
> I hope this patch arrives correctly.
> ---
> drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
> drivers/hid/intel-ish-hid/ipc/pci-ish.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> index 97869b7410eb..da133716bed0 100644
> --- a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> +++ b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> @@ -29,6 +29,7 @@
> #define CNL_Ax_DEVICE_ID 0x9DFC
> #define GLK_Ax_DEVICE_ID 0x31A2
> #define CNL_H_DEVICE_ID 0xA37C
> +#define SPT_H_DEVICE_ID 0xA135
>
> #define REVISION_ID_CHT_A0 0x6
> #define REVISION_ID_CHT_Ax_SI 0x0
> diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> index a2c53ea3b5ed..c7b8eb32b1ea 100644
> --- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> +++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> @@ -38,6 +38,7 @@ static const struct pci_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
On Fri, 17 Aug 2018, Andreas Bosch wrote:
> Added PCI ID for Sunrise Point-H ISH.
>
> Signed-off-by: Andreas Bosch
> ---
> I hope this patch arrives correctly.
> ---
> drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
> drivers/hid/intel-ish-hid/ipc/pci-ish.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> index 97869b7410eb..da133716bed0 100644
> --- a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> +++ b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> @@ -29,6 +29,7 @@
> #define CNL_Ax_DEVICE_ID 0x9DFC
> #define GLK_Ax_DEVICE_ID 0x31A2
> #define CNL_H_DEVICE_ID 0xA37C
> +#define SPT_H_DEVICE_ID 0xA135
>
> #define REVISION_ID_CHT_A0 0x6
> #define REVISION_ID_CHT_Ax_SI 0x0
> diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> index a2c53ea3b5ed..c7b8eb32b1ea 100644
> --- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> +++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> @@ -38,6 +38,7 @@ static const struct pci_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 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 014f214da581..b9d5e7c9ef43 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -684,8 +684,6 @@ void *__init_or_module text_poke_early(void *addr, const
void *opcode,
* It means the size must be writable atomically and the address must be
aligned
* in a way that permits an atomic write. It also makes sure we fit on a single
* page.
- *
- * Note: Must be called under text_mutex.
*/
void *text_poke(void *addr, const void *opcode, size_t len)
{
@@ -700,6 +698,8 @@ void *text_poke(void *addr, const void *opcode, size_t len)
*/
BUG_ON(!after_bootmem);
+ lockdep_assert_held(_mutex);
+
if (!core_kernel_text((unsigned long)addr)) {
pages[0] = vmalloc_to_page(addr);
pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
@@ -782,8 +782,6 @@ int poke_int3_handler(struct pt_regs *regs)
* - replace the first byte (int3) by the first byte of
* replacing opcode
* - sync cores
- *
- * Note: must be called under text_mutex.
*/
void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler)
{
@@ -792,6 +790,9 @@ void *text_poke_bp(void *addr, const void *opcode, size_t
len, void *handler)
bp_int3_handler = handler;
bp_int3_addr = (u8 *)addr + sizeof(int3);
bp_patching_in_progress = true;
+
+ lockdep_assert_held(_mutex);
+
/*
* Corresponding read barrier in int3 notifier for making sure the
* in_progress and handler are correctly ordered wrt. patching.
--
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 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 014f214da581..b9d5e7c9ef43 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -684,8 +684,6 @@ void *__init_or_module text_poke_early(void *addr, const
void *opcode,
* It means the size must be writable atomically and the address must be
aligned
* in a way that permits an atomic write. It also makes sure we fit on a single
* page.
- *
- * Note: Must be called under text_mutex.
*/
void *text_poke(void *addr, const void *opcode, size_t len)
{
@@ -700,6 +698,8 @@ void *text_poke(void *addr, const void *opcode, size_t len)
*/
BUG_ON(!after_bootmem);
+ lockdep_assert_held(_mutex);
+
if (!core_kernel_text((unsigned long)addr)) {
pages[0] = vmalloc_to_page(addr);
pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
@@ -782,8 +782,6 @@ int poke_int3_handler(struct pt_regs *regs)
* - replace the first byte (int3) by the first byte of
* replacing opcode
* - sync cores
- *
- * Note: must be called under text_mutex.
*/
void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler)
{
@@ -792,6 +790,9 @@ void *text_poke_bp(void *addr, const void *opcode, size_t
len, void *handler)
bp_int3_handler = handler;
bp_int3_addr = (u8 *)addr + sizeof(int3);
bp_patching_in_progress = true;
+
+ lockdep_assert_held(_mutex);
+
/*
* Corresponding read barrier in int3 notifier for making sure the
* in_progress and handler are correctly ordered wrt. patching.
--
Jiri Kosina
SUSE Labs
[GIT PULL] livepatching
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching.git for-linus to receive livepatching updates = - code cleanups from Kamalesh Babulal = Thanks. Kamalesh Babulal (2): 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
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching.git for-linus to receive livepatching updates = - code cleanups from Kamalesh Babulal = Thanks. Kamalesh Babulal (2): 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
d.h | 7 +- include/uapi/linux/input.h | 9 +- 27 files changed, 1824 insertions(+), 748 deletions(-) create mode 100644 drivers/hid/hid-cougar.c -- Jiri Kosina SUSE Labs
[GIT PULL] HID
d.h | 7 +- include/uapi/linux/input.h | 9 +- 27 files changed, 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
On Wed, 1 Aug 2018, Anton Vasilyev wrote: > ish_dev_init() allocates 512*176 bytes memory for tx_buf and stores it at > >wr_free_list_head.link list on ish_probe(). > But there is no deallocation of this memory in ish_remove() and in > ish_probe() error path. > So current intel-ish-ipc provides 88 KB memory leak for each > probe/release. > > The patch replaces kzalloc allocation by devm_kzalloc and removes > ishtp_device *dev deallocation by kfree. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Anton 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
On Wed, 1 Aug 2018, Anton Vasilyev wrote: > ish_dev_init() allocates 512*176 bytes memory for tx_buf and stores it at > >wr_free_list_head.link list on ish_probe(). > But there is no deallocation of this memory in ish_remove() and in > ish_probe() error path. > So current intel-ish-ipc provides 88 KB memory leak for each > probe/release. > > The patch replaces kzalloc allocation by devm_kzalloc and removes > ishtp_device *dev deallocation by kfree. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Anton 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
On Wed, 18 Jul 2018, Srinivas Pandruvada wrote: > On Mehlow Xeon-E workstation, ISH PCI device is enabled but without ISH > firmware. Here the ISH device PCI device id was reused for some non Linux > storage drivers. So this was not done for enabling ISH. But this has a > undesirable side effect for Linux. > > Here the ISH driver will be loaded via PCI enumeration and will try to do > reset sequence. But reset sequence will wait till timeout as there is no > real ISH firmware is present to take action. This delay will add to boot > time of Linux (This platform will still continue to boot after this > timeout). > > To avoid this boot delay we need to prevent loading of ISH drivers on > this platform. So we need to have hack to avoid treating this device as > ISH on this platform. To identify this workstation, we need some runtime > method. Luckily there are special PCI id on this workstation to > distinguish from the client version of this platform. On client version, > the ISH is supported using same PCI device id. So this change look for > the presence of PCI device IDs A309 and A30A and exit. > > Signed-off-by: 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
On Wed, 18 Jul 2018, Srinivas Pandruvada wrote: > On Mehlow Xeon-E workstation, ISH PCI device is enabled but without ISH > firmware. Here the ISH device PCI device id was reused for some non Linux > storage drivers. So this was not done for enabling ISH. But this has a > undesirable side effect for Linux. > > Here the ISH driver will be loaded via PCI enumeration and will try to do > reset sequence. But reset sequence will wait till timeout as there is no > real ISH firmware is present to take action. This delay will add to boot > time of Linux (This platform will still continue to boot after this > timeout). > > To avoid this boot delay we need to prevent loading of ISH drivers on > this platform. So we need to have hack to avoid treating this device as > ISH on this platform. To identify this workstation, we need some runtime > method. Luckily there are special PCI id on this workstation to > distinguish from the client version of this platform. On client version, > the ISH is supported using same PCI device id. So this change look for > the presence of PCI device IDs A309 and A30A and exit. > > Signed-off-by: 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: Protect against userspace-userspace spectreRSB
The article "Spectre Returns! Speculation Attacks using the Return Stack
Buffer" [1] describes two new (sub-)variants of spectrev2-like attacks,
making use solely of the RSB contents even on CPUs that don't fallback to
BTB on RSB underflow (Skylake+).
Mitigate userspace-userspace attacks by always unconditionally filling RSB on
context switch when the generic spectrev2 mitigation has been enabled.
[1] https://arxiv.org/pdf/1807.07940.pdf
Signed-off-by: Jiri Kosina
Signed-off-by: Thomas Gleixner
Reviewed-by: Josh Poimboeuf
Acked-by: Tim Chen
Cc: Konrad Rzeszutek Wilk
Cc: Borislav Petkov
Cc: David Woodhouse
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/nycvar.yfh.7.76.1807261308190@cbobk.fhfr.pm
---
arch/x86/kernel/cpu/bugs.c | 38 +++---
1 file changed, 7 insertions(+), 31 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5c0ea39311fe..bc8c43b22460 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -313,23 +313,6 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
-/* Check for Skylake-like CPUs (for RSB handling) */
-static bool __init is_skylake_era(void)
-{
- if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
- boot_cpu_data.x86 == 6) {
- switch (boot_cpu_data.x86_model) {
- case INTEL_FAM6_SKYLAKE_MOBILE:
- case INTEL_FAM6_SKYLAKE_DESKTOP:
- case INTEL_FAM6_SKYLAKE_X:
- case INTEL_FAM6_KABYLAKE_MOBILE:
- case INTEL_FAM6_KABYLAKE_DESKTOP:
- return true;
- }
- }
- return false;
-}
-
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -390,22 +373,15 @@ retpoline_auto:
pr_info("%s\n", spectre_v2_strings[mode]);
/*
-* If neither SMEP nor PTI are available, there is a risk of
-* hitting userspace addresses in the RSB after a context switch
-* from a shallow call stack to a deeper one. To prevent this fill
-* the entire RSB, even when using IBRS.
+* If spectre v2 protection has been enabled, unconditionally fill
+* RSB during a context switch; this protects against two independent
+* issues:
*
-* Skylake era CPUs have a separate issue with *underflow* of the
-* RSB, when they will predict 'ret' targets from the generic BTB.
-* The proper mitigation for this is IBRS. If IBRS is not supported
-* or deactivated in favour of retpolines the RSB fill on context
-* switch is required.
+* - RSB underflow (and switch to BTB) on Skylake+
+* - SpectreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
*/
- if ((!boot_cpu_has(X86_FEATURE_PTI) &&
-!boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
- setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
- pr_info("Spectre v2 mitigation: Filling RSB on context
switch\n");
- }
+ setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
+ pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context
switch\n");
/* Initialize Indirect Branch Prediction Barrier if supported */
if (boot_cpu_has(X86_FEATURE_IBPB)) {
[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: Protect against userspace-userspace spectreRSB
The article "Spectre Returns! Speculation Attacks using the Return Stack
Buffer" [1] describes two new (sub-)variants of spectrev2-like attacks,
making use solely of the RSB contents even on CPUs that don't fallback to
BTB on RSB underflow (Skylake+).
Mitigate userspace-userspace attacks by always unconditionally filling RSB on
context switch when the generic spectrev2 mitigation has been enabled.
[1] https://arxiv.org/pdf/1807.07940.pdf
Signed-off-by: Jiri Kosina
Signed-off-by: Thomas Gleixner
Reviewed-by: Josh Poimboeuf
Acked-by: Tim Chen
Cc: Konrad Rzeszutek Wilk
Cc: Borislav Petkov
Cc: David Woodhouse
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/nycvar.yfh.7.76.1807261308190@cbobk.fhfr.pm
---
arch/x86/kernel/cpu/bugs.c | 38 +++---
1 file changed, 7 insertions(+), 31 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5c0ea39311fe..bc8c43b22460 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -313,23 +313,6 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
-/* Check for Skylake-like CPUs (for RSB handling) */
-static bool __init is_skylake_era(void)
-{
- if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
- boot_cpu_data.x86 == 6) {
- switch (boot_cpu_data.x86_model) {
- case INTEL_FAM6_SKYLAKE_MOBILE:
- case INTEL_FAM6_SKYLAKE_DESKTOP:
- case INTEL_FAM6_SKYLAKE_X:
- case INTEL_FAM6_KABYLAKE_MOBILE:
- case INTEL_FAM6_KABYLAKE_DESKTOP:
- return true;
- }
- }
- return false;
-}
-
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -390,22 +373,15 @@ retpoline_auto:
pr_info("%s\n", spectre_v2_strings[mode]);
/*
-* If neither SMEP nor PTI are available, there is a risk of
-* hitting userspace addresses in the RSB after a context switch
-* from a shallow call stack to a deeper one. To prevent this fill
-* the entire RSB, even when using IBRS.
+* If spectre v2 protection has been enabled, unconditionally fill
+* RSB during a context switch; this protects against two independent
+* issues:
*
-* Skylake era CPUs have a separate issue with *underflow* of the
-* RSB, when they will predict 'ret' targets from the generic BTB.
-* The proper mitigation for this is IBRS. If IBRS is not supported
-* or deactivated in favour of retpolines the RSB fill on context
-* switch is required.
+* - RSB underflow (and switch to BTB) on Skylake+
+* - SpectreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
*/
- if ((!boot_cpu_has(X86_FEATURE_PTI) &&
-!boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
- setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
- pr_info("Spectre v2 mitigation: Filling RSB on context
switch\n");
- }
+ setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
+ pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context
switch\n");
/* Initialize Indirect Branch Prediction Barrier if supported */
if (boot_cpu_has(X86_FEATURE_IBPB)) {
Re: cpu_no_speculation omissions?
On Mon, 16 Jul 2018, Alan Cox wrote: > > > > At least the Centerton (late-generation Bonnell uarch) Atom family > > > > is omitted from the cpu_no_speculation table added by commit > > > > fec9434a12f3 to arch/x86/kernel/cpu/common.c. Is this intentional? > > > > Would a patch adding it and possibly other omissions be welcome? > > > > > > Probably. Dave? > > > > IIRC, Alan Cox was compiling a list on what is affected vs. not. He > > would know way better than I. > > The pre Silvermont atom cores 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?
On Mon, 16 Jul 2018, Alan Cox wrote: > > > > At least the Centerton (late-generation Bonnell uarch) Atom family > > > > is omitted from the cpu_no_speculation table added by commit > > > > fec9434a12f3 to arch/x86/kernel/cpu/common.c. Is this intentional? > > > > Would a patch adding it and possibly other omissions be welcome? > > > > > > Probably. Dave? > > > > IIRC, Alan Cox was compiling a list on what is affected vs. not. He > > would know way better than I. > > The pre Silvermont atom cores 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 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.pdf
Reviewed-by: Josh Poimboeuf
Signed-off-by: Jiri Kosina
---
v1 -> v2:
- Fixed typos/capatalization in SpectreRSB name
- Josh's Reviewed-by
arch/x86/kernel/cpu/bugs.c | 38 +++---
1 file changed, 7 insertions(+), 31 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5c0ea39311fe..bc8c43b22460 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -313,23 +313,6 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
-/* Check for Skylake-like CPUs (for RSB handling) */
-static bool __init is_skylake_era(void)
-{
- if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
- boot_cpu_data.x86 == 6) {
- switch (boot_cpu_data.x86_model) {
- case INTEL_FAM6_SKYLAKE_MOBILE:
- case INTEL_FAM6_SKYLAKE_DESKTOP:
- case INTEL_FAM6_SKYLAKE_X:
- case INTEL_FAM6_KABYLAKE_MOBILE:
- case INTEL_FAM6_KABYLAKE_DESKTOP:
- return true;
- }
- }
- return false;
-}
-
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -390,22 +373,15 @@ static void __init spectre_v2_select_mitigation(void)
pr_info("%s\n", spectre_v2_strings[mode]);
/*
-* If neither SMEP nor PTI are available, there is a risk of
-* hitting userspace addresses in the RSB after a context switch
-* from a shallow call stack to a deeper one. To prevent this fill
-* the entire RSB, even when using IBRS.
+* If spectre v2 protection has been enabled, unconditionally fill
+* RSB during a context switch; this protects against two independent
+* issues:
*
-* Skylake era CPUs have a separate issue with *underflow* of the
-* RSB, when they will predict 'ret' targets from the generic BTB.
-* The proper mitigation for this is IBRS. If IBRS is not supported
-* or deactivated in favour of retpolines the RSB fill on context
-* switch is required.
+* - RSB underflow (and switch to BTB) on Skylake+
+* - SpectreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
*/
- if ((!boot_cpu_has(X86_FEATURE_PTI) &&
-!boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
- setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
- pr_info("Spectre v2 mitigation: Filling RSB on context
switch\n");
- }
+ setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
+ pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context
switch\n");
/* Initialize Indirect Branch Prediction Barrier if supported */
if (boot_cpu_has(X86_FEATURE_IBPB)) {
--
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 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.pdf
Reviewed-by: Josh Poimboeuf
Signed-off-by: Jiri Kosina
---
v1 -> v2:
- Fixed typos/capatalization in SpectreRSB name
- Josh's Reviewed-by
arch/x86/kernel/cpu/bugs.c | 38 +++---
1 file changed, 7 insertions(+), 31 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5c0ea39311fe..bc8c43b22460 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -313,23 +313,6 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
-/* Check for Skylake-like CPUs (for RSB handling) */
-static bool __init is_skylake_era(void)
-{
- if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
- boot_cpu_data.x86 == 6) {
- switch (boot_cpu_data.x86_model) {
- case INTEL_FAM6_SKYLAKE_MOBILE:
- case INTEL_FAM6_SKYLAKE_DESKTOP:
- case INTEL_FAM6_SKYLAKE_X:
- case INTEL_FAM6_KABYLAKE_MOBILE:
- case INTEL_FAM6_KABYLAKE_DESKTOP:
- return true;
- }
- }
- return false;
-}
-
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -390,22 +373,15 @@ static void __init spectre_v2_select_mitigation(void)
pr_info("%s\n", spectre_v2_strings[mode]);
/*
-* If neither SMEP nor PTI are available, there is a risk of
-* hitting userspace addresses in the RSB after a context switch
-* from a shallow call stack to a deeper one. To prevent this fill
-* the entire RSB, even when using IBRS.
+* If spectre v2 protection has been enabled, unconditionally fill
+* RSB during a context switch; this protects against two independent
+* issues:
*
-* Skylake era CPUs have a separate issue with *underflow* of the
-* RSB, when they will predict 'ret' targets from the generic BTB.
-* The proper mitigation for this is IBRS. If IBRS is not supported
-* or deactivated in favour of retpolines the RSB fill on context
-* switch is required.
+* - RSB underflow (and switch to BTB) on Skylake+
+* - SpectreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
*/
- if ((!boot_cpu_has(X86_FEATURE_PTI) &&
-!boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
- setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
- pr_info("Spectre v2 mitigation: Filling RSB on context
switch\n");
- }
+ setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
+ pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context
switch\n");
/* Initialize Indirect Branch Prediction Barrier if supported */
if (boot_cpu_has(X86_FEATURE_IBPB)) {
--
Jiri Kosina
SUSE Labs
Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB
On Wed, 25 Jul 2018, Linus Torvalds wrote: > > Mitigate userspace-userspace attacks by always unconditionally filling RSB > > on > > context switch when generic spectrev2 mitigation has been enabled. > > Shouldn't this also do something like > > x86_spec_ctrl_base |= x86_spec_ctrl_mask & SPEC_CTRL_STIBP; > > if we have HT enabled? So IIUC your comment is not really tightly related to spectreRSB, is it? If you're making a more general remark about things that we'd also have to do in order to improve userspace-userspace spectrev2 prevention, then I agree. It probably wouldn't be as simple as adding it to x86_spec_ctrl_base I think though, as the VM switching also has to save/restore it properly (the same way we handle SSBD). So I'd rather handle this separately, as it really is in principle a completely different protection. 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
On Wed, 25 Jul 2018, Linus Torvalds wrote: > > Mitigate userspace-userspace attacks by always unconditionally filling RSB > > on > > context switch when generic spectrev2 mitigation has been enabled. > > Shouldn't this also do something like > > x86_spec_ctrl_base |= x86_spec_ctrl_mask & SPEC_CTRL_STIBP; > > if we have HT enabled? So IIUC your comment is not really tightly related to spectreRSB, is it? If you're making a more general remark about things that we'd also have to do in order to improve userspace-userspace spectrev2 prevention, then I agree. It probably wouldn't be as simple as adding it to x86_spec_ctrl_base I think though, as the VM switching also has to save/restore it properly (the same way we handle SSBD). So I'd rather handle this separately, as it really is in principle a completely different protection. 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
On Wed, 25 Jul 2018, Josh Poimboeuf wrote: > > 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 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.pdf > > > > Signed-off-by: Jiri Kosina > > While I generally agree with this patch, isn't it odd that we would do > RSB filling on every context switch, but almost never do IBPB? Yeah, I have actually been wondering exactly the same, but that's what we have been doing so far on SKL+, so I didn't really want to mix this aspect in. I actually believe that in the name of consistency we should've been doing the RSB fills under the same conditions we're issuing IBPB even on SKL+; I can resend a patch that re-adjusts that, if that's the consensus. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB
On Wed, 25 Jul 2018, Josh Poimboeuf wrote: > > 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 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.pdf > > > > Signed-off-by: Jiri Kosina > > While I generally agree with this patch, isn't it odd that we would do > RSB filling on every context switch, but almost never do IBPB? Yeah, I have actually been wondering exactly the same, but that's what we have been doing so far on SKL+, so I didn't really want to mix this aspect in. I actually believe that in the name of consistency we should've been doing the RSB fills under the same conditions we're issuing IBPB even on SKL+; I can resend a patch that re-adjusts that, if that's the consensus. Thanks, -- Jiri Kosina SUSE Labs
[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 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.pdf
Signed-off-by: Jiri Kosina
---
Note: this doesn't address the potential 'userspace-kernelspace' (maked as no.
4 in the article) attack variant. Mitigating that would require either filling
RSB on every kernel entry (as one of the very early Tim Chen's patches did as
part of spectrev2 mitigation proposal), or somehow (persumably throuhg objtool
or runtime ftrace-based counting) control the unmatched returns in the kernel;
and it's not yet clear whether this attack is practical at all in the first
place.
arch/x86/kernel/cpu/bugs.c | 38 +++---
1 file changed, 7 insertions(+), 31 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5c0ea39311fe..5ae0c12390cd 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -313,23 +313,6 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
-/* Check for Skylake-like CPUs (for RSB handling) */
-static bool __init is_skylake_era(void)
-{
- if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
- boot_cpu_data.x86 == 6) {
- switch (boot_cpu_data.x86_model) {
- case INTEL_FAM6_SKYLAKE_MOBILE:
- case INTEL_FAM6_SKYLAKE_DESKTOP:
- case INTEL_FAM6_SKYLAKE_X:
- case INTEL_FAM6_KABYLAKE_MOBILE:
- case INTEL_FAM6_KABYLAKE_DESKTOP:
- return true;
- }
- }
- return false;
-}
-
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -390,22 +373,15 @@ static void __init spectre_v2_select_mitigation(void)
pr_info("%s\n", spectre_v2_strings[mode]);
/*
-* If neither SMEP nor PTI are available, there is a risk of
-* hitting userspace addresses in the RSB after a context switch
-* from a shallow call stack to a deeper one. To prevent this fill
-* the entire RSB, even when using IBRS.
+* If spectre v2 protection has been enabled, unconditionally fill
+* RSB during a context switch; this protects against two independent
+* issues:
*
-* Skylake era CPUs have a separate issue with *underflow* of the
-* RSB, when they will predict 'ret' targets from the generic BTB.
-* The proper mitigation for this is IBRS. If IBRS is not supported
-* or deactivated in favour of retpolines the RSB fill on context
-* switch is required.
+* - RSB underflow (and switch to BTB) on Skylake+
+* - sepctreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
*/
- if ((!boot_cpu_has(X86_FEATURE_PTI) &&
-!boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
- setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
- pr_info("Spectre v2 mitigation: Filling RSB on context
switch\n");
- }
+ setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
+ pr_info("Spectre v2 / spectreRSB mitigation: Filling RSB on context
switch\n");
/* Initialize Indirect Branch Prediction Barrier if supported */
if (boot_cpu_has(X86_FEATURE_IBPB)) {
--
Jiri Kosina
SUSE Labs
[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 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.pdf
Signed-off-by: Jiri Kosina
---
Note: this doesn't address the potential 'userspace-kernelspace' (maked as no.
4 in the article) attack variant. Mitigating that would require either filling
RSB on every kernel entry (as one of the very early Tim Chen's patches did as
part of spectrev2 mitigation proposal), or somehow (persumably throuhg objtool
or runtime ftrace-based counting) control the unmatched returns in the kernel;
and it's not yet clear whether this attack is practical at all in the first
place.
arch/x86/kernel/cpu/bugs.c | 38 +++---
1 file changed, 7 insertions(+), 31 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5c0ea39311fe..5ae0c12390cd 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -313,23 +313,6 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
return cmd;
}
-/* Check for Skylake-like CPUs (for RSB handling) */
-static bool __init is_skylake_era(void)
-{
- if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
- boot_cpu_data.x86 == 6) {
- switch (boot_cpu_data.x86_model) {
- case INTEL_FAM6_SKYLAKE_MOBILE:
- case INTEL_FAM6_SKYLAKE_DESKTOP:
- case INTEL_FAM6_SKYLAKE_X:
- case INTEL_FAM6_KABYLAKE_MOBILE:
- case INTEL_FAM6_KABYLAKE_DESKTOP:
- return true;
- }
- }
- return false;
-}
-
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -390,22 +373,15 @@ static void __init spectre_v2_select_mitigation(void)
pr_info("%s\n", spectre_v2_strings[mode]);
/*
-* If neither SMEP nor PTI are available, there is a risk of
-* hitting userspace addresses in the RSB after a context switch
-* from a shallow call stack to a deeper one. To prevent this fill
-* the entire RSB, even when using IBRS.
+* If spectre v2 protection has been enabled, unconditionally fill
+* RSB during a context switch; this protects against two independent
+* issues:
*
-* Skylake era CPUs have a separate issue with *underflow* of the
-* RSB, when they will predict 'ret' targets from the generic BTB.
-* The proper mitigation for this is IBRS. If IBRS is not supported
-* or deactivated in favour of retpolines the RSB fill on context
-* switch is required.
+* - RSB underflow (and switch to BTB) on Skylake+
+* - sepctreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
*/
- if ((!boot_cpu_has(X86_FEATURE_PTI) &&
-!boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
- setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
- pr_info("Spectre v2 mitigation: Filling RSB on context
switch\n");
- }
+ setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
+ pr_info("Spectre v2 / spectreRSB mitigation: Filling RSB on context
switch\n");
/* Initialize Indirect Branch Prediction Barrier if supported */
if (boot_cpu_has(X86_FEATURE_IBPB)) {
--
Jiri Kosina
SUSE Labs
Re: [PATCH] livepatch: Validate module/old func name length
On Fri, 20 Jul 2018, Kamalesh Babulal wrote: > livepatch module author can pass module name/old function name with more > than the defined character limit. With obj->name length greater than > MODULE_NAME_LEN, the livepatch module gets loaded but waits forever on > the module specified by obj->name to be loaded. It also populates a /sys > directory with an untruncated object name. > > In the case of funcs->old_name length greater then KSYM_NAME_LEN, it > would not match against any of the symbol table entries. Instead loop > through the symbol table 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-by: Kamalesh Babulal Applied, thanks. -- Jiri Kosina SUSE Labs
Re: [PATCH] livepatch: Validate module/old func name length
On Fri, 20 Jul 2018, Kamalesh Babulal wrote: > livepatch module author can pass module name/old function name with more > than the defined character limit. With obj->name length greater than > MODULE_NAME_LEN, the livepatch module gets loaded but waits forever on > the module specified by obj->name to be loaded. It also populates a /sys > directory with an untruncated object name. > > In the case of funcs->old_name length greater then KSYM_NAME_LEN, it > would not match against any of the symbol table entries. Instead loop > through the symbol table 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-by: Kamalesh Babulal Applied, thanks. -- 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 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
On Mon, 2 Jul 2018, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/hid/hid-roccat-kone.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/hid/hid-roccat-kone.c b/drivers/hid/hid-roccat-kone.c > index bf4675a..c4dd616 100644 > --- a/drivers/hid/hid-roccat-kone.c > +++ b/drivers/hid/hid-roccat-kone.c > @@ -783,6 +783,7 @@ static void kone_keep_values_up_to_date(struct > kone_device *kone, > case kone_mouse_event_switch_profile: > kone->actual_dpi = kone->profiles[event->value - 1]. > startup_dpi; > + /* fall through */ > case kone_mouse_event_osd_profile: > kone->actual_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
On Mon, 2 Jul 2018, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/hid/hid-roccat-kone.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/hid/hid-roccat-kone.c b/drivers/hid/hid-roccat-kone.c > index bf4675a..c4dd616 100644 > --- a/drivers/hid/hid-roccat-kone.c > +++ b/drivers/hid/hid-roccat-kone.c > @@ -783,6 +783,7 @@ static void kone_keep_values_up_to_date(struct > kone_device *kone, > case kone_mouse_event_switch_profile: > kone->actual_dpi = kone->profiles[event->value - 1]. > startup_dpi; > + /* fall through */ > case kone_mouse_event_osd_profile: > kone->actual_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
On Mon, 2 Jul 2018, Colin King wrote: > From: Colin Ian King > > Variable num_frags is being assigned but is never used hence it is > redundant and can be removed. > > Cleans up clang warning: > warning: variable 'num_frags' set but not used [-Wunused-but-set-variable] > > Signed-off-by: Colin Ian King Applied, thanks. -- Jiri Kosina SUSE Labs
Re: [PATCH] HID: intel-ish-hid: remove redundant variable num_frags
On Mon, 2 Jul 2018, Colin King wrote: > From: Colin Ian King > > Variable num_frags is being assigned but is never used hence it is > redundant and can be removed. > > Cleans up clang warning: > warning: variable 'num_frags' set but not used [-Wunused-but-set-variable] > > 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)
On Thu, 5 Jul 2018, jan wrote: > Thanks for your reply. However, I am confused. Pleas bear with me as this is > the very first time that I submit a patch and I followed some guidance that I > found on the internet (obviously not the correct one). > > I suppose I just need to delete the parts of the email where you write "this > doesn't go in the changelog". Yeah, please put into the patch changelog only the things that should end up in the actual commit log (the thing you see when doing git log / git show etc). > I am not sure what my signoff should 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)
On Thu, 5 Jul 2018, jan wrote: > Thanks for your reply. However, I am confused. Pleas bear with me as this is > the very first time that I submit a patch and I followed some guidance that I > found on the internet (obviously not the correct one). > > I suppose I just need to delete the parts of the email where you write "this > doesn't go in the changelog". Yeah, please put into the patch changelog only the things that should end up in the actual commit log (the thing you see when doing git log / git show etc). > I am not sure what my signoff should 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()
On Thu, 12 Jul 2018, Kamalesh Babulal wrote:
> Support for immediate flag was removed by commit d0807da78e11
> ("livepatch: Remove immediate feature"). We bail out during
> patch registration for architectures, those don't support
> reliable stack trace. Remove the check 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()
On Thu, 12 Jul 2018, Kamalesh Babulal wrote:
> Support for immediate flag was removed by commit d0807da78e11
> ("livepatch: Remove immediate feature"). We bail out during
> patch registration for architectures, those don't support
> reliable stack trace. Remove the check 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
On Wed, 11 Jul 2018, Linus Torvalds wrote: > It's the testing that worries me most. Pretty much no developers run > 32-bit any more, and I'd be most worried about the odd interactions that > might be hw-specific. Some crazy EFI mapping setup or the similar odd > case that simply requires a particular configuration or setup. > > But I guess those issues will never be found until we just spring this > all on the unsuspecting public. FWIW we shipped Joerg's 32bit KAISER kernel out to our 32bit users (on old product where we still support it) on Apr 25th already (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
On Wed, 11 Jul 2018, Linus Torvalds wrote: > It's the testing that worries me most. Pretty much no developers run > 32-bit any more, and I'd be most worried about the odd interactions that > might be hw-specific. Some crazy EFI mapping setup or the similar odd > case that simply requires a particular configuration or setup. > > But I guess those issues will never be found until we just spring this > all on the unsuspecting public. FWIW we shipped Joerg's 32bit KAISER kernel out to our 32bit users (on old product where we still support it) on Apr 25th already (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
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus to receive HID subsystem fixes: = - spectrev1 pattern fix in hiddev from Gustavo A. R. Silva - Bounds check fix for hid-debug from Daniel Rosenberg - Regression fix for HID autobinding from Benjamin Tissoires - Removal of excessive logging from i2c-hid driver from Jason Andryuk - fix specific to 2nd generation of Wacom Intuos devices from Jason Gerecke = Thanks. Benjamin Tissoires (1): HID: core: allow concurrent registration of drivers Daniel Rosenberg (1): HID: debug: check length before copy_to_user() Gustavo A. R. Silva (1): HID: hiddev: fix potential Spectre v1 Jason Andryuk (1): HID: i2c-hid: Fix "incomplete report" noise Jason Gerecke (1): HID: wacom: Correct touch maximum XY of 2nd-gen Intuos drivers/hid/hid-core.c| 5 - drivers/hid/hid-debug.c | 8 +++- drivers/hid/i2c-hid/i2c-hid.c | 2 +- drivers/hid/usbhid/hiddev.c | 11 +++ drivers/hid/wacom_wac.c | 10 -- include/linux/hid.h | 3 ++- 6 files changed, 33 insertions(+), 6 deletions(-) -- Jiri Kosina SUSE Labs
[GIT PULL] HID fixes
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus to receive HID subsystem fixes: = - spectrev1 pattern fix in hiddev from Gustavo A. R. Silva - Bounds check fix for hid-debug from Daniel Rosenberg - Regression fix for HID autobinding from Benjamin Tissoires - Removal of excessive logging from i2c-hid driver from Jason Andryuk - fix specific to 2nd generation of Wacom Intuos devices from Jason Gerecke = Thanks. Benjamin Tissoires (1): HID: core: allow concurrent registration of drivers Daniel Rosenberg (1): HID: debug: check length before copy_to_user() Gustavo A. R. Silva (1): HID: hiddev: fix potential Spectre v1 Jason Andryuk (1): HID: i2c-hid: Fix "incomplete report" noise Jason Gerecke (1): HID: wacom: Correct touch maximum XY of 2nd-gen Intuos drivers/hid/hid-core.c| 5 - drivers/hid/hid-debug.c | 8 +++- drivers/hid/i2c-hid/i2c-hid.c | 2 +- drivers/hid/usbhid/hiddev.c | 11 +++ drivers/hid/wacom_wac.c | 10 -- include/linux/hid.h | 3 ++- 6 files changed, 33 insertions(+), 6 deletions(-) -- Jiri Kosina SUSE Labs
Re: [PATCH] i2c-hid: Fix "incomplete report" noise
On Fri, 22 Jun 2018, Jason Andryuk wrote:
> Commit ac75a041048b ("HID: i2c-hid: fix size check and type usage")
> started writing messages when the ret_size is <= 2 from i2c_master_recv.
> However, my device i2c-DLL07D1 returns 2 for a short period of time
> (~0.5s) after I stop moving the pointing stick or touchpad. It varies,
> but you get ~50 messages each time which spams the log hard.
> [ 95.925055] i2c_hid i2c-DLL07D1:01: i2c_hid_get_input: incomplete report
> (83/2)
>
> This has also been observed with a i2c-ALP0017.
> [ 1781.266353] 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
On Fri, 22 Jun 2018, Jason Andryuk wrote:
> Commit ac75a041048b ("HID: i2c-hid: fix size check and type usage")
> started writing messages when the ret_size is <= 2 from i2c_master_recv.
> However, my device i2c-DLL07D1 returns 2 for a short period of time
> (~0.5s) after I stop moving the pointing stick or touchpad. It varies,
> but you get ~50 messages each time which spams the log hard.
> [ 95.925055] i2c_hid i2c-DLL07D1:01: i2c_hid_get_input: incomplete report
> (83/2)
>
> This has also been observed with a i2c-ALP0017.
> [ 1781.266353] 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()
On Tue, 3 Jul 2018, Benjamin Tissoires wrote: > > If our length is greater than the size of the buffer, we > > overflow the buffer > > > > Signed-off-by: Daniel Rosenberg > > Cc: sta...@vger.kernel.org > > --- > > Looks good: > Reviewed-by: Benjamin 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()
On Tue, 3 Jul 2018, Benjamin Tissoires wrote: > > If our length is greater than the size of the buffer, we > > overflow the buffer > > > > Signed-off-by: Daniel Rosenberg > > Cc: sta...@vger.kernel.org > > --- > > Looks good: > Reviewed-by: Benjamin 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
On Mon, 25 Jun 2018, Petr Mladek wrote: > @@ -1426,7 +1428,8 @@ static int syslog_print_all(char __user *buf, int size, > bool clear) > } > logbuf_unlock_irq(); > > - kfree(text); > + if (text) > + kfree(text); Nit: you don't need to duplicate the check kfree() is doing anyway. -- Jiri Kosina SUSE Labs
Re: [PATCH] printk: remove unnecessary kmalloc() from syslog during clear
On Mon, 25 Jun 2018, Petr Mladek wrote: > @@ -1426,7 +1428,8 @@ static int syslog_print_all(char __user *buf, int size, > bool clear) > } > logbuf_unlock_irq(); > > - kfree(text); > + if (text) > + kfree(text); Nit: you don't need to duplicate the check kfree() is doing anyway. -- Jiri Kosina SUSE Labs
Re: [PATCH] HID: core: allow concurrent registration of drivers
On Thu, 31 May 2018, Benjamin Tissoires wrote:
> Detected on the Dell XPS 9365.
> The laptop has 2 devices that benefit from the hid-generic auto-unbinding.
> When those 2 devices are presented to the userspace, udev loads both
> wacom and hid-multitouch. When this happens, the code in
> __hid_bus_reprobe_drivers() is called concurrently and the second device
> gets reprobed twice.
> An other bug in the power_supply subsystem prevent to remove the wacom
> driver if it just finished its initialization, which basically kills
> the wacom node.
>
> Fixes 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
On Thu, 31 May 2018, Benjamin Tissoires wrote:
> Detected on the Dell XPS 9365.
> The laptop has 2 devices that benefit from the hid-generic auto-unbinding.
> When those 2 devices are presented to the userspace, udev loads both
> wacom and hid-multitouch. When this happens, the code in
> __hid_bus_reprobe_drivers() is called concurrently and the second device
> gets reprobed twice.
> An other bug in the power_supply subsystem prevent to remove the wacom
> driver if it just finished its initialization, which basically kills
> the wacom node.
>
> Fixes 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
On Tue, 19 Jun 2018, rob...@suse.de wrote:
> From: Robert Munteanu
>
> The redragon asura keyboard registers two input devices. The initial
> commit d44e2fadf940 ("HID: redragon: Fix modifier keys for Redragon Asura
> Keyboard")
This should actually have been 85455dd906d.
I have fixed that, added Fixes: tag, and applied.
--
Jiri Kosina
SUSE Labs
