Re: Spectre mitigation doesn't seem to work at all?!
On 06/04/2018 at 04:12 PM Alan Cox wrote: >> A malicious program most probably won't care about that. Therefore, my >> next question is: which memory regions can be exploited by a malicious >> program? The complete physical memory or only the memory provided to the >> malicious program? Should be the latter if this approach should have any >> impact. > > Spectre is not about memory regions. It's about speculative execution > leaving measurable footprints. What footprints you leave depend upon what > code you are executing. Thus the question becomes 'what can the target > access'. > > In order to attack something you need both a way to influence the code > concerned and a way to measure it. In addition it needs to have some > secret you want. > > In practice that usually means something on the same system with its own > memory space/privilege level. The usual cases then are user<->kernel and > managed application<->runtime. Would this be a practical test case: Gather keys and passwords used by a ssh login by running a malicious program in parallel to sshd as another ordinary user w/o root access. Thanks, Andreas
Re: Spectre mitigation doesn't seem to work at all?!
On 06/04/2018 at 04:12 PM Alan Cox wrote: >> A malicious program most probably won't care about that. Therefore, my >> next question is: which memory regions can be exploited by a malicious >> program? The complete physical memory or only the memory provided to the >> malicious program? Should be the latter if this approach should have any >> impact. > > Spectre is not about memory regions. It's about speculative execution > leaving measurable footprints. What footprints you leave depend upon what > code you are executing. Thus the question becomes 'what can the target > access'. > > In order to attack something you need both a way to influence the code > concerned and a way to measure it. In addition it needs to have some > secret you want. > > In practice that usually means something on the same system with its own > memory space/privilege level. The usual cases then are user<->kernel and > managed application<->runtime. Would this be a practical test case: Gather keys and passwords used by a ssh login by running a malicious program in parallel to sshd as another ordinary user w/o root access. Thanks, Andreas
Re: Spectre mitigation doesn't seem to work at all?!
On Mon, 4 Jun 2018, Andreas Hartmann wrote: > Sorry for a ping - but I think the behavior shown below should really be > investigated! There is not much to investigate ... > > I tested the spectre mitigation of different machines and kernels with > > https://github.com/crozone/SpectrePoC > > > > You can see the results below. > > My question: Did I miss something? Yes. > > My expectation was, that on base of the output of > > /sys/devices/system/cpu/vulnerabilities/spectre_v* as shown below the > > problem should be gone away. > > But the results seem to tell me something other ... . > > CPU: AMD Ryzen 7 1700X Eight-Core Processor > > Bios: BIOS 4011 04/19/2018 - ibpb is listed in /proc/cpuinfo > > Kernel: 4.14.44-1.1-default > > cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 > > Mitigation: Full AMD retpoline, IBPB > > cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 > > Mitigation: __user pointer sanitization Looks correct, but irrelevant. > > > > ./spectre.out > > Using a cache hit threshold of 80. > > Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED This is the info you missed: > > INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED The whole POC is sniffing on itself and it allows you to compile with different mitigation enabled or disabled. You disabled both. So it's expected to succeed. It does not matter at all which mitigations the kernel has enabled because they do not affect the user space programm attacking itself. It's just a demonstrator of the attack technology along with options to demonstrate the effectiveness of mitigation strategies. Thanks, tglx
Re: Spectre mitigation doesn't seem to work at all?!
On Mon, 4 Jun 2018, Andreas Hartmann wrote: > Sorry for a ping - but I think the behavior shown below should really be > investigated! There is not much to investigate ... > > I tested the spectre mitigation of different machines and kernels with > > https://github.com/crozone/SpectrePoC > > > > You can see the results below. > > My question: Did I miss something? Yes. > > My expectation was, that on base of the output of > > /sys/devices/system/cpu/vulnerabilities/spectre_v* as shown below the > > problem should be gone away. > > But the results seem to tell me something other ... . > > CPU: AMD Ryzen 7 1700X Eight-Core Processor > > Bios: BIOS 4011 04/19/2018 - ibpb is listed in /proc/cpuinfo > > Kernel: 4.14.44-1.1-default > > cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 > > Mitigation: Full AMD retpoline, IBPB > > cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 > > Mitigation: __user pointer sanitization Looks correct, but irrelevant. > > > > ./spectre.out > > Using a cache hit threshold of 80. > > Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED This is the info you missed: > > INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED The whole POC is sniffing on itself and it allows you to compile with different mitigation enabled or disabled. You disabled both. So it's expected to succeed. It does not matter at all which mitigations the kernel has enabled because they do not affect the user space programm attacking itself. It's just a demonstrator of the attack technology along with options to demonstrate the effectiveness of mitigation strategies. Thanks, tglx
Re: Spectre mitigation doesn't seem to work at all?!
> A malicious program most probably won't care about that. Therefore, my > next question is: which memory regions can be exploited by a malicious > program? The complete physical memory or only the memory provided to the > malicious program? Should be the latter if this approach should have any > impact. Spectre is not about memory regions. It's about speculative execution leaving measurable footprints. What footprints you leave depend upon what code you are executing. Thus the question becomes 'what can the target access'. In order to attack something you need both a way to influence the code concerned and a way to measure it. In addition it needs to have some secret you want. In practice that usually means something on the same system with its own memory space/privilege level. The usual cases then are user<->kernel and managed application<->runtime. Thus it's very different to meltdown style attacks. If you are actually worried about this you should probably also read up on more general cache prime/probe attacks and cache profiling (things like the ARMageddon paper are worth reading - and while it was done on ARM much of it is generic to most modern processors), as well as timing attacks. Alan
Re: Spectre mitigation doesn't seem to work at all?!
> A malicious program most probably won't care about that. Therefore, my > next question is: which memory regions can be exploited by a malicious > program? The complete physical memory or only the memory provided to the > malicious program? Should be the latter if this approach should have any > impact. Spectre is not about memory regions. It's about speculative execution leaving measurable footprints. What footprints you leave depend upon what code you are executing. Thus the question becomes 'what can the target access'. In order to attack something you need both a way to influence the code concerned and a way to measure it. In addition it needs to have some secret you want. In practice that usually means something on the same system with its own memory space/privilege level. The usual cases then are user<->kernel and managed application<->runtime. Thus it's very different to meltdown style attacks. If you are actually worried about this you should probably also read up on more general cache prime/probe attacks and cache profiling (things like the ARMageddon paper are worth reading - and while it was done on ARM much of it is generic to most modern processors), as well as timing attacks. Alan
Re: Spectre mitigation doesn't seem to work at all?!
Hello Mark, On 06/04/2018 at 11:19 AM Mark Rutland wrote: > On Mon, Jun 04, 2018 at 10:50:07AM +0200, Andreas Hartmann wrote: >> Hello Peter, >> >> thanks for your answer! I appreciate it! >> >> On 06/04/2018 at 10:15 AM Peter Zijlstra wrote: >>> On Fri, Jun 01, 2018 at 02:19:38PM +0200, Andreas Hartmann wrote: >>> I tested the spectre mitigation of different machines and kernels with https://github.com/crozone/SpectrePoC You can see the results below. >>> My question: Did I miss something? >>> >>> Yes. >>> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED >>> >>> >>> >>> The POC is a v1 on itself. V1 needs to be fixed for every individual >>> executable (worse, for every individual location in the code, and we're >>> still finding them). The kernel mitigation status for v1 only indicates >>> the kernel itself has mitigations (for some locations). >>> >>> The POC is meant to test effectiveness of these mitigations, either the >>> original LFENCE or the dependent instruction thing, but you have to >>> enable one or the other. >> >> Ok, this means every program running on the machine has to care itself >> to be spectre v1 - safe. > > Correct. Primiarily this matters for things like JITs, where untrusted code > may > be run in the same address space as sensitive data. > >> A malicious program most probably won't care about that. Therefore, my >> next question is: which memory regions can be exploited by a malicious >> program? The complete physical memory or only the memory provided to the >> malicious program? Should be the latter if this approach should have any >> impact. > > Assuming you have a CPU which is not vulnerable to meltdown / variant-3, or > you > have mitigated this, (e.g. with KPTI), a malicious program can only access > data > within its own address space. > > Spectre variant-1 alone only gives access to memory in the address space of > the > program itself. Thanks Mark! Now I've a better understanding about the effects the different vulnerabilities around Spectre and Meltdown do have and I'm now hopefully able to better estimate them. As I'm mostly using AMD-CPUs (like Ryzen 1 e.g.) for virtualization, I should be secure by default regarding unwanted global memory access from the VM to the host memory, because the Ryzen 1 CPU is not affected by Meltdown at all. Regards, Andreas
Re: Spectre mitigation doesn't seem to work at all?!
Hello Mark, On 06/04/2018 at 11:19 AM Mark Rutland wrote: > On Mon, Jun 04, 2018 at 10:50:07AM +0200, Andreas Hartmann wrote: >> Hello Peter, >> >> thanks for your answer! I appreciate it! >> >> On 06/04/2018 at 10:15 AM Peter Zijlstra wrote: >>> On Fri, Jun 01, 2018 at 02:19:38PM +0200, Andreas Hartmann wrote: >>> I tested the spectre mitigation of different machines and kernels with https://github.com/crozone/SpectrePoC You can see the results below. >>> My question: Did I miss something? >>> >>> Yes. >>> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED >>> >>> >>> >>> The POC is a v1 on itself. V1 needs to be fixed for every individual >>> executable (worse, for every individual location in the code, and we're >>> still finding them). The kernel mitigation status for v1 only indicates >>> the kernel itself has mitigations (for some locations). >>> >>> The POC is meant to test effectiveness of these mitigations, either the >>> original LFENCE or the dependent instruction thing, but you have to >>> enable one or the other. >> >> Ok, this means every program running on the machine has to care itself >> to be spectre v1 - safe. > > Correct. Primiarily this matters for things like JITs, where untrusted code > may > be run in the same address space as sensitive data. > >> A malicious program most probably won't care about that. Therefore, my >> next question is: which memory regions can be exploited by a malicious >> program? The complete physical memory or only the memory provided to the >> malicious program? Should be the latter if this approach should have any >> impact. > > Assuming you have a CPU which is not vulnerable to meltdown / variant-3, or > you > have mitigated this, (e.g. with KPTI), a malicious program can only access > data > within its own address space. > > Spectre variant-1 alone only gives access to memory in the address space of > the > program itself. Thanks Mark! Now I've a better understanding about the effects the different vulnerabilities around Spectre and Meltdown do have and I'm now hopefully able to better estimate them. As I'm mostly using AMD-CPUs (like Ryzen 1 e.g.) for virtualization, I should be secure by default regarding unwanted global memory access from the VM to the host memory, because the Ryzen 1 CPU is not affected by Meltdown at all. Regards, Andreas
Re: Spectre mitigation doesn't seem to work at all?!
On Mon, Jun 04, 2018 at 10:50:07AM +0200, Andreas Hartmann wrote: > Hello Peter, > > thanks for your answer! I appreciate it! > > On 06/04/2018 at 10:15 AM Peter Zijlstra wrote: > > On Fri, Jun 01, 2018 at 02:19:38PM +0200, Andreas Hartmann wrote: > > > >> I tested the spectre mitigation of different machines and kernels with > >> https://github.com/crozone/SpectrePoC > >> > >> You can see the results below. > > > >> My question: Did I miss something? > > > > Yes. > > > >> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > >> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > >> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > > > > > > > > The POC is a v1 on itself. V1 needs to be fixed for every individual > > executable (worse, for every individual location in the code, and we're > > still finding them). The kernel mitigation status for v1 only indicates > > the kernel itself has mitigations (for some locations). > > > > The POC is meant to test effectiveness of these mitigations, either the > > original LFENCE or the dependent instruction thing, but you have to > > enable one or the other. > > Ok, this means every program running on the machine has to care itself > to be spectre v1 - safe. Correct. Primiarily this matters for things like JITs, where untrusted code may be run in the same address space as sensitive data. > A malicious program most probably won't care about that. Therefore, my > next question is: which memory regions can be exploited by a malicious > program? The complete physical memory or only the memory provided to the > malicious program? Should be the latter if this approach should have any > impact. Assuming you have a CPU which is not vulnerable to meltdown / variant-3, or you have mitigated this, (e.g. with KPTI), a malicious program can only access data within its own address space. Spectre variant-1 alone only gives access to memory in the address space of the program itself. Thanks, Mark.
Re: Spectre mitigation doesn't seem to work at all?!
On Mon, Jun 04, 2018 at 10:50:07AM +0200, Andreas Hartmann wrote: > Hello Peter, > > thanks for your answer! I appreciate it! > > On 06/04/2018 at 10:15 AM Peter Zijlstra wrote: > > On Fri, Jun 01, 2018 at 02:19:38PM +0200, Andreas Hartmann wrote: > > > >> I tested the spectre mitigation of different machines and kernels with > >> https://github.com/crozone/SpectrePoC > >> > >> You can see the results below. > > > >> My question: Did I miss something? > > > > Yes. > > > >> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > >> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > >> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > > > > > > > > The POC is a v1 on itself. V1 needs to be fixed for every individual > > executable (worse, for every individual location in the code, and we're > > still finding them). The kernel mitigation status for v1 only indicates > > the kernel itself has mitigations (for some locations). > > > > The POC is meant to test effectiveness of these mitigations, either the > > original LFENCE or the dependent instruction thing, but you have to > > enable one or the other. > > Ok, this means every program running on the machine has to care itself > to be spectre v1 - safe. Correct. Primiarily this matters for things like JITs, where untrusted code may be run in the same address space as sensitive data. > A malicious program most probably won't care about that. Therefore, my > next question is: which memory regions can be exploited by a malicious > program? The complete physical memory or only the memory provided to the > malicious program? Should be the latter if this approach should have any > impact. Assuming you have a CPU which is not vulnerable to meltdown / variant-3, or you have mitigated this, (e.g. with KPTI), a malicious program can only access data within its own address space. Spectre variant-1 alone only gives access to memory in the address space of the program itself. Thanks, Mark.
Re: Spectre mitigation doesn't seem to work at all?!
On Mon, Jun 04, 2018 at 10:50:07AM +0200, Andreas Hartmann wrote: > Ok, this means every program running on the machine has to care itself > to be spectre v1 - safe. Correct. Compiler and static analyser teams are looking hard at this to help. > A malicious program most probably won't care about that. Therefore, my > next question is: which memory regions can be exploited by a malicious > program? The complete physical memory or only the memory provided to the > malicious program? Should be the latter if this approach should have any > impact. It affects the virtual memory of the target process.
Re: Spectre mitigation doesn't seem to work at all?!
On Mon, Jun 04, 2018 at 10:50:07AM +0200, Andreas Hartmann wrote: > Ok, this means every program running on the machine has to care itself > to be spectre v1 - safe. Correct. Compiler and static analyser teams are looking hard at this to help. > A malicious program most probably won't care about that. Therefore, my > next question is: which memory regions can be exploited by a malicious > program? The complete physical memory or only the memory provided to the > malicious program? Should be the latter if this approach should have any > impact. It affects the virtual memory of the target process.
Re: Spectre mitigation doesn't seem to work at all?!
Hello Peter, thanks for your answer! I appreciate it! On 06/04/2018 at 10:15 AM Peter Zijlstra wrote: > On Fri, Jun 01, 2018 at 02:19:38PM +0200, Andreas Hartmann wrote: > >> I tested the spectre mitigation of different machines and kernels with >> https://github.com/crozone/SpectrePoC >> >> You can see the results below. > >> My question: Did I miss something? > > Yes. > >> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED >> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED >> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > > > > The POC is a v1 on itself. V1 needs to be fixed for every individual > executable (worse, for every individual location in the code, and we're > still finding them). The kernel mitigation status for v1 only indicates > the kernel itself has mitigations (for some locations). > > The POC is meant to test effectiveness of these mitigations, either the > original LFENCE or the dependent instruction thing, but you have to > enable one or the other. Ok, this means every program running on the machine has to care itself to be spectre v1 - safe. A malicious program most probably won't care about that. Therefore, my next question is: which memory regions can be exploited by a malicious program? The complete physical memory or only the memory provided to the malicious program? Should be the latter if this approach should have any impact. Thanks, Andreas
Re: Spectre mitigation doesn't seem to work at all?!
Hello Peter, thanks for your answer! I appreciate it! On 06/04/2018 at 10:15 AM Peter Zijlstra wrote: > On Fri, Jun 01, 2018 at 02:19:38PM +0200, Andreas Hartmann wrote: > >> I tested the spectre mitigation of different machines and kernels with >> https://github.com/crozone/SpectrePoC >> >> You can see the results below. > >> My question: Did I miss something? > > Yes. > >> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED >> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED >> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > > > > The POC is a v1 on itself. V1 needs to be fixed for every individual > executable (worse, for every individual location in the code, and we're > still finding them). The kernel mitigation status for v1 only indicates > the kernel itself has mitigations (for some locations). > > The POC is meant to test effectiveness of these mitigations, either the > original LFENCE or the dependent instruction thing, but you have to > enable one or the other. Ok, this means every program running on the machine has to care itself to be spectre v1 - safe. A malicious program most probably won't care about that. Therefore, my next question is: which memory regions can be exploited by a malicious program? The complete physical memory or only the memory provided to the malicious program? Should be the latter if this approach should have any impact. Thanks, Andreas
Re: Spectre mitigation doesn't seem to work at all?!
On Fri, Jun 01, 2018 at 02:19:38PM +0200, Andreas Hartmann wrote: > I tested the spectre mitigation of different machines and kernels with > https://github.com/crozone/SpectrePoC > > You can see the results below. > My question: Did I miss something? Yes. > Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED The POC is a v1 on itself. V1 needs to be fixed for every individual executable (worse, for every individual location in the code, and we're still finding them). The kernel mitigation status for v1 only indicates the kernel itself has mitigations (for some locations). The POC is meant to test effectiveness of these mitigations, either the original LFENCE or the dependent instruction thing, but you have to enable one or the other.
Re: Spectre mitigation doesn't seem to work at all?!
On Fri, Jun 01, 2018 at 02:19:38PM +0200, Andreas Hartmann wrote: > I tested the spectre mitigation of different machines and kernels with > https://github.com/crozone/SpectrePoC > > You can see the results below. > My question: Did I miss something? Yes. > Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED The POC is a v1 on itself. V1 needs to be fixed for every individual executable (worse, for every individual location in the code, and we're still finding them). The kernel mitigation status for v1 only indicates the kernel itself has mitigations (for some locations). The POC is meant to test effectiveness of these mitigations, either the original LFENCE or the dependent instruction thing, but you have to enable one or the other.
Re: Spectre mitigation doesn't seem to work at all?!
Hello! Sorry for a ping - but I think the behavior shown below should really be investigated! Thanks, Andreas On 06/01/2018 at 02:19 PM Andreas Hartmann wrote: > Hello! > > I tested the spectre mitigation of different machines and kernels with > https://github.com/crozone/SpectrePoC > > You can see the results below. > > > My question: Did I miss something? > My expectation was, that on base of the output of > /sys/devices/system/cpu/vulnerabilities/spectre_v* as shown below the > problem should be gone away. > But the results seem to tell me something other ... . > > > Thanks > Andreas > > > > > -- > > CPU: AMD Ryzen 7 1700X Eight-Core Processor > Bios: BIOS 4011 04/19/2018 - ibpb is listed in /proc/cpuinfo > Kernel: 4.14.44-1.1-default > cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 > Mitigation: Full AMD retpoline, IBPB > cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 > Mitigation: __user pointer sanitization > > ./spectre.out > Using a cache hit threshold of 80. > Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED > INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > Reading 40 bytes: > Reading at malicious_x = 0xffdfec18... Success: 0x54=’T’ score=2 > Reading at malicious_x = 0xffdfec19... Success: 0x68=’h’ score=2 > Reading at malicious_x = 0xffdfec1a... Success: 0x65=’e’ score=2 > Reading at malicious_x = 0xffdfec1b... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffdfec1c... Success: 0x4D=’M’ score=2 > Reading at malicious_x = 0xffdfec1d... Success: 0x61=’a’ score=2 > Reading at malicious_x = 0xffdfec1e... Success: 0x67=’g’ score=2 > Reading at malicious_x = 0xffdfec1f... Success: 0x69=’i’ score=2 > Reading at malicious_x = 0xffdfec20... Success: 0x63=’c’ score=2 > Reading at malicious_x = 0xffdfec21... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffdfec22... Success: 0x57=’W’ score=2 > Reading at malicious_x = 0xffdfec23... Success: 0x6F=’o’ score=2 > Reading at malicious_x = 0xffdfec24... Success: 0x72=’r’ score=2 > Reading at malicious_x = 0xffdfec25... Success: 0x64=’d’ score=2 > Reading at malicious_x = 0xffdfec26... Success: 0x73=’s’ score=2 > Reading at malicious_x = 0xffdfec27... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffdfec28... Success: 0x61=’a’ score=2 > Reading at malicious_x = 0xffdfec29... Success: 0x72=’r’ score=2 > Reading at malicious_x = 0xffdfec2a... Success: 0x65=’e’ score=2 > Reading at malicious_x = 0xffdfec2b... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffdfec2c... Success: 0x53=’S’ score=2 > Reading at malicious_x = 0xffdfec2d... Success: 0x71=’q’ score=2 > Reading at malicious_x = 0xffdfec2e... Success: 0x75=’u’ score=2 > Reading at malicious_x = 0xffdfec2f... Success: 0x65=’e’ score=2 > Reading at malicious_x = 0xffdfec30... Success: 0x61=’a’ score=2 > Reading at malicious_x = 0xffdfec31... Success: 0x6D=’m’ score=2 > Reading at malicious_x = 0xffdfec32... Success: 0x69=’i’ score=2 > Reading at malicious_x = 0xffdfec33... Success: 0x73=’s’ score=2 > Reading at malicious_x = 0xffdfec34... Success: 0x68=’h’ score=2 > Reading at malicious_x = 0xffdfec35... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffdfec36... Success: 0x4F=’O’ score=2 > Reading at malicious_x = 0xffdfec37... Success: 0x73=’s’ score=2 > Reading at malicious_x = 0xffdfec38... Success: 0x73=’s’ score=2 > Reading at malicious_x = 0xffdfec39... Success: 0x69=’i’ score=2 > Reading at malicious_x = 0xffdfec3a... Success: 0x66=’f’ score=2 > Reading at malicious_x = 0xffdfec3b... Success: 0x72=’r’ score=2 > Reading at malicious_x = 0xffdfec3c... Success: 0x61=’a’ score=2 > Reading at malicious_x = 0xffdfec3d... Success: 0x67=’g’ score=2 > Reading at malicious_x = 0xffdfec3e... Success: 0x65=’e’ score=2 > Reading at malicious_x = 0xffdfec3f... Success: 0x2E=’.’ score=2 > > > -- > > CPU: AMD G-T40E Processor > Kernel: 4.14.44-1.el6.x86_64 > cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 > Mitigation: __user pointer sanitization > cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 > Mitigation: Full AMD retpoline > > ./spectre.out 130 > Using a cache hit threshold of 130. > Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED > INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > Reading 40 bytes: > Reading at malicious_x = 0xffdfebf0... Unclear: 0x54=’T’ > score=999 (second best: 0x00=’?’ score=992) > Reading at
Re: Spectre mitigation doesn't seem to work at all?!
Hello! Sorry for a ping - but I think the behavior shown below should really be investigated! Thanks, Andreas On 06/01/2018 at 02:19 PM Andreas Hartmann wrote: > Hello! > > I tested the spectre mitigation of different machines and kernels with > https://github.com/crozone/SpectrePoC > > You can see the results below. > > > My question: Did I miss something? > My expectation was, that on base of the output of > /sys/devices/system/cpu/vulnerabilities/spectre_v* as shown below the > problem should be gone away. > But the results seem to tell me something other ... . > > > Thanks > Andreas > > > > > -- > > CPU: AMD Ryzen 7 1700X Eight-Core Processor > Bios: BIOS 4011 04/19/2018 - ibpb is listed in /proc/cpuinfo > Kernel: 4.14.44-1.1-default > cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 > Mitigation: Full AMD retpoline, IBPB > cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 > Mitigation: __user pointer sanitization > > ./spectre.out > Using a cache hit threshold of 80. > Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED > INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > Reading 40 bytes: > Reading at malicious_x = 0xffdfec18... Success: 0x54=’T’ score=2 > Reading at malicious_x = 0xffdfec19... Success: 0x68=’h’ score=2 > Reading at malicious_x = 0xffdfec1a... Success: 0x65=’e’ score=2 > Reading at malicious_x = 0xffdfec1b... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffdfec1c... Success: 0x4D=’M’ score=2 > Reading at malicious_x = 0xffdfec1d... Success: 0x61=’a’ score=2 > Reading at malicious_x = 0xffdfec1e... Success: 0x67=’g’ score=2 > Reading at malicious_x = 0xffdfec1f... Success: 0x69=’i’ score=2 > Reading at malicious_x = 0xffdfec20... Success: 0x63=’c’ score=2 > Reading at malicious_x = 0xffdfec21... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffdfec22... Success: 0x57=’W’ score=2 > Reading at malicious_x = 0xffdfec23... Success: 0x6F=’o’ score=2 > Reading at malicious_x = 0xffdfec24... Success: 0x72=’r’ score=2 > Reading at malicious_x = 0xffdfec25... Success: 0x64=’d’ score=2 > Reading at malicious_x = 0xffdfec26... Success: 0x73=’s’ score=2 > Reading at malicious_x = 0xffdfec27... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffdfec28... Success: 0x61=’a’ score=2 > Reading at malicious_x = 0xffdfec29... Success: 0x72=’r’ score=2 > Reading at malicious_x = 0xffdfec2a... Success: 0x65=’e’ score=2 > Reading at malicious_x = 0xffdfec2b... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffdfec2c... Success: 0x53=’S’ score=2 > Reading at malicious_x = 0xffdfec2d... Success: 0x71=’q’ score=2 > Reading at malicious_x = 0xffdfec2e... Success: 0x75=’u’ score=2 > Reading at malicious_x = 0xffdfec2f... Success: 0x65=’e’ score=2 > Reading at malicious_x = 0xffdfec30... Success: 0x61=’a’ score=2 > Reading at malicious_x = 0xffdfec31... Success: 0x6D=’m’ score=2 > Reading at malicious_x = 0xffdfec32... Success: 0x69=’i’ score=2 > Reading at malicious_x = 0xffdfec33... Success: 0x73=’s’ score=2 > Reading at malicious_x = 0xffdfec34... Success: 0x68=’h’ score=2 > Reading at malicious_x = 0xffdfec35... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffdfec36... Success: 0x4F=’O’ score=2 > Reading at malicious_x = 0xffdfec37... Success: 0x73=’s’ score=2 > Reading at malicious_x = 0xffdfec38... Success: 0x73=’s’ score=2 > Reading at malicious_x = 0xffdfec39... Success: 0x69=’i’ score=2 > Reading at malicious_x = 0xffdfec3a... Success: 0x66=’f’ score=2 > Reading at malicious_x = 0xffdfec3b... Success: 0x72=’r’ score=2 > Reading at malicious_x = 0xffdfec3c... Success: 0x61=’a’ score=2 > Reading at malicious_x = 0xffdfec3d... Success: 0x67=’g’ score=2 > Reading at malicious_x = 0xffdfec3e... Success: 0x65=’e’ score=2 > Reading at malicious_x = 0xffdfec3f... Success: 0x2E=’.’ score=2 > > > -- > > CPU: AMD G-T40E Processor > Kernel: 4.14.44-1.el6.x86_64 > cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 > Mitigation: __user pointer sanitization > cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 > Mitigation: Full AMD retpoline > > ./spectre.out 130 > Using a cache hit threshold of 130. > Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED > INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > Reading 40 bytes: > Reading at malicious_x = 0xffdfebf0... Unclear: 0x54=’T’ > score=999 (second best: 0x00=’?’ score=992) > Reading at
Spectre mitigation doesn't seem to work at all?!
Hello! I tested the spectre mitigation of different machines and kernels with https://github.com/crozone/SpectrePoC You can see the results below. My question: Did I miss something? My expectation was, that on base of the output of /sys/devices/system/cpu/vulnerabilities/spectre_v* as shown below the problem should be gone away. But the results seem to tell me something other ... . Thanks Andreas -- CPU:AMD Ryzen 7 1700X Eight-Core Processor Bios: BIOS 4011 04/19/2018 - ibpb is listed in /proc/cpuinfo Kernel: 4.14.44-1.1-default cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 Mitigation: Full AMD retpoline, IBPB cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 Mitigation: __user pointer sanitization ./spectre.out Using a cache hit threshold of 80. Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED Reading 40 bytes: Reading at malicious_x = 0xffdfec18... Success: 0x54=’T’ score=2 Reading at malicious_x = 0xffdfec19... Success: 0x68=’h’ score=2 Reading at malicious_x = 0xffdfec1a... Success: 0x65=’e’ score=2 Reading at malicious_x = 0xffdfec1b... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffdfec1c... Success: 0x4D=’M’ score=2 Reading at malicious_x = 0xffdfec1d... Success: 0x61=’a’ score=2 Reading at malicious_x = 0xffdfec1e... Success: 0x67=’g’ score=2 Reading at malicious_x = 0xffdfec1f... Success: 0x69=’i’ score=2 Reading at malicious_x = 0xffdfec20... Success: 0x63=’c’ score=2 Reading at malicious_x = 0xffdfec21... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffdfec22... Success: 0x57=’W’ score=2 Reading at malicious_x = 0xffdfec23... Success: 0x6F=’o’ score=2 Reading at malicious_x = 0xffdfec24... Success: 0x72=’r’ score=2 Reading at malicious_x = 0xffdfec25... Success: 0x64=’d’ score=2 Reading at malicious_x = 0xffdfec26... Success: 0x73=’s’ score=2 Reading at malicious_x = 0xffdfec27... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffdfec28... Success: 0x61=’a’ score=2 Reading at malicious_x = 0xffdfec29... Success: 0x72=’r’ score=2 Reading at malicious_x = 0xffdfec2a... Success: 0x65=’e’ score=2 Reading at malicious_x = 0xffdfec2b... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffdfec2c... Success: 0x53=’S’ score=2 Reading at malicious_x = 0xffdfec2d... Success: 0x71=’q’ score=2 Reading at malicious_x = 0xffdfec2e... Success: 0x75=’u’ score=2 Reading at malicious_x = 0xffdfec2f... Success: 0x65=’e’ score=2 Reading at malicious_x = 0xffdfec30... Success: 0x61=’a’ score=2 Reading at malicious_x = 0xffdfec31... Success: 0x6D=’m’ score=2 Reading at malicious_x = 0xffdfec32... Success: 0x69=’i’ score=2 Reading at malicious_x = 0xffdfec33... Success: 0x73=’s’ score=2 Reading at malicious_x = 0xffdfec34... Success: 0x68=’h’ score=2 Reading at malicious_x = 0xffdfec35... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffdfec36... Success: 0x4F=’O’ score=2 Reading at malicious_x = 0xffdfec37... Success: 0x73=’s’ score=2 Reading at malicious_x = 0xffdfec38... Success: 0x73=’s’ score=2 Reading at malicious_x = 0xffdfec39... Success: 0x69=’i’ score=2 Reading at malicious_x = 0xffdfec3a... Success: 0x66=’f’ score=2 Reading at malicious_x = 0xffdfec3b... Success: 0x72=’r’ score=2 Reading at malicious_x = 0xffdfec3c... Success: 0x61=’a’ score=2 Reading at malicious_x = 0xffdfec3d... Success: 0x67=’g’ score=2 Reading at malicious_x = 0xffdfec3e... Success: 0x65=’e’ score=2 Reading at malicious_x = 0xffdfec3f... Success: 0x2E=’.’ score=2 -- CPU:AMD G-T40E Processor Kernel: 4.14.44-1.el6.x86_64 cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 Mitigation: __user pointer sanitization cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 Mitigation: Full AMD retpoline ./spectre.out 130 Using a cache hit threshold of 130. Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED Reading 40 bytes: Reading at malicious_x = 0xffdfebf0... Unclear: 0x54=’T’ score=999 (second best: 0x00=’?’ score=992) Reading at malicious_x = 0xffdfebf1... Unclear: 0x68=’h’ score=996 (second best: 0x00=’?’ score=988) Reading at malicious_x = 0xffdfebf2... Unclear: 0x65=’e’ score=999 (second best: 0x00=’?’ score=985) Reading at malicious_x = 0xffdfebf3... Unclear: 0x20=’ ’ score=997 (second best: 0x00=’?’ score=989) Reading at malicious_x =
Spectre mitigation doesn't seem to work at all?!
Hello! I tested the spectre mitigation of different machines and kernels with https://github.com/crozone/SpectrePoC You can see the results below. My question: Did I miss something? My expectation was, that on base of the output of /sys/devices/system/cpu/vulnerabilities/spectre_v* as shown below the problem should be gone away. But the results seem to tell me something other ... . Thanks Andreas -- CPU:AMD Ryzen 7 1700X Eight-Core Processor Bios: BIOS 4011 04/19/2018 - ibpb is listed in /proc/cpuinfo Kernel: 4.14.44-1.1-default cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 Mitigation: Full AMD retpoline, IBPB cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 Mitigation: __user pointer sanitization ./spectre.out Using a cache hit threshold of 80. Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED Reading 40 bytes: Reading at malicious_x = 0xffdfec18... Success: 0x54=’T’ score=2 Reading at malicious_x = 0xffdfec19... Success: 0x68=’h’ score=2 Reading at malicious_x = 0xffdfec1a... Success: 0x65=’e’ score=2 Reading at malicious_x = 0xffdfec1b... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffdfec1c... Success: 0x4D=’M’ score=2 Reading at malicious_x = 0xffdfec1d... Success: 0x61=’a’ score=2 Reading at malicious_x = 0xffdfec1e... Success: 0x67=’g’ score=2 Reading at malicious_x = 0xffdfec1f... Success: 0x69=’i’ score=2 Reading at malicious_x = 0xffdfec20... Success: 0x63=’c’ score=2 Reading at malicious_x = 0xffdfec21... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffdfec22... Success: 0x57=’W’ score=2 Reading at malicious_x = 0xffdfec23... Success: 0x6F=’o’ score=2 Reading at malicious_x = 0xffdfec24... Success: 0x72=’r’ score=2 Reading at malicious_x = 0xffdfec25... Success: 0x64=’d’ score=2 Reading at malicious_x = 0xffdfec26... Success: 0x73=’s’ score=2 Reading at malicious_x = 0xffdfec27... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffdfec28... Success: 0x61=’a’ score=2 Reading at malicious_x = 0xffdfec29... Success: 0x72=’r’ score=2 Reading at malicious_x = 0xffdfec2a... Success: 0x65=’e’ score=2 Reading at malicious_x = 0xffdfec2b... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffdfec2c... Success: 0x53=’S’ score=2 Reading at malicious_x = 0xffdfec2d... Success: 0x71=’q’ score=2 Reading at malicious_x = 0xffdfec2e... Success: 0x75=’u’ score=2 Reading at malicious_x = 0xffdfec2f... Success: 0x65=’e’ score=2 Reading at malicious_x = 0xffdfec30... Success: 0x61=’a’ score=2 Reading at malicious_x = 0xffdfec31... Success: 0x6D=’m’ score=2 Reading at malicious_x = 0xffdfec32... Success: 0x69=’i’ score=2 Reading at malicious_x = 0xffdfec33... Success: 0x73=’s’ score=2 Reading at malicious_x = 0xffdfec34... Success: 0x68=’h’ score=2 Reading at malicious_x = 0xffdfec35... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffdfec36... Success: 0x4F=’O’ score=2 Reading at malicious_x = 0xffdfec37... Success: 0x73=’s’ score=2 Reading at malicious_x = 0xffdfec38... Success: 0x73=’s’ score=2 Reading at malicious_x = 0xffdfec39... Success: 0x69=’i’ score=2 Reading at malicious_x = 0xffdfec3a... Success: 0x66=’f’ score=2 Reading at malicious_x = 0xffdfec3b... Success: 0x72=’r’ score=2 Reading at malicious_x = 0xffdfec3c... Success: 0x61=’a’ score=2 Reading at malicious_x = 0xffdfec3d... Success: 0x67=’g’ score=2 Reading at malicious_x = 0xffdfec3e... Success: 0x65=’e’ score=2 Reading at malicious_x = 0xffdfec3f... Success: 0x2E=’.’ score=2 -- CPU:AMD G-T40E Processor Kernel: 4.14.44-1.el6.x86_64 cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 Mitigation: __user pointer sanitization cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 Mitigation: Full AMD retpoline ./spectre.out 130 Using a cache hit threshold of 130. Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED Reading 40 bytes: Reading at malicious_x = 0xffdfebf0... Unclear: 0x54=’T’ score=999 (second best: 0x00=’?’ score=992) Reading at malicious_x = 0xffdfebf1... Unclear: 0x68=’h’ score=996 (second best: 0x00=’?’ score=988) Reading at malicious_x = 0xffdfebf2... Unclear: 0x65=’e’ score=999 (second best: 0x00=’?’ score=985) Reading at malicious_x = 0xffdfebf3... Unclear: 0x20=’ ’ score=997 (second best: 0x00=’?’ score=989) Reading at malicious_x =
