Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Meltdown/Spectre: Unauthorized Disclosure of Kernel Memory
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... , 21, 22, 23  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
Hossie
Tux's lil' helper
Tux's lil' helper


Joined: 08 Dec 2005
Posts: 108

PostPosted: Mon Feb 26, 2018 5:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6220

PostPosted: Mon Feb 26, 2018 6:08 pm    Post subject: Re: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
tholin
Tux's lil' helper
Tux's lil' helper


Joined: 04 Oct 2008
Posts: 146

PostPosted: Mon Feb 26, 2018 7:30 pm    Post subject: Re: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
Luke-Jr
n00b
n00b


Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org

PostPosted: Mon Feb 26, 2018 7:34 pm    Post subject: Re: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 12826

PostPosted: Tue Feb 27, 2018 3:47 am    Post subject: Reply with quote

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
View user's profile Send private message
tholin
Tux's lil' helper
Tux's lil' helper


Joined: 04 Oct 2008
Posts: 146

PostPosted: Tue Feb 27, 2018 10:05 am    Post subject: Reply with quote

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
View user's profile Send private message
blopsalot
Apprentice
Apprentice


Joined: 28 Jan 2017
Posts: 231

PostPosted: Sun Mar 11, 2018 5:33 am    Post subject: Reply with quote

Hossie wrote:
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 :/


i am watching supermicro website for westmere. it looks like they going back to yorkfields.
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf
https://www.supermicro.com/support/security_Intel-SA-00088.cfm
Back to top
View user's profile Send private message
dasPaul
Apprentice
Apprentice


Joined: 14 Feb 2012
Posts: 172
Location: Dresden

PostPosted: Sun Mar 11, 2018 7:10 am    Post subject: Reply with quote

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
View user's profile Send private message
blopsalot
Apprentice
Apprentice


Joined: 28 Jan 2017
Posts: 231

PostPosted: Sun Mar 11, 2018 9:09 am    Post subject: Reply with quote

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
View user's profile Send private message
Ska`
n00b
n00b


Joined: 25 Sep 2004
Posts: 74

PostPosted: Mon Mar 12, 2018 1:01 pm    Post subject: Reply with quote

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
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 2607
Location: Illinois, USA

PostPosted: Mon Mar 12, 2018 3:16 pm    Post subject: Reply with quote

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
View user's profile Send private message
Luke-Jr
n00b
n00b


Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org

PostPosted: Mon Mar 12, 2018 4:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 2607
Location: Illinois, USA

PostPosted: Mon Mar 12, 2018 5:24 pm    Post subject: Reply with quote

Luke-Jr wrote:
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


How true! In your case, it looks like you could make a simple user patch to engage that configuration option.
Back to top
View user's profile Send private message
Luke-Jr
n00b
n00b


Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org

PostPosted: Mon Mar 12, 2018 5:33 pm    Post subject: Reply with quote

Tony0945 wrote:
Luke-Jr wrote:
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


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
View user's profile Send private message
mike155
Guru
Guru


Joined: 17 Sep 2010
Posts: 566
Location: Frankfurt, Germany

PostPosted: Mon Mar 12, 2018 5:50 pm    Post subject: Reply with quote

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
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 2607
Location: Illinois, USA

PostPosted: Mon Mar 12, 2018 5:54 pm    Post subject: Reply with quote

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
View user's profile Send private message
Elleni
Guru
Guru


Joined: 23 May 2006
Posts: 592

PostPosted: Mon Mar 12, 2018 8:35 pm    Post subject: Reply with quote

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
View user's profile Send private message
mike155
Guru
Guru


Joined: 17 Sep 2010
Posts: 566
Location: Frankfurt, Germany

PostPosted: Mon Mar 12, 2018 9:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
Luke-Jr
n00b
n00b


Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org

PostPosted: Mon Mar 12, 2018 10:03 pm    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 12826

PostPosted: Tue Mar 13, 2018 1:37 am    Post subject: Reply with quote

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:
  1. The program relies on undefined behavior.
  2. 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
View user's profile Send private message
Hossie
Tux's lil' helper
Tux's lil' helper


Joined: 08 Dec 2005
Posts: 108

PostPosted: Tue Mar 13, 2018 6:57 pm    Post subject: Reply with quote

Omg there is a new microcode.

I opened 650428 for some quick bumping. :D
Back to top
View user's profile Send private message
mike155
Guru
Guru


Joined: 17 Sep 2010
Posts: 566
Location: Frankfurt, Germany

PostPosted: Wed Mar 14, 2018 12:39 pm    Post subject: Reply with quote

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
View user's profile Send private message
Ska`
n00b
n00b


Joined: 25 Sep 2004
Posts: 74

PostPosted: Wed Mar 14, 2018 2:24 pm    Post subject: Reply with quote

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
View user's profile Send private message
Spargeltarzan
Apprentice
Apprentice


Joined: 23 Jul 2017
Posts: 266

PostPosted: Tue Mar 20, 2018 3:40 pm    Post subject: Reply with quote

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
View user's profile Send private message
Ska`
n00b
n00b


Joined: 25 Sep 2004
Posts: 74

PostPosted: Tue Mar 20, 2018 4:36 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3 ... , 21, 22, 23  Next
Page 22 of 23

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum