Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote: > From: Andi Kleen > > When access_ok fails we should always stop speculating. > Add the required barriers to the x86 access_ok macro. Honestly, this seems completely bogus. The description is

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote: > From: Andi Kleen > > When access_ok fails we should always stop speculating. > Add the required barriers to the x86 access_ok macro. Honestly, this seems completely bogus. The description is pure garbage afaik. The fact is, we have to stop

Re: [Ocfs2-devel] [PATCH v2] ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE

Hi Andrew, >>> Andrew Morton 01/06/18 4:50 AM >>> On Thu, 04 Jan 2018 23:31:12 -0700 "Gang He" wrote: > Happy new year. > Could you help to pick up this patch, which is used to fix a old patch > 1cce4df04f37. > If we have not this patch, some

Re: [Ocfs2-devel] [PATCH v2] ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE

Hi Andrew, >>> Andrew Morton 01/06/18 4:50 AM >>> On Thu, 04 Jan 2018 23:31:12 -0700 "Gang He" wrote: > Happy new year. > Could you help to pick up this patch, which is used to fix a old patch > 1cce4df04f37. > If we have not this patch, some multiple node test cases will trigger >

[PATCH v2 3/8] x86/enter: Use IBRS on syscall and interrupts

From: Andrea Arcangeli Set IBRS upon kernel entrance via syscall and interrupts. Clear it upon exit. IBRS protects against unsafe indirect branching predictions in the kernel. The NMI interrupt save/restore of IBRS state was based on Andrea Arcangeli's implementation.

[PATCH v2 3/8] x86/enter: Use IBRS on syscall and interrupts

From: Andrea Arcangeli Set IBRS upon kernel entrance via syscall and interrupts. Clear it upon exit. IBRS protects against unsafe indirect branching predictions in the kernel. The NMI interrupt save/restore of IBRS state was based on Andrea Arcangeli's implementation. Here's an explanation by

[PATCH v2 5/8] x86/idle: Disable IBRS entering idle and enable it on wakeup

Clear IBRS on idle entry and set it on idle exit into kernel on mwait. When we are in mwait, we are not running but if we leave IBRS on, it will affect the performance on the sibling hardware thread. So we disable IBRS and reenable it when we wake up. Signed-off-by: Tim Chen

[PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

From: Tim Chen From: Andrea Arcangeli There are 2 ways to control IBRS 1. At boot time noibrs kernel boot parameter will disable IBRS usage Otherwise if the above parameters are not specified, the system will enable ibrs and ibpb usage if

[PATCH v2 6/8] x86/microcode: Recheck IBRS features on microcode reload

On new microcode write, check whether IBRS is present by rescanning IBRS feature. Signed-off-by: Tim Chen --- arch/x86/include/asm/spec_ctrl.h | 1 + arch/x86/kernel/cpu/microcode/core.c | 4 arch/x86/kernel/cpu/spec_ctrl.c | 18 ++ 3

[PATCH v2 5/8] x86/idle: Disable IBRS entering idle and enable it on wakeup

Clear IBRS on idle entry and set it on idle exit into kernel on mwait. When we are in mwait, we are not running but if we leave IBRS on, it will affect the performance on the sibling hardware thread. So we disable IBRS and reenable it when we wake up. Signed-off-by: Tim Chen ---

[PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

From: Tim Chen From: Andrea Arcangeli There are 2 ways to control IBRS 1. At boot time noibrs kernel boot parameter will disable IBRS usage Otherwise if the above parameters are not specified, the system will enable ibrs and ibpb usage if the cpu supports it. 2. At run time echo 0 >

[PATCH v2 6/8] x86/microcode: Recheck IBRS features on microcode reload

On new microcode write, check whether IBRS is present by rescanning IBRS feature. Signed-off-by: Tim Chen --- arch/x86/include/asm/spec_ctrl.h | 1 + arch/x86/kernel/cpu/microcode/core.c | 4 arch/x86/kernel/cpu/spec_ctrl.c | 18 ++ 3 files changed, 15

[PATCH v2 2/8] x86/enter: MACROS to set/clear IBRS

Create macros to control IBRS. Use these macros to enable IBRS on kernel entry paths and disable IBRS on kernel exit paths. The registers rax, rcx and rdx are touched when controlling IBRS so they need to be saved when they can't be clobbered. Signed-off-by: Tim Chen

[PATCH v2 2/8] x86/enter: MACROS to set/clear IBRS

Create macros to control IBRS. Use these macros to enable IBRS on kernel entry paths and disable IBRS on kernel exit paths. The registers rax, rcx and rdx are touched when controlling IBRS so they need to be saved when they can't be clobbered. Signed-off-by: Tim Chen ---

[PATCH v2 7/8] x86: Do not use dynamic IBRS if retpoline is enabled

Don't use dynamic IBRS that toggle IBRS on entry/exit to kernel code if retpoline is used. Signed-off-by: Tim Chen --- arch/x86/kernel/cpu/spec_ctrl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kernel/cpu/spec_ctrl.c

[PATCH v2 8/8] x86: Use IBRS for firmware update path

From: David Woodhouse We are impervious to the indirect branch prediction attack with retpoline but firmware won't be, so we still need to set IBRS to protect firmware code execution when calling into firmware at runtime. Signed-off-by: David Woodhouse

[PATCH v2 7/8] x86: Do not use dynamic IBRS if retpoline is enabled

Don't use dynamic IBRS that toggle IBRS on entry/exit to kernel code if retpoline is used. Signed-off-by: Tim Chen --- arch/x86/kernel/cpu/spec_ctrl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kernel/cpu/spec_ctrl.c b/arch/x86/kernel/cpu/spec_ctrl.c index 28107a2..076c470

[PATCH v2 8/8] x86: Use IBRS for firmware update path

From: David Woodhouse We are impervious to the indirect branch prediction attack with retpoline but firmware won't be, so we still need to set IBRS to protect firmware code execution when calling into firmware at runtime. Signed-off-by: David Woodhouse Signed-off-by: Tim Chen ---

[PATCH v2 0/8] IBRS patch series

Thanks to everyone for the feedback on the initial posting. This is an updated patchset and I hope I've captured all the review comments. I've done a lot of code clean up per everyone's comments. Please let me know if I've missed something. The retpoline related changes is moved to the end of

[PATCH v2 1/8] x86/feature: Detect the x86 IBRS feature to control Speculation

cpuid ax=0x7, return rdx bit 26 to indicate presence of this feature IA32_SPEC_CTRL (0x48) IA32_SPEC_CTRL, bit0 – Indirect Branch Restricted Speculation (IBRS) If IBRS is set, near returns and near indirect jumps/calls will not allow their predicted target address to be controlled by code that

[PATCH v2 1/8] x86/feature: Detect the x86 IBRS feature to control Speculation

cpuid ax=0x7, return rdx bit 26 to indicate presence of this feature IA32_SPEC_CTRL (0x48) IA32_SPEC_CTRL, bit0 – Indirect Branch Restricted Speculation (IBRS) If IBRS is set, near returns and near indirect jumps/calls will not allow their predicted target address to be controlled by code that

[PATCH v2 0/8] IBRS patch series

Thanks to everyone for the feedback on the initial posting. This is an updated patchset and I hope I've captured all the review comments. I've done a lot of code clean up per everyone's comments. Please let me know if I've missed something. The retpoline related changes is moved to the end of

Re: [PATCH] selftests: seccomp: fix compile error seccomp_bpf

On 5 January 2018 at 22:01, Anders Roxell wrote: > aarch64-linux-gnu-gcc -Wl,-no-as-needed -Wall > -lpthread seccomp_bpf.c -o seccomp_bpf > seccomp_bpf.c: In function 'tracer_ptrace': > seccomp_bpf.c:1720:12: error: '__NR_open' undeclared > (first use in this

Re: [PATCH] selftests: seccomp: fix compile error seccomp_bpf

On 5 January 2018 at 22:01, Anders Roxell wrote: > aarch64-linux-gnu-gcc -Wl,-no-as-needed -Wall > -lpthread seccomp_bpf.c -o seccomp_bpf > seccomp_bpf.c: In function 'tracer_ptrace': > seccomp_bpf.c:1720:12: error: '__NR_open' undeclared > (first use in this function) > if (nr ==

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

Dan Williams writes: > Quoting Mark's original RFC: > > "Recently, Google Project Zero discovered several classes of attack > against speculative execution. One of these, known as variant-1, allows > explicit bounds checks to be bypassed under speculation, providing an

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

Dan Williams writes: > Quoting Mark's original RFC: > > "Recently, Google Project Zero discovered several classes of attack > against speculative execution. One of these, known as variant-1, allows > explicit bounds checks to be bypassed under speculation, providing an > arbitrary read gadget.

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

Hi, On Fri, Jan 05, 2018 at 04:00:25PM -0800, Linus Torvalds wrote: > On Fri, Jan 5, 2018 at 2:04 PM, Aaro Koskinen wrote: > > After v4.14, I've been unable to boot my AMD compilation box with the > > v4.15-rc mainline Linux. It just ends up in a silent reboot loop. > > > >

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

Hi, On Fri, Jan 05, 2018 at 04:00:25PM -0800, Linus Torvalds wrote: > On Fri, Jan 5, 2018 at 2:04 PM, Aaro Koskinen wrote: > > After v4.14, I've been unable to boot my AMD compilation box with the > > v4.15-rc mainline Linux. It just ends up in a silent reboot loop. > > > > I bisected this to: >

Re: [PATCH 12/18] Thermal/int340x: prevent bounds-check bypass via speculative execution

On Fri, Jan 5, 2018 at 5:53 PM, Srinivas Pandruvada wrote: > On Fri, 2018-01-05 at 17:10 -0800, Dan Williams wrote: >> Static analysis reports that 'trip' may be a user controlled value >> that >> is used as a data dependency to read '*temp' from the

Re: [PATCH 12/18] Thermal/int340x: prevent bounds-check bypass via speculative execution

On Fri, Jan 5, 2018 at 5:53 PM, Srinivas Pandruvada wrote: > On Fri, 2018-01-05 at 17:10 -0800, Dan Williams wrote: >> Static analysis reports that 'trip' may be a user controlled value >> that >> is used as a data dependency to read '*temp' from the 'd->aux_trips' >> array. In order to avoid

Re: [PATCH 12/18] Thermal/int340x: prevent bounds-check bypass via speculative execution

On Fri, 2018-01-05 at 17:10 -0800, Dan Williams wrote: > Static analysis reports that 'trip' may be a user controlled value > that > is used as a data dependency to read '*temp' from the 'd->aux_trips' > array.  In order to avoid potential leaks of kernel memory values, > block > speculative

[PATCH] USB: ohci: da8xx: remove clk con_id

The ohci-da8xx device only has one clock, so a con_id is not needed, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner --- drivers/usb/host/ohci-da8xx.c | 2 +- 1 file changed, 1

Re: [PATCH 12/18] Thermal/int340x: prevent bounds-check bypass via speculative execution

On Fri, 2018-01-05 at 17:10 -0800, Dan Williams wrote: > Static analysis reports that 'trip' may be a user controlled value > that > is used as a data dependency to read '*temp' from the 'd->aux_trips' > array.  In order to avoid potential leaks of kernel memory values, > block > speculative

[PATCH] USB: ohci: da8xx: remove clk con_id

The ohci-da8xx device only has one clock, so a con_id is not needed, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner --- drivers/usb/host/ohci-da8xx.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 2/2] pinctrl: qcom: Add sdm845 pinctrl driver

From: Rajendra Nayak This adds the pinctrl definitions for the TLMM of SDM845. Signed-off-by: Rajendra Nayak [bjorn: consolidated functions] Signed-off-by: Bjorn Andersson --- drivers/pinctrl/qcom/Kconfig |

[PATCH 1/2] dt-bindings: pinctrl: Add Qualcomm SDM845 TLMM binding

This adds the DeviceTree binding for the Qualcomm SDM845 TLMM block. Signed-off-by: Bjorn Andersson --- .../bindings/pinctrl/qcom,sdm845-pinctrl.txt | 176 + 1 file changed, 176 insertions(+) create mode 100644

[PATCH 1/2] dt-bindings: pinctrl: Add Qualcomm SDM845 TLMM binding

This adds the DeviceTree binding for the Qualcomm SDM845 TLMM block. Signed-off-by: Bjorn Andersson --- .../bindings/pinctrl/qcom,sdm845-pinctrl.txt | 176 + 1 file changed, 176 insertions(+) create mode 100644

[PATCH 2/2] pinctrl: qcom: Add sdm845 pinctrl driver

From: Rajendra Nayak This adds the pinctrl definitions for the TLMM of SDM845. Signed-off-by: Rajendra Nayak [bjorn: consolidated functions] Signed-off-by: Bjorn Andersson --- drivers/pinctrl/qcom/Kconfig |9 + drivers/pinctrl/qcom/Makefile |1 +

[PATCH] USB: musb: da8xx: remove clock con_id

There is only one clock for the DA8xx MUSB device, so we don't need the con_id, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner --- drivers/usb/musb/da8xx.c | 2 +- 1 file changed,

[PATCH] USB: musb: da8xx: remove clock con_id

There is only one clock for the DA8xx MUSB device, so we don't need the con_id, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner --- drivers/usb/musb/da8xx.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v4 6/7] ARM: davinci: convert to common clock framework

On 01/05/2018 04:42 AM, Sekhar Nori wrote: On Friday 05 January 2018 08:29 AM, David Lechner wrote: On 01/04/2018 11:50 AM, David Lechner wrote: On 1/4/18 6:39 AM, Sekhar Nori wrote: This is a pretty huge patch again and I hope it can be broken down. Ideally one per SoC converted and then

Re: [PATCH v4 6/7] ARM: davinci: convert to common clock framework

On 01/05/2018 04:42 AM, Sekhar Nori wrote: On Friday 05 January 2018 08:29 AM, David Lechner wrote: On 01/04/2018 11:50 AM, David Lechner wrote: On 1/4/18 6:39 AM, Sekhar Nori wrote: This is a pretty huge patch again and I hope it can be broken down. Ideally one per SoC converted and then

Re: [PATCH] leaking_addresses: add files to skip

On Fri, Jan 05, 2018 at 04:11:07PM -0800, Kees Cook wrote: > On Fri, Jan 5, 2018 at 2:59 PM, Tobin C. Harding wrote: > > Script currently times out when parsing the following files: > > > > /proc/kallsyms > > /proc/sched_debug > > /proc/PID/smaps > > Seems

Re: [PATCH] leaking_addresses: add files to skip

On Fri, Jan 05, 2018 at 04:11:07PM -0800, Kees Cook wrote: > On Fri, Jan 5, 2018 at 2:59 PM, Tobin C. Harding wrote: > > Script currently times out when parsing the following files: > > > > /proc/kallsyms > > /proc/sched_debug > > /proc/PID/smaps > > Seems like kallsyms

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On 01/05/2018 12:54 PM, Greg Kroah-Hartman wrote: On Fri, Jan 05, 2018 at 09:56:16AM -0800, Guenter Roeck wrote: On Wed, Jan 03, 2018 at 09:11:06PM +0100, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On 01/05/2018 12:54 PM, Greg Kroah-Hartman wrote: On Fri, Jan 05, 2018 at 09:56:16AM -0800, Guenter Roeck wrote: On Wed, Jan 03, 2018 at 09:11:06PM +0100, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all

[PATCH 0/2 RESEND] fix kernel-docs for struct iio_trigger

This set is a re-spin of [PATCH] iio: add kernel-doc '@owner' Patch 1 is the original patch. Adds a kernel-doc description for field @owner clearing a sphinx build warning when building kernel documentation. Patch 2 adds field identifier for @use_count. Currently this field has a

[PATCH 0/2 RESEND] fix kernel-docs for struct iio_trigger

This set is a re-spin of [PATCH] iio: add kernel-doc '@owner' Patch 1 is the original patch. Adds a kernel-doc description for field @owner clearing a sphinx build warning when building kernel documentation. Patch 2 adds field identifier for @use_count. Currently this field has a

[PATCH 1/2 RESEND] iio: add kernel-doc for field @owner

When building kernel documentation sphinx emits the following warning warning: No description found for parameter 'owner' Add description for struct member 'owner'. Signed-off-by: Tobin C. Harding --- include/linux/iio/trigger.h | 1 + 1 file changed, 1 insertion(+)

[PATCH 1/2 RESEND] iio: add kernel-doc for field @owner

When building kernel documentation sphinx emits the following warning warning: No description found for parameter 'owner' Add description for struct member 'owner'. Signed-off-by: Tobin C. Harding --- include/linux/iio/trigger.h | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 2/2 RESEND] iio: add field identifier for @use_count kernel-doc

Kernel-doc for @use_count does not currently have a field identifier. All the rest of the fields do. @use_count is used internally and should not be accessed directly by the driver so it should be marked as so. Add [INTERN] identifier to @use_count field. Signed-off-by: Tobin C. Harding

[PATCH 2/2 RESEND] iio: add field identifier for @use_count kernel-doc

Kernel-doc for @use_count does not currently have a field identifier. All the rest of the fields do. @use_count is used internally and should not be accessed directly by the driver so it should be marked as so. Add [INTERN] identifier to @use_count field. Signed-off-by: Tobin C. Harding ---

[PATCH] docs: add index entry for networking/msg_zerocopy

Currently msg_zerocopy is not included in any toctree. Sphinx emits a build warning to this effect. The other three rst files in Documentation/networking are all indexed. We can add msg_zerocopy to the toctree to enable navigation of the document via HTML kernel docs. Add msg_zerocopy to the

[PATCH] docs: add index entry for networking/msg_zerocopy

Currently msg_zerocopy is not included in any toctree. Sphinx emits a build warning to this effect. The other three rst files in Documentation/networking are all indexed. We can add msg_zerocopy to the toctree to enable navigation of the document via HTML kernel docs. Add msg_zerocopy to the

Re: platform/x86/thinkpad_acpi: Adjustments for four function implementations

On Wed, Jan 03, 2018 at 09:41:04AM +0100, SF Markus Elfring wrote: > > I understand it can be frustrating to encounter different policies > > across kernel maintainers. > > The change acceptance is varying for special transformation patterns. > > > > You'll even run in to this with maintainers

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On 01/05/2018 03:16 AM, David Woodhouse wrote: > On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote: >> >> + mutex_lock(_ctrl_mutex); >> + >> + if (enable == IBRS_DISABLED) { >> + /* disable IBRS usage */ >> + set_ibrs_disabled(); >> + if

Re: platform/x86/thinkpad_acpi: Adjustments for four function implementations

On Wed, Jan 03, 2018 at 09:41:04AM +0100, SF Markus Elfring wrote: > > I understand it can be frustrating to encounter different policies > > across kernel maintainers. > > The change acceptance is varying for special transformation patterns. > > > > You'll even run in to this with maintainers

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On 01/05/2018 03:16 AM, David Woodhouse wrote: > On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote: >> >> + mutex_lock(_ctrl_mutex); >> + >> + if (enable == IBRS_DISABLED) { >> + /* disable IBRS usage */ >> + set_ibrs_disabled(); >> + if

[PATCH 04/18] arm: implement nospec_ptr()

From: Mark Rutland This patch implements nospec_ptr() for arm, following the recommended architectural sequences for the arm and thumb instruction sets. Signed-off-by: Mark Rutland Signed-off-by: Dan Williams ---

[PATCH 04/18] arm: implement nospec_ptr()

From: Mark Rutland This patch implements nospec_ptr() for arm, following the recommended architectural sequences for the arm and thumb instruction sets. Signed-off-by: Mark Rutland Signed-off-by: Dan Williams --- arch/arm/include/asm/barrier.h | 75

[PATCH 13/18] ipv6: prevent bounds-check bypass via speculative execution

Static analysis reports that 'offset' may be a user controlled value that is used as a data dependency reading from a raw6_frag_vec buffer. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue further reads based on an

[PATCH 13/18] ipv6: prevent bounds-check bypass via speculative execution

Static analysis reports that 'offset' may be a user controlled value that is used as a data dependency reading from a raw6_frag_vec buffer. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue further reads based on an

[PATCH 18/18] userns: prevent bounds-check bypass via speculative execution

Static analysis reports that 'pos' may be a user controlled value that is used as a data dependency determining which extent to return out of 'map'. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue further reads based

[PATCH 18/18] userns: prevent bounds-check bypass via speculative execution

Static analysis reports that 'pos' may be a user controlled value that is used as a data dependency determining which extent to return out of 'map'. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue further reads based

[PATCH 16/18] net: mpls: prevent bounds-check bypass via speculative execution

Static analysis reports that 'index' may be a user controlled value that is used as a data dependency reading 'rt' from the 'platform_label' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue further reads based

[PATCH 15/18] vfs, fdtable: prevent bounds-check bypass via speculative execution

Expectedly, static analysis reports that 'fd' is a user controlled value that is used as a data dependency to read from the 'fdt->fd' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an invalid

[PATCH 17/18] udf: prevent bounds-check bypass via speculative execution

Static analysis reports that 'eahd->appAttrLocation' and 'eahd->impAttrLocation' may be a user controlled values that are used as data dependencies for calculating source and destination buffers for memmove operations. In order to avoid potential leaks of kernel memory values, block speculative

[PATCH 16/18] net: mpls: prevent bounds-check bypass via speculative execution

Static analysis reports that 'index' may be a user controlled value that is used as a data dependency reading 'rt' from the 'platform_label' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue further reads based

[PATCH 15/18] vfs, fdtable: prevent bounds-check bypass via speculative execution

Expectedly, static analysis reports that 'fd' is a user controlled value that is used as a data dependency to read from the 'fdt->fd' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an invalid

[PATCH 17/18] udf: prevent bounds-check bypass via speculative execution

Static analysis reports that 'eahd->appAttrLocation' and 'eahd->impAttrLocation' may be a user controlled values that are used as data dependencies for calculating source and destination buffers for memmove operations. In order to avoid potential leaks of kernel memory values, block speculative

[PATCH 12/18] Thermal/int340x: prevent bounds-check bypass via speculative execution

Static analysis reports that 'trip' may be a user controlled value that is used as a data dependency to read '*temp' from the 'd->aux_trips' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an

[PATCH 12/18] Thermal/int340x: prevent bounds-check bypass via speculative execution

Static analysis reports that 'trip' may be a user controlled value that is used as a data dependency to read '*temp' from the 'd->aux_trips' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an

[PATCH 11/18] cw1200: prevent bounds-check bypass via speculative execution

Static analysis reports that 'queue' may be a user controlled value that is used as a data dependency to read 'txq_params' from the 'priv->tx_queue_params.params' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could

[PATCH 11/18] cw1200: prevent bounds-check bypass via speculative execution

Static analysis reports that 'queue' may be a user controlled value that is used as a data dependency to read 'txq_params' from the 'priv->tx_queue_params.params' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could

[PATCH 06/18] x86, barrier: stop speculation for failed access_ok

From: Andi Kleen When access_ok fails we should always stop speculating. Add the required barriers to the x86 access_ok macro. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Arnd Bergmann

[PATCH 09/18] p54: prevent bounds-check bypass via speculative execution

Static analysis reports that 'queue' may be a user controlled value that is used as a data dependency to read from the 'priv->qos_params' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an

[PATCH 06/18] x86, barrier: stop speculation for failed access_ok

From: Andi Kleen When access_ok fails we should always stop speculating. Add the required barriers to the x86 access_ok macro. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Arnd Bergmann Cc: x...@kernel.org Signed-off-by: Andi Kleen Signed-off-by: Dan Williams ---

[PATCH 09/18] p54: prevent bounds-check bypass via speculative execution

Static analysis reports that 'queue' may be a user controlled value that is used as a data dependency to read from the 'priv->qos_params' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an

[PATCH 10/18] qla2xxx: prevent bounds-check bypass via speculative execution

Static analysis reports that 'handle' may be a user controlled value that is used as a data dependency to read 'sp' from the 'req->outstanding_cmds' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based

[PATCH 14/18] ipv4: prevent bounds-check bypass via speculative execution

Static analysis reports that 'offset' may be a user controlled value that is used as a data dependency reading from a raw_frag_vec buffer. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue further reads based on an

[PATCH 05/18] x86: implement nospec_barrier()

The new speculative execution barrier, nospec_barrier(), ensures that any userspace controllable speculation doesn't cross the boundary. Any user observable speculative activity on this CPU thread before this point either completes, reaches a state it can no longer cause an observable activity,

[PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

Static analysis reports that 'queue' may be a user controlled value that is used as a data dependency to read from the 'ar9170_qmap' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an invalid

[PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution

Static analysis reports that 'index' may be a user controlled value that is used as a data dependency to read 'pin' from the 'selector->baSourceID' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based

[PATCH 10/18] qla2xxx: prevent bounds-check bypass via speculative execution

Static analysis reports that 'handle' may be a user controlled value that is used as a data dependency to read 'sp' from the 'req->outstanding_cmds' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based

[PATCH 14/18] ipv4: prevent bounds-check bypass via speculative execution

Static analysis reports that 'offset' may be a user controlled value that is used as a data dependency reading from a raw_frag_vec buffer. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue further reads based on an

[PATCH 05/18] x86: implement nospec_barrier()

The new speculative execution barrier, nospec_barrier(), ensures that any userspace controllable speculation doesn't cross the boundary. Any user observable speculative activity on this CPU thread before this point either completes, reaches a state it can no longer cause an observable activity,

[PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

Static analysis reports that 'queue' may be a user controlled value that is used as a data dependency to read from the 'ar9170_qmap' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an invalid

[PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution

Static analysis reports that 'index' may be a user controlled value that is used as a data dependency to read 'pin' from the 'selector->baSourceID' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based

[PATCH 02/18] Documentation: document nospec helpers

From: Mark Rutland Document the rationale and usage of the new nospec*() helpers. Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Cc: Dan Williams Cc: Jonathan Corbet Cc: Peter

[PATCH 02/18] Documentation: document nospec helpers

From: Mark Rutland Document the rationale and usage of the new nospec*() helpers. Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Cc: Dan Williams Cc: Jonathan Corbet Cc: Peter Zijlstra Signed-off-by: Dan Williams --- Documentation/speculation.txt | 166

[PATCH 00/18] prevent bounds-check bypass via speculative execution

Quoting Mark's original RFC: "Recently, Google Project Zero discovered several classes of attack against speculative execution. One of these, known as variant-1, allows explicit bounds checks to be bypassed under speculation, providing an arbitrary read gadget. Further details can be found on the

[PATCH 00/18] prevent bounds-check bypass via speculative execution

Quoting Mark's original RFC: "Recently, Google Project Zero discovered several classes of attack against speculative execution. One of these, known as variant-1, allows explicit bounds checks to be bypassed under speculation, providing an arbitrary read gadget. Further details can be found on the

[PATCH 03/18] arm64: implement nospec_ptr()

From: Mark Rutland This patch implements nospec_ptr() for arm64, following the recommended architectural sequence. Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Cc: Dan Williams Cc: Peter

[PATCH 03/18] arm64: implement nospec_ptr()

From: Mark Rutland This patch implements nospec_ptr() for arm64, following the recommended architectural sequence. Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Cc: Dan Williams Cc: Peter Zijlstra Signed-off-by: Dan Williams --- arch/arm64/include/asm/barrier.h | 55

[PATCH 01/18] asm-generic/barrier: add generic nospec helpers

From: Mark Rutland Under speculation, CPUs may mis-predict branches in bounds checks. Thus, memory accesses under a bounds check may be speculated even if the bounds check fails, providing a primitive for building a side channel. This patch adds helpers which can be used

[PATCH 01/18] asm-generic/barrier: add generic nospec helpers

From: Mark Rutland Under speculation, CPUs may mis-predict branches in bounds checks. Thus, memory accesses under a bounds check may be speculated even if the bounds check fails, providing a primitive for building a side channel. This patch adds helpers which can be used to inhibit the use of

Re: [PATCH] ACPI / WMI: Call acpi_wmi_init() later

On Sat, Jan 06, 2018 at 12:30:23AM +0100, Rafael J. Wysocki wrote: > On Wed, Jan 3, 2018 at 12:49 PM, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Calling acpi_wmi_init() at the subsys_initcall() level causes ordering > > issues to

Re: [PATCH] ACPI / WMI: Call acpi_wmi_init() later

On Sat, Jan 06, 2018 at 12:30:23AM +0100, Rafael J. Wysocki wrote: > On Wed, Jan 3, 2018 at 12:49 PM, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Calling acpi_wmi_init() at the subsys_initcall() level causes ordering > > issues to appear on some systems and they are difficult to

Re: [PATCH 4.4 00/37] 4.4.110-stable review

Hi Hugh, Thank you very much for your very thoughtful input. I quiet positive this problem is PTI regression, because exactly the same problem I see with kernel 4.1 to which I back-ported all the necessary PTI patches from 4.4.110. I will provide this thread with more information as I

Re: [PATCH 4.4 00/37] 4.4.110-stable review

Hi Hugh, Thank you very much for your very thoughtful input. I quiet positive this problem is PTI regression, because exactly the same problem I see with kernel 4.1 to which I back-ported all the necessary PTI patches from 4.4.110. I will provide this thread with more information as I

<    1   2   3   4   5   6   7   8   9   10   >