Gentoo Forums :: View topic - Meltdown/Spectre: Unauthorized Disclosure of Kernel Memory

Meltdown/Spectre: Unauthorized Disclosure of Kernel Memory

View unanswered posts
View posts from last 24 hours

Goto page Previous 1, 2, 3, 4, 5, 6 ... 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

The Main Man
Veteran
Veteran

Joined: 27 Nov 2014
Posts: 1166
Location: /run/user/1000

Posted: Fri Jan 05, 2018 12:53 pm Post subject:

yamabiko wrote:

Is there a PoC that works on older processors?
Both https://github.com/Eugnis/spectre-attack/ and https://github.com/gkaindl/meltdown-poc (only for OSX ?) are not working on my core2.

I asked the author and he promptly responded with the version that now works in my case.
What confuses me is that message isn't recovered and Spectre isn't patched AFAIK.

Check it here :
https://github.com/Eugnis/spectre-attack/issues/6

krinn
Watchman

Joined: 02 May 2003
Posts: 7470

Posted: Fri Jan 05, 2018 1:50 pm Post subject:

because the new version is just buggy

on my x86 core2: old version fail with the illegal instruction, and new version cannot leak anything
on my x86-64 corei7 : old version work, and new version cannot leak anything

Code:

Last edited by krinn on Fri Jan 05, 2018 1:54 pm; edited 2 times in total

PrSo
Tux's lil' helper

Joined: 01 Jun 2017
Posts: 136

Posted: Fri Jan 05, 2018 1:51 pm Post subject:

I don't know how much it is relevant in this case, but reading papers about spectre in accordance of AMD vulnerability discovered that CONFIG_HAVE_EBPF_JIT is enabled in my kernel config. The papers state that spectre 1 can be triggered in assumption that eBPF and JIT are enabled in config which should not be default, or maybe matters that the code is executed locally not remotely. Did I misunderstood something? Last edited by PrSo on Fri Jan 05, 2018 2:04 pm; edited 1 time in total

yamabiko
n00b
n00b

Joined: 22 Jul 2017
Posts: 10

Posted: Fri Jan 05, 2018 1:54 pm Post subject:

kajzer wrote:

yamabiko wrote:

Is there a PoC that works on older processors?
Both https://github.com/Eugnis/spectre-attack/ and https://github.com/gkaindl/meltdown-poc (only for OSX ?) are not working on my core2.

Same result with an unpatched kernel.

rburcham
Apprentice

Joined: 20 Mar 2003
Posts: 243

Posted: Fri Jan 05, 2018 2:04 pm Post subject:

Some intrepid mod should sticky a summary in the top post. There's a lot to know, and high risk for crosstalk and confusion. Basic info/background/history: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html Chips from Intel, AMD and ARM are affected, with tested examples of each and statements from the manufacturers in the above link (except for Intel, whose statement it seems is not worth reading). Both meltdown and spectre are variants of the same sort of attack, with meltdown targeting kernel memory and spectre targeting other in-process and external process memory that would otherwise be protected. Meltdown can be defended against with >=sys-kernel/gentoo-sources-4.14.11-r2 and CONFIG_PAGE_TABLE_ISOLATION=y, which will be set automatically should you do a make olddefconfig against your previous .config. This "fix" could result in a performance slowdown of your machine, maybe 5% - 30% depending on the type of workload, maybe nothing. Spectre does not yet have a global fix available, and there is great activity across the app community https://en.wikipedia.org/wiki/Spectre%5f%28security%5fvulnerability%29#Mitigation, particularly in the web browser community https://www.mozilla.org/en-US/security/advisories/mfsa2018-01/, to address the risk app by app. Last edited by rburcham on Fri Jan 05, 2018 2:15 pm; edited 2 times in total

mv
Watchman

Joined: 20 Apr 2005
Posts: 6747

Posted: Fri Jan 05, 2018 2:09 pm Post subject:

krinn wrote:

anyone also notice that pie made it worst?

If the attacker can execute arbitrary code, he can choose pie or no-pie or whatever he wants.

Quote:

without pie i nearly always get a 2 score.

I think that this is accident on your system. Here, pie doesn't influence the result; only sometimes (independent of pie) it needs longer. I suppose that it has more to do with scheduling/interrupt policy of the rest of your system. It might be that pie or non-pie is just by accident advantageous for a certain system.

The Main Man
Veteran
Veteran

Joined: 27 Nov 2014
Posts: 1166
Location: /run/user/1000

Posted: Fri Jan 05, 2018 2:14 pm Post subject:

krinn wrote:

because the new version is just buggy

Could be, he said to try changing threshold value, I tried with few values and I got some chars instead of '?' , but not the original message.
Maybe if I was to play the whole routine through some loop I would get the right one....

Anyhow, he also said that my cpu (Intel(R) Pentium(R) Dual CPU E2180) isn't in the affected list, which is interesting.
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

krinn
Watchman

Joined: 02 May 2003
Posts: 7470

Posted: Fri Jan 05, 2018 2:31 pm Post subject:

kajzer wrote:

Could be, he said to try changing threshold value

i didn't change it, but both use 80, i tried change -thread version to 120 with same result.

rather than be in the list or not, is your cpu running x86-64? because i'm sure my core2 is in it, but the non-thread doesn't work (with the same illegal instruction) and the -thread version run, but fail also on my x86-64 where the non-thread is able to leak info.

for now, the only thing you should conclude: it work on x86-64 for first version, the thread version do nothing.

mv: yeah right, he won't build it with -pie

yamabiko
n00b
n00b

Joined: 22 Jul 2017
Posts: 10

Posted: Fri Jan 05, 2018 2:44 pm Post subject:

kajzer wrote:

Anyhow, he also said that my cpu (Intel(R) Pentium(R) Dual CPU E2180) isn't in the affected list, which is interesting.
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

Well, it seems that Penryn Core 2 processors aren't in the list too.
I've tried to change rdtscp to rdtsc, the code compiles but it shows '?' and/or random characters.
Regarding Meltdown, I also tried this https://github.com/corsix/meltdown-poc on an unpatched kernel and it runs on an i5 while it fails with "Illegal instruction" on the core2.

The Main Man
Veteran
Veteran

Joined: 27 Nov 2014
Posts: 1166
Location: /run/user/1000

Posted: Fri Jan 05, 2018 2:49 pm Post subject:

krinn wrote:

rather than be in the list or not, is your cpu running x86-64?

Yeah, it runs x86-64.

I mean aren't ALL core2 cpu's 64-bit?
Or maybe you mean that I for some reason run x86 OS.

krinn
Watchman

Joined: 02 May 2003
Posts: 7470

Posted: Fri Jan 05, 2018 2:58 pm Post subject:

kajzer wrote:

I mean aren't ALL core2 cpu's 64-bit?
Or maybe you mean that I for some reason run x86 OS.

yes, i mean my core2 is running x86.
In case you wonder: model name : Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz

krinn
Watchman

Joined: 02 May 2003
Posts: 7470

Posted: Fri Jan 05, 2018 3:27 pm Post subject:

ok... we're in deep trouble

Code:

model name : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
bugs : cpu_insecure

uname -a
Linux beleg 4.14.11 #1 SMP PREEMPT Fri Jan 5 15:26:39 CET 2018 x86_64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz GenuineIntel GNU/Linux

dmesg | grep "iso\|Command line"
[ 0.000000] Command line: root=/dev/sdb2 pti=on
[ 0.000000] Kernel/User page tables isolation: enabled

./spectre
Putting 'The Magic Words are Squeamish Ossifrage.' in memory
Reading 40 bytes:
Reading at malicious_x = 0xffffffffffdfebe8... Success: 0x54=’T’ score=2
Reading at malicious_x = 0xffffffffffdfebe9... Success: 0x68=’h’ score=2
Reading at malicious_x = 0xffffffffffdfebea... Success: 0x65=’e’ score=2
Reading at malicious_x = 0xffffffffffdfebeb... Success: 0x20=’ ’ score=2
....

Atom2
Apprentice

Joined: 01 Aug 2011
Posts: 185

Posted: Fri Jan 05, 2018 3:27 pm Post subject:

Further information relating to XEN which just came through by E-Mail:

Quote:

Hi all, this is a repost of https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ for xen-users/xen-devel. If you have questions, please reply to this thread and we will try and improve the FAQ based on questions.
Regards
Lars

Google’s Project Zero announced several information leak vulnerabilities affecting all modern superscalar processors. Details can be found on their blog, and in the Xen Project Advisory 254 [1]. To help our users understand the impact and our next steps forward, we put together the following FAQ.

Note that we will update the FAQ as new information surfaces.

= Is Xen impacted by Meltdown and Spectre? =

There are two angles to consider for this question:

* Can an untrusted guest attack the hypervisor using Meltdown or Spectre?
* Can a guest user-space program attack a guest kernel using Meltdown or Spectre?

Systems running Xen, like all operating systems and hypervisors, are potentially affected by Spectre (referred to as SP1 and SP2 in Advisory 254 [1]). For Arm Processors information, you can find which processors are impacted here [2]. In general, both the hypervisor and a guest kernel are vulnerable to attack via SP1 and SP2.

Only Intel processors are impacted by Meltdown (referred to as SP3 in Advisory 254 [1]). On Intel processors, only 64-bit PV mode guests can attack Xen. Guests running in 32-bit PV mode, HVM mode, and PVH mode cannot attack the hypervisor using SP3. However, in 32-bit PV mode, HVM mode, and PVH mode, guest userspaces can attack guest kernels using SP3; so updating guest kernels is advisable.

Interestingly, guest kernels running in 64-bit PV mode are not vulnerable to attack using SP3, because 64-bit PV guests already run in a KPTI-like mode.

= Is there any risk of privilege escalation? =

Meltdown and Spectre are, by themselves, only information leaks. There is no suggestion that speculative execution can be used to modify memory or cause a system to do anything it might not have done already.

= Where can I find more information? =

We will update this blog post and Advisory 254 [1] as new information becomes available. Updates will also be published on xen-announce@.

We will also maintain a technical FAQ on our wiki [3] for answers to more detailed technical questions that emerge on xen-devel@ and other communication channels.

= Are there any patches for the vulnerability? =

We have prototype patches for a mitigation for Meltdown on Intel CPUs and a Mitigation for SP2/CVE-2017-5715, which are functional but have not undergone rigorous review and have not been backported to all supported Xen Project releases.

As information related to Meltdown and Spectre is now public, development will continue in public on xen-devel@ and patches will be posted and attached to Advisory 254 [1] as they become available in the next few days.

= Can SP1/SP2 be fixed at all? What plans are there to mitigate them? =

SP2 can be mitigated in two ways, both of which essentially prevent speculative execution of indirect branches. The first is to flush the branch prediction logic on entry into the hypervisor. This requires microcode updates, which Intel and AMD are in the process of preparing, as well as patches to the hypervisor which are also in process and should be available soon.

The second is to do indirect jumps in a way which is not subject to speculative execution. This requires the hypervisor to be recompiled with a compiler that contains special new features. These new compiler features are also in the process of being prepared for both gcc and clang, and should be available soon.

SP1 is much more difficult to mitigate. We have some ideas we’re exploring, but they’re still at the design stage at this point.

= Does Xen have any equivalent to Linux’s KPTI series? =

Linux’s KPTI series is designed to address SP3 only. For Xen guests, only 64-bit PV guests are affected by SP3. A KPTI-like approach was explored initially, but required significant ABI changes. Instead we’ve decided to go with an alternate approach, which is less disruptive and less complex to implement. The chosen approach runs PV guests in a PVH container, which ensures that PV guests continue to behave as before, while providing the isolation that protects the hypervisor from SP3. This works well for Xen 4.8 to Xen 4.10, which is currently our priority.

For Xen 4.6 and 4.7, we are evaluating several options, but we have not yet finalized the best solution.

= Devicemodel stub domains run in PV mode, so is it still more safe to run device models in a stub domain than in domain 0? =

The short answer is, yes, it is still safer to run stub domains than otherwise.

If an attacker can gain control of the device model running in a stub domain, it can indeed attempt to use these processor vulnerabilities to read information from Xen.

However, if an attacker can gain control of a device model running in domain 0 without deprivileging, the attacker can gain control of the entire system. Even with qemu deprivileging, the qemu process may be able to execute speculative execution attacks against the hypervisor.

So although XSA-254 does affect device model stub domains, they are still safer than not running with a stub domain.

= What is the Xen Project’s plan going forward? =

The Xen Project is working on finalizing solutions for SP3 and SP2 and evaluating options for SP1. If you would like to stay abreast on our progress, please sign up to xen-announce@. We will update this FAQ as soon as we have more news and updated information. Answers to more detailed technical questions will be maintained in a technical FAQ on our wiki [3]. Thank you for your patience.

= How can I ask further questions? =
Please respond to this e-mail thread on xen-devel@ or xen-users@

References
[1] http://xenbits.xen.org/xsa/advisory-254.html
[2] https://developer.arm.com/support/security-update
[3] https://wiki.xenproject.org/wiki/Xen_Project_Meltdown_and_Spectre_Technical_FAQ
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Furthermore, for XEN there is a practical response FAQ (which is WIP) available here: https://wiki.xenproject.org/wiki/Respond_to_Meltdown_and_Spectre

Regards Atom2

Naib
Watchman

Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

Posted: Fri Jan 05, 2018 3:30 pm Post subject:

krinn wrote:

ok... we're in deep trouble

Code:

The PTI patch was only for Meltdown and intel only Back^M^M^Mug.
You are executing a Spectre testcase, which to date has NOT been patched by anyone. Spectre has always been the real concern & more of a concern for Intel than AMD
_________________

Quote:

Removed by Chiitoo

krinn
Watchman

Joined: 02 May 2003
Posts: 7470

Posted: Fri Jan 05, 2018 3:32 pm Post subject:

ah yes metldown so

Code:

./meltdown
poke buffer: 0x7ffa9ed5f000, page size: 4096
0x0000000000400fb0 | 48 6D 6D 2C 20 74 68 69 73 20 64 6F 65 73 20 72 | Hmm, this does r
0x0000000000400fc0 | 65 61 6C 6C 79 20 77 6F 72 6B 21 | eally work!

Naib
Watchman

Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

Posted: Fri Jan 05, 2018 3:38 pm Post subject:

have you tried this one? https://github.com/raphaelsc/Am-I-affected-by-Meltdown

looking over the code for a number of "meltdown" a large number are using the spectre code so people are confused there are three issues
_________________

Quote:

Removed by Chiitoo

krinn
Watchman

Joined: 02 May 2003
Posts: 7470

Posted: Fri Jan 05, 2018 3:57 pm Post subject:

Naib wrote:

Thanks, it's meldown from upper link

I'll see if this one report the same problem with pti=on, and i could reboot to my previous kernel to see how it will react too.

edit: ah well, not really reliable, it miserably fail, even as root

Code:

# ./meltdown-checker
Unable to find symbol sys_call_table in /proc/kallsyms
Falling back on the alternative symbol map file (usually requires root permission): /boot/System.map-4.14.11...
Failed to open /boot/System.map-4.14.11. Unable to proceed.
Abandon

ah lol ok

Code:

mount /boot
./meltdown-checker
Unable to find symbol sys_call_table in /proc/kallsyms
Falling back on the alternative symbol map file (usually requires root permission): /boot/System.map-4.14.11...
Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ...
Checking syscall table (sys_call_table) found at address 0xffffffff81a00120 ...
0x4343434301e71603 -> That's unknown
0x0303030303c75303 -> That's unknown
0xa3c3c3c3c3c30f18 -> That's unknown
0xa3a3a3a30f200f20 -> That's unknown
0x0707f3f3f3f3f30f -> That's unknown
0xb7b70f4367870f20 -> That's unknown
0x3337332720202707 -> That's unknown
0x20d3d3d3d3d3e320 -> That's unknown
0x1313130f0f070f0f -> That's unknown
0xa3a3570f570f5720 -> That's unknown
0x6767676720202020 -> That's unknown
0x2323030303030303 -> That's unknown
0x67676767670f2020 -> That's unknown
0x030303070f182020 -> That's unknown
0x0f2323232323201a -> That's unknown
0x6767c3c307070707 -> That's unknown
0x074303030303030f -> That's unknown
0x7373a3a3a320200f -> That's unknown
0x6767670f2020200f -> That's unknown
0xe7e7e7e7e7e70707 -> That's unknown
0xb7b7b7b70f20200f -> That's unknown
0x0f20f3f3f3f30f87 -> That's unknown
0xb7b7b7b7b7070707 -> That's unknown
0x2020232323232323 -> That's unknown
0xe387878787870f0f -> That's unknown
0x73737373200f2020 -> That's unknown
0x7373e3e3e3e32020 -> That's unknown
0xc7c7d3c70f20200f -> That's unknown
0x434320201a0f0f0f -> That's unknown
0x87878787870f200f -> That's unknown
0x200f0f200f0f0f20 -> That's unknown
0x732323232727180f -> That's unknown
0xd3d3d3d307070707 -> That's unknown
0x37370f1820015707 -> That's unknown
0xb7b72093930f0f0f -> That's unknown
0xb7b7b7e3e3e3e3e3 -> That's unknown
0x73c3474747470f20 -> That's unknown
0x20535753200f0f20 -> That's unknown
0xd3d3878787878720 -> That's unknown
0x3737333737202020 -> That's unknown
0x6767170f170f170f -> That's unknown
0xb7b7b7b7b7202018 -> That's unknown
0x030303a3a3a3a3a3 -> That's unknown
0x204747530f47200f -> That's unknown
0xe7e7e7e71820200f -> That's unknown
0x676703030303030f -> That's unknown
0xc3c3c3c3c3070707 -> That's unknown
0x1717172323230707 -> That's unknown
0xb720570f200f0f20 -> That's unknown
0xf3f3f3f320202020 -> That's unknown

System not affected. Congratulations!

I'll go try 4.4.78 (my previous kernel)

back with 4.4.78:

Code:

./meltdown-checker Unable to find symbol sys_call_table in /proc/kallsyms
Falling back on the alternative symbol map file (usually requires root permission): /boot/System.map-4.4.78...
Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ...
Checking syscall table (sys_call_table) found at address 0xffffffff8142e120 ...
0x0723230700070707 -> That's unknown
0xffffffff8110c160 -> That's SyS_write

System affected! Please consider upgrading your kernel to one that is patched with KAISER
Check https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html for more details

So you're right naib, prevous link for meltdown is bad.

The Main Man
Veteran
Veteran

Joined: 27 Nov 2014
Posts: 1166
Location: /run/user/1000

Posted: Fri Jan 05, 2018 4:15 pm Post subject:

krinn wrote:

yes, i mean my core2 is running x86.

Yeah, well it doesn't work in both cases then it seems.
Right now I'm not sure if that's because core2 isn't affected with spectre and meltdown or there's no PoC that works right with those old cpu's.
cat /proc/cpuinfo reports cpu_insecure bug though, hmm :roll:

krinn
Watchman

Joined: 02 May 2003
Posts: 7470

Posted: Fri Jan 05, 2018 4:18 pm Post subject:

kajzer wrote:

cat /proc/cpuinfo reports cpu_insecure bug though, hmm :roll:

Until proof a cpu is not affect, all X86 cpu are just mark insecure ; it doesn't mean yours is, just that it is default mark insecure.

Last edited by krinn on Fri Jan 05, 2018 4:21 pm; edited 1 time in total

Naib
Watchman

Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

Posted: Fri Jan 05, 2018 4:20 pm Post subject:

kajzer wrote:

krinn wrote:

yes, i mean my core2 is running x86.

core2 definitely is affected.

kajzer wrote:

cat /proc/cpuinfo reports cpu_insecure bug though, hmm :roll:

That just means pti is enabled NOT that it has detected an insecure cpu
_________________

Quote:

Removed by Chiitoo

krinn
Watchman

Joined: 02 May 2003
Posts: 7470

Posted: Fri Jan 05, 2018 4:55 pm Post subject:

Naib wrote:

That just means pti is enabled NOT that it has detected an insecure cpu

Not really, it doesn't mean pti is enable, just that the kernel has pti and the insecure status, and all x86 cpu are tag as insecure for now, amd has already sent a patch to get them out of the list http://lkml.iu.edu/hypermail/linux/kernel/1712.3/00675.html

There's no detection, just a white/black list of cpu
And having pti disable doesn't change it. (but having a cpu not tag insecure should indeed disable pti).

Code:

grep cpu_insecure /proc/cpuinfo && dmesg | grep "iso\|Command line"
...
bugs : cpu_insecure
[ 0.000000] Command line: root=/dev/sdb2 pti=off
[ 0.000000] Kernel/User page tables isolation: disabled on command line.

hard times for intel

Last edited by krinn on Fri Jan 05, 2018 5:01 pm; edited 1 time in total

Naib
Watchman

Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

Posted: Fri Jan 05, 2018 5:01 pm Post subject:

krinn wrote:

Naib wrote:

That just means pti is enabled NOT that it has detected an insecure cpu

Code:

grep cpu_insecure /proc/cpuinfo && dmesg | grep "Command line"
bugs    : cpu_insecure
bugs    : cpu_insecure
bugs    : cpu_insecure
bugs    : cpu_insecure
bugs    : cpu_insecure
bugs    : cpu_insecure
bugs    : cpu_insecure
bugs    : cpu_insecure
[ 0.000000] Command line: root=/dev/sdb2 pti=off

that what I said (－‸ლ)
The kernel doesn't do any form of detection, it is purely driven by the status of pti (on = mark insecure, off = don't mark). the rc6 has this for all x86 but rc7 (or final) will check for AMD CPU's as meltdown is intel-only.
_________________

Quote:

Removed by Chiitoo

krinn
Watchman

Joined: 02 May 2003
Posts: 7470

Posted: Fri Jan 05, 2018 5:03 pm Post subject:

Naib wrote:

it is purely driven by the status of pti (on = mark insecure, off = don't mark).

i've edit to you shown you better pti doesn't do anything to the insecure status, but the insecure status should do something on pti.

Naib
Watchman

Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

Posted: Fri Jan 05, 2018 5:11 pm Post subject:

You post is still wrong...
There is no whitelist of CPU's, the present RC has a blunt arch check.

Code:

+ /* Assume for now that ALL x86 CPUs are insecure */
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE

The original AMD patch and equally what is now in tip is a vendor check

Code:

+ if (c->x86_vendor != X86_VENDOR_AMD)
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

A patched kernel has PTI capability and the check to make use of it is either enabled by default or controlled via the kernel cmdline. With PTI enabled the page table isolation is enabled

EQUALLY the /proc/cpuinfo bug flag is present, independent of pti status as this is controlled by hte code I posted.

Code:

uname -a && cat /proc/cmdline && grep -m 1 bug /proc/cpuinfo
Linux fluidmotion 4.15.0-rc6 #1 SMP PREEMPT Wed Jan 3 16:07:25 GMT 2018 x86_64 AMD Ryzen 5 1600 Six-Core Processor AuthenticAMD GNU/Linux

BOOT_IMAGE=/vmlinuz-4.15.0-rc6 root=/dev/nvme0n1p2 ro video=uvesafb:1280x1024-32,mtrr:3,ywrap quiet splash libata.force=6.0 rootfstype=ext4 elevator=noop processor.max_cstate=5 pti=off

bugs : sysret_ss_attrs null_seg cpu_insecure

Now this is rc6 so it is "enabled" for all x86 and as you can see with pti off, the cpu is still marked as the bug label and the mitigation are separate. I have not pulled tip to see how an AMD cpu is flagged but I suspect the check I posted then stops teh bugs being set
_________________

Quote:

Removed by Chiitoo

sligo
Tux's lil' helper

Joined: 17 Oct 2011
Posts: 93

Posted: Fri Jan 05, 2018 5:23 pm Post subject:

I've updated to the lasted kernel in portage on all my Intel driven systems. Is it of any use to update on my AMD box as well? Or does this only slow the CPU down without any benefit?

This is my CPU from AMD:

Code:

AMD Opteron 62xx class CPU

Display posts from previous:

	Gentoo Forums Forum Index Kernel & Hardware	All times are GMT Goto page Previous 1, 2, 3, 4, 5, 6 ... 21, 22, 23 Next
Page 5 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

Copyright 2001-2024 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy