View previous topic :: View next topic |
Author |
Message |
Hossie Tux's lil' helper
Joined: 08 Dec 2005 Posts: 116
|
Posted: Mon Feb 26, 2018 5:51 pm Post subject: |
|
|
Does anybody know of new microcode releases (that "linux package")? Do distributors have special access / communction channels to intel or do they also just download from that downloadcenter page...
Maybe we should be thinking about collecting bios updates and extracting microcode from there?
I still need it to secure my CentOS KVM VMs :/ |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Mon Feb 26, 2018 6:08 pm Post subject: Re: Mac PPC32 G4 |
|
|
tholin wrote: | To fix the vulnerability you have to do something like this to all vulnerable code patterns. |
Wouldn't it be the task of the compiler to do that? Only the compiler knows when his assembler code actually produces a conditional; and at every conditional the corresponding instruction would have to be put.
Actually, I had assumed that -mindirect-branch=thunk would exactly fix such conditional branches. |
|
Back to top |
|
|
tholin Apprentice
Joined: 04 Oct 2008 Posts: 205
|
Posted: Mon Feb 26, 2018 7:30 pm Post subject: Re: Mac PPC32 G4 |
|
|
Luke-Jr wrote: | But the program segfaults if I try to read directly from it...? |
How are you reading the memory?
Perhaps I'm wrong and the kernel got some way to emulate the behavior despite the lack of hardware support on x86.
mv wrote: | Wouldn't it be the task of the compiler to do that? |
Ideally, yes but it won't be easy. You can't put a serializing instruction after every conditional branch because the performance hit is too high. That PoC takes a 98.7% performance drop on my computer after inserting that single lfence instruction. The compiler needs to figure out which branches are vulnerable and only protect them but the compiler doesn't even know which inputs are trusted and untrusted.
Microsoft has implemented spectre v1 protection in their compiler but as expected it didn't work so well.
https://www.paulkocher.com/doc/MicrosoftCompilerSpectreMitigation.html
"A compiler cannot reliably determine whether arbitrary sequences of instructions will be exploitable. For example, when compiling a function, the compiler often has no way to infer the properties of the parameters that will be passed when the function is called. A post-compilation analysis tool (e.g. using symbolic execution) could do somewhat a better job, but will still be imperfect since code analysis is an inherently undecidable problem."
mv wrote: | Actually, I had assumed that -mindirect-branch=thunk would exactly fix such conditional branches. |
-mindirect-branch=thunk is only for spectre v2 (replacing indirect branches with retpolines) and that's unrelated to spectre v1 (problematic speculation beyond conditional branches). |
|
Back to top |
|
|
Luke-Jr n00b
Joined: 28 Apr 2003 Posts: 33 Location: Jabber: luke@dashjr.org
|
Posted: Mon Feb 26, 2018 7:34 pm Post subject: Re: Mac PPC32 G4 |
|
|
tholin wrote: | Luke-Jr wrote: | But the program segfaults if I try to read directly from it...? |
How are you reading the memory? |
Code: | value[0] = *(uint8_t *)malicious_x; |
|
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22914
|
Posted: Tue Feb 27, 2018 3:47 am Post subject: |
|
|
Why are you casting a size to a pointer? That is unlikely to work, especially since it looks like the size isn't even sane in the first place. victim is a pointer to the mapping. array1 is unspecified in the linked diff, but based on other context is probably a global array. So the displacement between them is (1) variable based on the mapping location and (2) meaningless as a pointer. Accessing it at all is a bug. Remember the basic rule of C casts: if you cannot explain exactly why you need it, you probably don't need it and should not use it. If not using it breaks your build, that's probably because your code is wrong. I suggest removing all non-justifiable casts in your code and rebuilding with -Wall -Wextra. |
|
Back to top |
|
|
tholin Apprentice
Joined: 04 Oct 2008 Posts: 205
|
Posted: Tue Feb 27, 2018 10:05 am Post subject: |
|
|
As Hu pointed out malicious_x is a vector no a pointer. It should be the offset between the start of array1 to secret. The original code calls victim_function with malicious_x which will speculatively read from array1[malicious_x]. Since malicious_x is the distance between array1 and secret that read will be out of bounds and end up in secret instead. Even if you change your mmap permission to (PROT_READ | PROT_WRITE) dereferencing malicious_x directly will still segfault.
The original code is also a bit confused. In main() it tries to print malicious_x like a pointer.
Code: | printf("Reading at malicious_x = %p... ", (void *)malicious_x); |
But it's not a pointer and the value printed is gibberish.
If you try to make a write only mapping it will show up in /proc/<pid>/smaps as
Code: | 7f858927c000-7f858927d000 -w-p 00000000 00:00 0 |
So it looks like the mapping is writable and private but not readable. But if you check the actual pagetables from /sys/kernel/debug/page_tables/current_user the same mapping looks like
Code: | 0x00007f858927c000-0x00007f858927e000 8K USR RW NX pte |
So the mapping is really RW. X86 doesn't have write only pagetables.
/sys/kernel/debug/page_tables/current_user shows the pagetables of the process that reads it so you have to read it from the C program. |
|
Back to top |
|
|
blopsalot Apprentice
Joined: 28 Jan 2017 Posts: 231
|
|
Back to top |
|
|
dasPaul Apprentice
Joined: 14 Feb 2012 Posts: 243 Location: Dresden
|
Posted: Sun Mar 11, 2018 7:10 am Post subject: |
|
|
Hi
The "spectre-meltdown-checker" says on my system:
CVE-2017-5753
STATUS: NOT VULNERABLE
CVE-2017-5754
STATUS: NOT VULNERABLE
but for
CVE-2017-5715
STATUS: VULNERABLE
Is this because I do not yet have compiled with the patched gcc? I currently have gcc-6.4.0-r1.
Should/Can I upgrade to ~7.3.0 and recompile world/kernel? Does 7.3.0 contain the patches? _________________ -=human without Windows®=-
sorry for my bad english! |
|
Back to top |
|
|
blopsalot Apprentice
Joined: 28 Jan 2017 Posts: 231
|
Posted: Sun Mar 11, 2018 9:09 am Post subject: |
|
|
dasPaul wrote: | Hi
The "spectre-meltdown-checker" says on my system:
CVE-2017-5753
STATUS: NOT VULNERABLE
CVE-2017-5754
STATUS: NOT VULNERABLE
but for
CVE-2017-5715
STATUS: VULNERABLE
Is this because I do not yet have compiled with the patched gcc? I currently have gcc-6.4.0-r1.
Should/Can I upgrade to ~7.3.0 and recompile world/kernel? Does 7.3.0 contain the patches? |
they just merged the s390 mitigations a few days ago to the 6-branch. 7.3.0 was kind of rushed, I'm guess i386 will be backported soon though.. |
|
Back to top |
|
|
Ska` n00b
Joined: 25 Sep 2004 Posts: 74
|
Posted: Mon Mar 12, 2018 1:01 pm Post subject: |
|
|
Since ~7.3.0 had no ~ deps, I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt
Everything went fine except one package: oath-toolkit. I don't know if the fault is due to the new GCC or what, I already unmerged 6.4.0 so I can't try right now. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Mon Mar 12, 2018 3:16 pm Post subject: |
|
|
Ska` wrote: | Since ~7.3.0 had no ~ deps, I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt
Everything went fine except one package: oath-toolkit. I don't know if the fault is due to the new GCC or what, I already unmerged 6.4.0 so I can't try right now. |
I had a few that just needed a package.env setting to specify an older default standard or a changed flag (couldn't tolerate pie, I switched profile at the same time). |
|
Back to top |
|
|
Luke-Jr n00b
Joined: 28 Apr 2003 Posts: 33 Location: Jabber: luke@dashjr.org
|
Posted: Mon Mar 12, 2018 4:30 pm Post subject: |
|
|
Ska` wrote: | Since ~7.3.0 had no ~ deps, I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt
Everything went fine except one package: oath-toolkit. I don't know if the fault is due to the new GCC or what, I already unmerged 6.4.0 so I can't try right now. | Note that some packages ignore CFLAGS still. :/
I'm playing with this patch to [almost] force it on: https://luke.dashjr.org/tmp/code/gcc-retpoline-default.patch
Problem now is libgcrypt's ebuild doesn't let you configure its optional feature, and one of those (jitter RNG) requires -O0...
Annoyingly, the package maintainer doesn't care about providing the choice Gentoo was once known for: https://bugs.gentoo.org/show_bug.cgi?id=649660 |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Mon Mar 12, 2018 5:24 pm Post subject: |
|
|
How true! In your case, it looks like you could make a simple user patch to engage that configuration option. |
|
Back to top |
|
|
Luke-Jr n00b
Joined: 28 Apr 2003 Posts: 33 Location: Jabber: luke@dashjr.org
|
Posted: Mon Mar 12, 2018 5:33 pm Post subject: |
|
|
Tony0945 wrote: |
How true! In your case, it looks like you could make a simple user patch to engage that configuration option. | Yes, it will just be annoying to need to bump it for every new version. |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Mon Mar 12, 2018 5:50 pm Post subject: |
|
|
Quote: | I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt |
Why do you do this? Do you really think that your systems will be more secure or more reliable?
Look, there are many reasons why it makes sense to compile the kernel with retpoline and meltdown/spectre patches. The most important one is: because kernel developers know what they are doing, they tested it and they recommend it.
That's not true for the other 1.000 packages on our computers. As far as I know, none of the developers of those 1000 packages has said: we tested '-mindirect-branch=thunk -mfunction-return=thunk -fno-plt', it's safe, it works, please use it.
So you compile packages with compiler flags that were not tested for those packages. What you get are binaries which may have errors due to untested compiler flags and which are probably less secure. That's especially true for cryptography software, which is highly optimized and tested with compilers which were available at the time the software was released. Do you really understand what happens if you compile openssl & friends with '-mindirect-branch=thunk -mfunction-return=thunk -fno-plt'? I wouldn't do that if I my objective was to get a secure system. At least not before developers of the software recommend it. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Mon Mar 12, 2018 5:54 pm Post subject: |
|
|
Luke-Jr wrote: | Yes, it will just be annoying to need to bump it for every new version. |
If it's changing rapidly, it might be easier to maintain the ebuild in local overlay and just put the config line in the ebuild. Most of the time you only have to update the ebuild name, and run "repoman manifest" to keep it in sync. Annoying, but minor. Much less annoying than having your system barf from a surprise change or having useless systemd unit files polluting your system.
EDIT: Just look what happened to xorg-server! I have more and more system packages in package.mask with <name>::gentoo to just block all the official ebuilds. |
|
Back to top |
|
|
Elleni Veteran
Joined: 23 May 2006 Posts: 1291
|
Posted: Mon Mar 12, 2018 8:35 pm Post subject: |
|
|
mike155 wrote: | Quote: | I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt |
Why do you do this? Do you really think that your systems will be more secure or more reliable?
Look, there are many reasons why it makes sense to compile the kernel with retpoline and meltdown/spectre patches. The most important one is: because kernel developers know what they are doing, they tested it and they recommend it.
That's not true for the other 1.000 packages on our computers. As far as I know, none of the developers of those 1000 packages has said: we tested '-mindirect-branch=thunk -mfunction-return=thunk -fno-plt', it's safe, it works, please use it.
So you compile packages with compiler flags that were not tested for those packages. What you get are binaries which may have errors due to untested compiler flags and which are probably less secure. That's especially true for cryptography software, which is highly optimized and tested with compilers which were available at the time the software was released. Do you really understand what happens if you compile openssl & friends with '-mindirect-branch=thunk -mfunction-return=thunk -fno-plt'? I wouldn't do that if I my objective was to get a secure system. At least not before developers of the software recommend it. |
Thanks for clarification, so for the average user, is it sufficient to just update to gcc-7.3 and emerge kernel and perhaps even -e world with this compiler? I have no special cflags in make.conf, just CFLAGS="-O2 -march=znver1" for my ryzen cpu.
At least grep . /sys/devices/system/cpu/vulnerabilities/* then shows:
Code: | /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline |
|
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Mon Mar 12, 2018 9:02 pm Post subject: |
|
|
Quote: | Thanks for clarification, so for the average user, is it sufficient to just update to gcc-7.3 and emerge kernel and perhaps even -e world with this compiler? I have no special cflags in make.conf, just CFLAGS="-O2 -march=znver1" for my ryzen cpu.
|
Exactly. That's what I did on my computers and that's what I recommend at the moment.
You could add '-pipe' to your CFLAGS, if you want. |
|
Back to top |
|
|
Luke-Jr n00b
Joined: 28 Apr 2003 Posts: 33 Location: Jabber: luke@dashjr.org
|
Posted: Mon Mar 12, 2018 10:03 pm Post subject: |
|
|
mike155 wrote: | Quote: | I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt |
Why do you do this? Do you really think that your systems will be more secure or more reliable? | Certainly won't make them less secure or reliable...
mike155 wrote: | That's not true for the other 1.000 packages on our computers. As far as I know, none of the developers of those 1000 packages has said: we tested '-mindirect-branch=thunk -mfunction-return=thunk -fno-plt', it's safe, it works, please use it.
So you compile packages with compiler flags that were not tested for those packages. What you get are binaries which may have errors due to untested compiler flags and which are probably less secure. That's especially true for cryptography software, which is highly optimized and tested with compilers which were available at the time the software was released. Do you really understand what happens if you compile openssl & friends with '-mindirect-branch=thunk -mfunction-return=thunk -fno-plt'? I wouldn't do that if I my objective was to get a secure system. At least not before developers of the software recommend it. | All it does is emit a slightly different set of instructions that do the same thing, but without triggering speculation.
If this is a problem, it would indicate yet another CPU bug. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22914
|
Posted: Tue Mar 13, 2018 1:37 am Post subject: |
|
|
Luke-Jr wrote: | Problem now is libgcrypt's ebuild doesn't let you configure its optional feature, and one of those (jitter RNG) requires -O0... | That sounds like a bug in the jitter RNG code. In my opinion, if changing the optimization level affects observed program correctness, then either:- The program relies on undefined behavior.
- The compiler implements the standard incorrectly.
Since you mention jitter, I suspect the code is written to rely on failure to optimize. This is broken. The code should instead use appropriate directives to explicitly inhibit any optimizations that impact its correctness.
Separately, looking at the libgcrypt code for tiger.c (which uses the mangled optimization flags), I see several opportunities for improvement. The implementation of the munging is just wrong. The Makefile: cipher/Makefile.am: | 118 if ENABLE_O_FLAG_MUNGING
119 o_flag_munging = sed -e 's/-O\([2-9s][2-9s]*\)/-O1/' -e 's/-Ofast/-O1/g'
120 else
121 o_flag_munging = cat
122 endif
123
124
125 # We need to lower the optimization for this module.
126 tiger.o: $(srcdir)/tiger.c
127 `echo $(COMPILE) -c $(srcdir)/tiger.c | $(o_flag_munging) ` | The consequences: Code: | $ echo '-O2 -O3 -O2' |sed -e 's/-O\([2-9s][2-9s]*\)/-O1/'
-O1 -O3 -O2 | Last match wins, so by failing to specify a global replace on the sed, the rule doesn't actually work if the user passes more than one -O option. More generally, the use of `echo ...` works, but feels very fragile. If upstream insists on munging the flag instead of fixing the code, then the right implementation would be: Code: | if ENABLE_O_FLAG_MUNGING
o_flag_munging=-O1
else
o_flag_munging=
endif
tiger.o: $(srcdir)/tiger.c
$(COMPILE) $(o_flag_munging) -c "$(srcdir)/tiger.c" | When munging is enabled, an extra -O1 would be added after all user flags. When munging is not enabled, the token would be empty and user flags would be fully respected. However, as said above, I think the code is wrong if it requires a particular optimization level.
Amusingly, tiger.c contains this comment: Code: | * Okay, okay, this is not the fastest code - improvements are welcome. | The code might go faster if it was compiled with all standard optimizations.
I also note that many global constant variables are not actually marked as const, so the compiler might needlessly place them in .data instead of .rdata. Luke-Jr wrote: | Yes, it will just be annoying to need to bump it for every new version. | You probably would not need to bump for every version. Write the patch to modify the upstream build files, put it in /etc/portage/patches under a non-version-qualified path, and it should work unchanged until upstream modifies the patched file in a way that causes a conflict.
As an alternative, get upstream to fix their code so you don't need to patch it, then you will not need to maintain anything locally or convince a Gentoo maintainer to modify the ebuild. |
|
Back to top |
|
|
Hossie Tux's lil' helper
Joined: 08 Dec 2005 Posts: 116
|
Posted: Tue Mar 13, 2018 6:57 pm Post subject: |
|
|
Omg there is a new microcode.
I opened 650428 for some quick bumping. |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Wed Mar 14, 2018 12:39 pm Post subject: |
|
|
Hossie wrote: | Omg there is a new microcode. |
Even better, it seems that Intel got it right this time.
I just installed sys-firmware/intel-microcode-20180312 on my Ivy Bridge system, and rebooted:
Code: | > dmesg -t | head -n 1
microcode: microcode updated early to revision 0x1f, date = 2018-02-07
> cd /sys/devices/system/cpu/vulnerabilities
> grep . *
meltdown: Mitigation: PTI
spectre_v1: Mitigation: __user pointer sanitization
spectre_v2: Mitigation: Full generic retpoline, IBPB
|
I haven't seen 'IBPB' before, so that seems to be the new flag to look for. |
|
Back to top |
|
|
Ska` n00b
Joined: 25 Sep 2004 Posts: 74
|
Posted: Wed Mar 14, 2018 2:24 pm Post subject: |
|
|
mike155 wrote: | Quote: | I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt |
Why do you do this? Do you really think that your systems will be more secure or more reliable?
Look, there are many reasons why it makes sense to compile the kernel with retpoline and meltdown/spectre patches. The most important one is: because kernel developers know what they are doing, they tested it and they recommend it.
That's not true for the other 1.000 packages on our computers. As far as I know, none of the developers of those 1000 packages has said: we tested '-mindirect-branch=thunk -mfunction-return=thunk -fno-plt', it's safe, it works, please use it.
So you compile packages with compiler flags that were not tested for those packages. What you get are binaries which may have errors due to untested compiler flags and which are probably less secure. That's especially true for cryptography software, which is highly optimized and tested with compilers which were available at the time the software was released. Do you really understand what happens if you compile openssl & friends with '-mindirect-branch=thunk -mfunction-return=thunk -fno-plt'? I wouldn't do that if I my objective was to get a secure system. At least not before developers of the software recommend it. |
I agree and I wouldn't recommend that flags to a regular desktop user (that should follow the handbook and not a forum thread about new functionalities), I like to try new things and I reported that, at least the compiling, went almost fine.
I don't have time neither the knowledge to explain further but you can find what the flags are supposed to do, basically they drop the speculative execution support and most likely the only effect is a performance downgrade. You can start here from the 3rd post: https://forums.gentoo.org/viewtopic-t-1076300.html |
|
Back to top |
|
|
Spargeltarzan Guru
Joined: 23 Jul 2017 Posts: 328
|
Posted: Tue Mar 20, 2018 3:40 pm Post subject: |
|
|
I have realised with one of the last kernel upgrades the Spectre v2 mitigation "improved" detected by the checker-tool
Code: |
Spectre and Meltdown mitigation detection tool v0.35
Checking for vulnerabilities on current system
Kernel is Linux 4.14.28-gentoo #1 SMP Tue Mar 20 11:57:47 CET 2018 x86_64
CPU is Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: YES
* CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: YES
* CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: YES
* CPU indicates STIBP capability: YES
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO (model 60 stepping 3 ucode 0x24)
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec: YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline, IBPB, IBRS_FW)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)
A false sense of security is worse than no security at all, see --disclaimer
|
It reports not only full generic retpoline, but also IBPB and IBRS_FW in Spectre v2 now. But why the Mitigation 1 is on the other hand "NO", if IBPB and IBRS is available? _________________ ___________________
Regards
Spargeltarzan
Notebook: Lenovo YOGA 900-13ISK: Gentoo stable amd64, GNOME systemd, KVM/QEMU
Desktop-PC: Intel Core i7-4770K, 8GB Ram, AMD Radeon R9 280X, ZFS Storage, GNOME openrc, Dantrell, Xen |
|
Back to top |
|
|
Ska` n00b
Joined: 25 Sep 2004 Posts: 74
|
Posted: Tue Mar 20, 2018 4:36 pm Post subject: |
|
|
Spargeltarzan wrote: | It reports not only full generic retpoline, but also IBPB and IBRS_FW in Spectre v2 now. But why the Mitigation 1 is on the other hand "NO", if IBPB and IBRS is available? |
As far as I understand, the new microcode supports IBPB and IBRS but the kernel not yet. I don't know what these mitigations are supposed to do and if it makes sense using them with retpoline. |
|
Back to top |
|
|
|