Re: [PATCH 6/6] s390: scrub registers on kernel entry and KVM exit
在 2018/1/19 15:57, Christian Borntraeger 写道:
On 01/19/2018 07:29 AM, QingFeng Hao wrote:
在 2018/1/17 17:48, Martin Schwidefsky 写道:
Clear all user space registers on entry to the kernel and all KVM guest
registers on KVM guest exit if the register does not contain either a
parameter or a result value.
I am not sure if I understand this but it will be safer?
It ist similar to commit 0cb5b30698fd ("kvm: vmx: Scrub hardware GPRs at
VM-exit").
The idea is to minimize potential payload channels.
Got it! thanks for your explanation!
And can we abstract the operations to be a macro like CLEAR_REG_7?
No, please.
xgr %r7,%r7
is absolutely clear what it does, a MACRO often is not.
nod, this makes sense!
--
Regards
QingFeng Hao
Re: [PATCH 6/6] s390: scrub registers on kernel entry and KVM exit
在 2018/1/19 15:57, Christian Borntraeger 写道:
On 01/19/2018 07:29 AM, QingFeng Hao wrote:
在 2018/1/17 17:48, Martin Schwidefsky 写道:
Clear all user space registers on entry to the kernel and all KVM guest
registers on KVM guest exit if the register does not contain either a
parameter or a result value.
I am not sure if I understand this but it will be safer?
It ist similar to commit 0cb5b30698fd ("kvm: vmx: Scrub hardware GPRs at
VM-exit").
The idea is to minimize potential payload channels.
Got it! thanks for your explanation!
And can we abstract the operations to be a macro like CLEAR_REG_7?
No, please.
xgr %r7,%r7
is absolutely clear what it does, a MACRO often is not.
nod, this makes sense!
--
Regards
QingFeng Hao
Re: [PATCH 6/6] s390: scrub registers on kernel entry and KVM exit
在 2018/1/17 17:48, Martin Schwidefsky 写道: Clear all user space registers on entry to the kernel and all KVM guest registers on KVM guest exit if the register does not contain either a parameter or a result value. I am not sure if I understand this but it will be safer? And can we abstract the operations to be a macro like CLEAR_REG_7? Thanks Suggested-by: Christian Borntraeger <borntrae...@de.ibm.com> Reviewed-by: Christian Borntraeger <borntrae...@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidef...@de.ibm.com> --- arch/s390/kernel/entry.S | 41 + 1 file changed, 41 insertions(+) diff --git a/arch/s390/kernel/entry.S b/arch/s390/kernel/entry.S index 2a22c03..47227d3 100644 --- a/arch/s390/kernel/entry.S +++ b/arch/s390/kernel/entry.S @@ -322,6 +322,12 @@ ENTRY(sie64a) sie_exit: lg %r14,__SF_EMPTY+8(%r15) # load guest register save area stmg%r0,%r13,0(%r14)# save guest gprs 0-13 + xgr %r0,%r0 # clear guest registers + xgr %r1,%r1 + xgr %r2,%r2 + xgr %r3,%r3 + xgr %r4,%r4 + xgr %r5,%r5 lmg %r6,%r14,__SF_GPRS(%r15)# restore kernel registers lg %r2,__SF_EMPTY+16(%r15) # return exit reason code br %r14 @@ -358,6 +364,7 @@ ENTRY(system_call) UPDATE_VTIME %r8,%r9,__LC_SYNC_ENTER_TIMER BPENTER __TI_flags(%r12),_TIF_NOBP stmg%r0,%r7,__PT_R0(%r11) + xgr %r0,%r0 mvc __PT_R8(64,%r11),__LC_SAVE_AREA_SYNC mvc __PT_PSW(16,%r11),__LC_SVC_OLD_PSW mvc __PT_INT_CODE(4,%r11),__LC_SVC_ILC @@ -640,6 +647,14 @@ ENTRY(pgm_check_handler) 4:lgr %r13,%r11 la %r11,STACK_FRAME_OVERHEAD(%r15) stmg%r0,%r7,__PT_R0(%r11) + xgr %r0,%r0 # clear user space registers + xgr %r1,%r1 + xgr %r2,%r2 + xgr %r3,%r3 + xgr %r4,%r4 + xgr %r5,%r5 + xgr %r6,%r6 + xgr %r7,%r7 mvc __PT_R8(64,%r11),__LC_SAVE_AREA_SYNC stmg%r8,%r9,__PT_PSW(%r11) mvc __PT_INT_CODE(4,%r11),__LC_PGM_ILC @@ -706,6 +721,15 @@ ENTRY(io_int_handler) lmg %r8,%r9,__LC_IO_OLD_PSW SWITCH_ASYNC __LC_SAVE_AREA_ASYNC,__LC_ASYNC_ENTER_TIMER stmg%r0,%r7,__PT_R0(%r11) + xgr %r0,%r0 # clear user space registers + xgr %r1,%r1 + xgr %r2,%r2 + xgr %r3,%r3 + xgr %r4,%r4 + xgr %r5,%r5 + xgr %r6,%r6 + xgr %r7,%r7 + xgr %r10,%r10 mvc __PT_R8(64,%r11),__LC_SAVE_AREA_ASYNC stmg%r8,%r9,__PT_PSW(%r11) mvc __PT_INT_CODE(12,%r11),__LC_SUBCHANNEL_ID @@ -924,6 +948,15 @@ ENTRY(ext_int_handler) lmg %r8,%r9,__LC_EXT_OLD_PSW SWITCH_ASYNC __LC_SAVE_AREA_ASYNC,__LC_ASYNC_ENTER_TIMER stmg%r0,%r7,__PT_R0(%r11) + xgr %r0,%r0 # clear user space registers + xgr %r1,%r1 + xgr %r2,%r2 + xgr %r3,%r3 + xgr %r4,%r4 + xgr %r5,%r5 + xgr %r6,%r6 + xgr %r7,%r7 + xgr %r10,%r10 mvc __PT_R8(64,%r11),__LC_SAVE_AREA_ASYNC stmg%r8,%r9,__PT_PSW(%r11) lghi%r1,__LC_EXT_PARAMS2 @@ -1133,6 +1166,14 @@ ENTRY(mcck_int_handler) .Lmcck_skip: lghi%r14,__LC_GPREGS_SAVE_AREA+64 stmg%r0,%r7,__PT_R0(%r11) + xgr %r0,%r0 # clear user space registers + xgr %r2,%r2 + xgr %r3,%r3 + xgr %r4,%r4 + xgr %r5,%r5 + xgr %r6,%r6 + xgr %r7,%r7 + xgr %r10,%r10 mvc __PT_R8(64,%r11),0(%r14) stmg%r8,%r9,__PT_PSW(%r11) xc __PT_FLAGS(8,%r11),__PT_FLAGS(%r11) -- Regards QingFeng Hao
Re: [PATCH 6/6] s390: scrub registers on kernel entry and KVM exit
在 2018/1/17 17:48, Martin Schwidefsky 写道: Clear all user space registers on entry to the kernel and all KVM guest registers on KVM guest exit if the register does not contain either a parameter or a result value. I am not sure if I understand this but it will be safer? And can we abstract the operations to be a macro like CLEAR_REG_7? Thanks Suggested-by: Christian Borntraeger Reviewed-by: Christian Borntraeger Signed-off-by: Martin Schwidefsky --- arch/s390/kernel/entry.S | 41 + 1 file changed, 41 insertions(+) diff --git a/arch/s390/kernel/entry.S b/arch/s390/kernel/entry.S index 2a22c03..47227d3 100644 --- a/arch/s390/kernel/entry.S +++ b/arch/s390/kernel/entry.S @@ -322,6 +322,12 @@ ENTRY(sie64a) sie_exit: lg %r14,__SF_EMPTY+8(%r15) # load guest register save area stmg%r0,%r13,0(%r14)# save guest gprs 0-13 + xgr %r0,%r0 # clear guest registers + xgr %r1,%r1 + xgr %r2,%r2 + xgr %r3,%r3 + xgr %r4,%r4 + xgr %r5,%r5 lmg %r6,%r14,__SF_GPRS(%r15)# restore kernel registers lg %r2,__SF_EMPTY+16(%r15) # return exit reason code br %r14 @@ -358,6 +364,7 @@ ENTRY(system_call) UPDATE_VTIME %r8,%r9,__LC_SYNC_ENTER_TIMER BPENTER __TI_flags(%r12),_TIF_NOBP stmg%r0,%r7,__PT_R0(%r11) + xgr %r0,%r0 mvc __PT_R8(64,%r11),__LC_SAVE_AREA_SYNC mvc __PT_PSW(16,%r11),__LC_SVC_OLD_PSW mvc __PT_INT_CODE(4,%r11),__LC_SVC_ILC @@ -640,6 +647,14 @@ ENTRY(pgm_check_handler) 4:lgr %r13,%r11 la %r11,STACK_FRAME_OVERHEAD(%r15) stmg%r0,%r7,__PT_R0(%r11) + xgr %r0,%r0 # clear user space registers + xgr %r1,%r1 + xgr %r2,%r2 + xgr %r3,%r3 + xgr %r4,%r4 + xgr %r5,%r5 + xgr %r6,%r6 + xgr %r7,%r7 mvc __PT_R8(64,%r11),__LC_SAVE_AREA_SYNC stmg%r8,%r9,__PT_PSW(%r11) mvc __PT_INT_CODE(4,%r11),__LC_PGM_ILC @@ -706,6 +721,15 @@ ENTRY(io_int_handler) lmg %r8,%r9,__LC_IO_OLD_PSW SWITCH_ASYNC __LC_SAVE_AREA_ASYNC,__LC_ASYNC_ENTER_TIMER stmg%r0,%r7,__PT_R0(%r11) + xgr %r0,%r0 # clear user space registers + xgr %r1,%r1 + xgr %r2,%r2 + xgr %r3,%r3 + xgr %r4,%r4 + xgr %r5,%r5 + xgr %r6,%r6 + xgr %r7,%r7 + xgr %r10,%r10 mvc __PT_R8(64,%r11),__LC_SAVE_AREA_ASYNC stmg%r8,%r9,__PT_PSW(%r11) mvc __PT_INT_CODE(12,%r11),__LC_SUBCHANNEL_ID @@ -924,6 +948,15 @@ ENTRY(ext_int_handler) lmg %r8,%r9,__LC_EXT_OLD_PSW SWITCH_ASYNC __LC_SAVE_AREA_ASYNC,__LC_ASYNC_ENTER_TIMER stmg%r0,%r7,__PT_R0(%r11) + xgr %r0,%r0 # clear user space registers + xgr %r1,%r1 + xgr %r2,%r2 + xgr %r3,%r3 + xgr %r4,%r4 + xgr %r5,%r5 + xgr %r6,%r6 + xgr %r7,%r7 + xgr %r10,%r10 mvc __PT_R8(64,%r11),__LC_SAVE_AREA_ASYNC stmg%r8,%r9,__PT_PSW(%r11) lghi%r1,__LC_EXT_PARAMS2 @@ -1133,6 +1166,14 @@ ENTRY(mcck_int_handler) .Lmcck_skip: lghi%r14,__LC_GPREGS_SAVE_AREA+64 stmg%r0,%r7,__PT_R0(%r11) + xgr %r0,%r0 # clear user space registers + xgr %r2,%r2 + xgr %r3,%r3 + xgr %r4,%r4 + xgr %r5,%r5 + xgr %r6,%r6 + xgr %r7,%r7 + xgr %r10,%r10 mvc __PT_R8(64,%r11),0(%r14) stmg%r8,%r9,__PT_PSW(%r11) xc __PT_FLAGS(8,%r11),__PT_FLAGS(%r11) -- Regards QingFeng Hao
Re: [PATCH 3/6] s390: add options to change branch prediction behaviour for the kernel
在 2018/1/17 17:48, Martin Schwidefsky 写道: Add the PPA instruction to the system entry and exit path to switch the kernel to a different branch prediction behaviour. The instructions are added via CPU alternatives and can be disabled with the "nospec" or the "nobp=0" kernel parameter. If the default behaviour selected with CONFIG_KERNEL_NOBP is set to "n" then the "nobp=1" parameter can be used to enable the changed kernel branch prediction. Acked-by: Christian Borntraeger <borntrae...@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidef...@de.ibm.com> --- arch/s390/Kconfig | 17 + arch/s390/include/asm/processor.h | 1 + arch/s390/kernel/alternative.c| 23 ++ arch/s390/kernel/early.c | 2 ++ arch/s390/kernel/entry.S | 50 ++- arch/s390/kernel/ipl.c| 1 + arch/s390/kernel/smp.c| 2 ++ 7 files changed, 95 insertions(+), 1 deletion(-) diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index 829c679..a818644 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -541,6 +541,23 @@ config ARCH_RANDOM If unsure, say Y. +config KERNEL_NOBP Just a question that can we add the control in proc system to enable/disable the facilities for the whole system by default? Each process can still overwrite the default setting. This may provide more flexibility for the operator to choose and debug as well without rebooting the system. e.g. echo 0 > /sys/kernel/debug/s390x/ibpb_enabled Ref: https://access.redhat.com/articles/3311301 + def_bool n + prompt "Enable modified branch prediction for the kernel by default" + help + If this option is selected the kernel will switch to a modified + branch prediction mode if the firmware interface is available. + The modified branch prediction mode improves the behaviour in + regard to speculative execution. + + With the option enabled the kernel parameter "nobp=0" or "nospec" + can be used to run the kernel in the normal branch prediction mode. + + With the option disabled the modified branch prediction mode is + enabled with the "nobp=1" kernel parameter. + + If unsure, say N. + endmenu [...] -- Regards QingFeng Hao
Re: [PATCH 3/6] s390: add options to change branch prediction behaviour for the kernel
在 2018/1/17 17:48, Martin Schwidefsky 写道: Add the PPA instruction to the system entry and exit path to switch the kernel to a different branch prediction behaviour. The instructions are added via CPU alternatives and can be disabled with the "nospec" or the "nobp=0" kernel parameter. If the default behaviour selected with CONFIG_KERNEL_NOBP is set to "n" then the "nobp=1" parameter can be used to enable the changed kernel branch prediction. Acked-by: Christian Borntraeger Signed-off-by: Martin Schwidefsky --- arch/s390/Kconfig | 17 + arch/s390/include/asm/processor.h | 1 + arch/s390/kernel/alternative.c| 23 ++ arch/s390/kernel/early.c | 2 ++ arch/s390/kernel/entry.S | 50 ++- arch/s390/kernel/ipl.c| 1 + arch/s390/kernel/smp.c| 2 ++ 7 files changed, 95 insertions(+), 1 deletion(-) diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index 829c679..a818644 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -541,6 +541,23 @@ config ARCH_RANDOM If unsure, say Y. +config KERNEL_NOBP Just a question that can we add the control in proc system to enable/disable the facilities for the whole system by default? Each process can still overwrite the default setting. This may provide more flexibility for the operator to choose and debug as well without rebooting the system. e.g. echo 0 > /sys/kernel/debug/s390x/ibpb_enabled Ref: https://access.redhat.com/articles/3311301 + def_bool n + prompt "Enable modified branch prediction for the kernel by default" + help + If this option is selected the kernel will switch to a modified + branch prediction mode if the firmware interface is available. + The modified branch prediction mode improves the behaviour in + regard to speculative execution. + + With the option enabled the kernel parameter "nobp=0" or "nospec" + can be used to run the kernel in the normal branch prediction mode. + + With the option disabled the modified branch prediction mode is + enabled with the "nobp=1" kernel parameter. + + If unsure, say N. + endmenu [...] -- Regards QingFeng Hao
Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution
在 2018/1/6 9:09, Dan Williams 写道:
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 GPZ blog [1]
and the Documentation patch in this series."
This series incorporates Mark Rutland's latest api and adds the x86
specific implementation of nospec_barrier. The
nospec_{array_ptr,ptr,barrier} helpers are then combined with a kernel
wide analysis performed by Elena Reshetova to address static analysis
reports where speculative execution on a userspace controlled value
@Elena, can I know how did you do this analysis? I mean manually or with
tool.
Thanks!
could bypass a bounds check. The patches address a precondition for the
attack discussed in the Spectre paper [2].
A consideration worth noting for reviewing these patches is to weigh the
dramatic cost of being wrong about whether a given report is exploitable
vs the overhead nospec_{array_ptr,ptr} may introduce. In other words,
lets make the bar for applying these patches be "can you prove that the
bounds check bypass is *not* exploitable". Consider that the Spectre
paper reports one example of a speculation window being ~180 cycles.
[snip]
--
Regards
QingFeng Hao
Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution
在 2018/1/6 9:09, Dan Williams 写道:
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 GPZ blog [1]
and the Documentation patch in this series."
This series incorporates Mark Rutland's latest api and adds the x86
specific implementation of nospec_barrier. The
nospec_{array_ptr,ptr,barrier} helpers are then combined with a kernel
wide analysis performed by Elena Reshetova to address static analysis
reports where speculative execution on a userspace controlled value
@Elena, can I know how did you do this analysis? I mean manually or with
tool.
Thanks!
could bypass a bounds check. The patches address a precondition for the
attack discussed in the Spectre paper [2].
A consideration worth noting for reviewing these patches is to weigh the
dramatic cost of being wrong about whether a given report is exploitable
vs the overhead nospec_{array_ptr,ptr} may introduce. In other words,
lets make the bar for applying these patches be "can you prove that the
bounds check bypass is *not* exploitable". Consider that the Spectre
paper reports one example of a speculation window being ~180 cycles.
[snip]
--
Regards
QingFeng Hao
[Question]: Are the patches for CVE-2012-4542 in upstream?
Hi, I saw the patches were tracked in https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-4542, but I couldn't find them in upstream from https://lkml.org/lkml/2013/1/24/279. Could anyone give some help on this and if they are in upstream? If yes, what are the commits? Thanks a lot! QingFeng Hao
[Question]: Are the patches for CVE-2012-4542 in upstream?
Hi, I saw the patches were tracked in https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-4542, but I couldn't find them in upstream from https://lkml.org/lkml/2013/1/24/279. Could anyone give some help on this and if they are in upstream? If yes, what are the commits? Thanks a lot! QingFeng Hao
