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 ... 12, 13, 14, 15, 16  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
mike155
Apprentice
Apprentice


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

PostPosted: Fri Jan 12, 2018 10:19 pm    Post subject: Reply with quote

Current status of Linux kernel patches regarding Meltdown / Spectre: https://marc.info/?l=linux-kernel&m=151579356820020&w=2
Thomas Gleixner wrote:
... To be honest the last 10 days were more horrible than the whole PTI work
due to lack of documentation, 12 different opinions when asking 8 people
(why does this have a lawyer smell?) and an amazing amount of half baken
and hastily cobbled together crap. ...
Back to top
View user's profile Send private message
gengreen
n00b
n00b


Joined: 23 Dec 2017
Posts: 55

PostPosted: Fri Jan 12, 2018 10:24 pm    Post subject: Reply with quote

Code:
sys-firmware/intel-microcode 20180108-r1


Code:
[0.000000] microcode: microcode updated early to revision 0xc2, date = 2017-11-16
[    2.700454] microcode: sig=0x506e3, pf=0x20, revision=0xc2
[    2.700562] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba


Gcc has release a -r1 update, after the emerge of this

Code:
emerge -e @world


Will do ? I have to rebuilding my kernel with the new gcc patched as well ?

Thanks,
Back to top
View user's profile Send private message
mike155
Apprentice
Apprentice


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

PostPosted: Fri Jan 12, 2018 10:48 pm    Post subject: Reply with quote

Spargeltarzan wrote:
Does gcc-r1 have something todo with spectre?

As far as I can see: no

The difference between gcc-6.4.0 and gcc-6.4.0-r1 is:
Code:
95_all_static_override_pie.patch
96_all_powerpc_pie.patch
97_all_libjava-ucontext.patch

These patches are not related to Meltdown / Spectre.
Back to top
View user's profile Send private message
mike155
Apprentice
Apprentice


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

PostPosted: Fri Jan 12, 2018 10:57 pm    Post subject: Reply with quote

gengreen wrote:
emerge -e @world

Why do you want to rebuild your world? What do you want to achieve?
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 16821

PostPosted: Fri Jan 12, 2018 11:03 pm    Post subject: Reply with quote

mike155 wrote:
Current status of Linux kernel patches regarding Meltdown / Spectre: https://marc.info/?l=linux-kernel&m=151579356820020&w=2
Thomas Gleixner wrote:
... To be honest the last 10 days were more horrible than the whole PTI work
due to lack of documentation, 12 different opinions when asking 8 people
(why does this have a lawyer smell?) and an amazing amount of half baken
and hastily cobbled together crap. ...
And on that note, I was about to ask for some clarification.

I keep seeing comments similar to AMD isn't affected by Meltdown, which I associated with the kernel option "CONFIG_PAGE_TABLE_ISOLATION=y" not being needed for AMD CPUs.

Am I mistaken?

I'm asking for two reasons. First, I haven't seen a source for this claim other than that supposedly AMD says they aren't impacted. That's fine, but doesn't explain what C_P_T_I is actually doing.

Which brings me to the second reason I'm seeking source clarification:
Meltdown vulnerability and KPTI wrote:
AMD x86 processors are not currently known to be affected by Meltdown and don't need KPTI to mitigate them.[13][24] However, AMD processors are still susceptible to KASLR bypass when KPTI is disabled.
Emphasis added.
Back to top
View user's profile Send private message
gengreen
n00b
n00b


Joined: 23 Dec 2017
Posts: 55

PostPosted: Fri Jan 12, 2018 11:13 pm    Post subject: Reply with quote

mike155 wrote:
gengreen wrote:
emerge -e @world

Why do you want to rebuild your world? What do you want to achieve?


I tought this new update of gcc was about the new feature that will help against meltdown/spectre.

Anyway, when the update of gcc will have some protection for meltdown/spectre, rebuilding my entire system to have the full benefit of it, is what I should do no ?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39631
Location: 56N 3W

PostPosted: Fri Jan 12, 2018 11:22 pm    Post subject: Reply with quote

gengreen,

The fixes are not yet completely in place and some details remain to be worked out.
The honest answer today is that nobody knows for sure.

It may be enough to rebuild the kernel to improve the mitigation.
You need a new kernel and new microcode built with your current gcc now but maybe not if you have AMD.
See the questions pjp is asking.

A patch to gcc to address meltdown/spectre will be a minor version bump from gcc upstream, not a -rx bump from gentoo.
Look for gcc-6.5 or gcc-7.3 and the like.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
gengreen
n00b
n00b


Joined: 23 Dec 2017
Posts: 55

PostPosted: Sat Jan 13, 2018 12:16 am    Post subject: Reply with quote

NeddySeagoon wrote:
gengreen,

The fixes are not yet completely in place and some details remain to be worked out.
The honest answer today is that nobody knows for sure.

It may be enough to rebuild the kernel to improve the mitigation.
You need a new kernel and new microcode built with your current gcc now but maybe not if you have AMD.
See the questions pjp is asking.

A patch to gcc to address meltdown/spectre will be a minor version bump from gcc upstream, not a -rx bump from gentoo.
Look for gcc-6.5 or gcc-7.3 and the like.


Thank you for those details. You are right, I should use the term, mitigation instead of protection.

I'm a lucky possessor of a i7 intel Skylake, fully compatible with meltdown and spectre :P

intel-microcode is updated, kernel not yet, using a non-standard one (minipli) which haven't release an update for meltdown.

Regarding Gcc when the version 6-5 or 7-3 will be release,
Code:
emerge -e @world
could improve, even if it is minor, the mitigation against meltdown/spectre ?

Planning to buy a new laptop in few month, Intel will be out of buying list (Meltdown/Spectre aren't the only reason why, just the trigger).
Back to top
View user's profile Send private message
mike155
Apprentice
Apprentice


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

PostPosted: Sat Jan 13, 2018 12:23 am    Post subject: Reply with quote

pjp wrote:
First, I haven't seen a source for this claim other than that supposedly AMD says they aren't impacted.

Here are the sources that I know of:
1) Mail from Tom Lendacky (AMD). His explanation seems plausible, but we can't do more than believe him.
2) Linux kernel commit message: "Exclude AMD from the PTI enforcement. Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead"
Back to top
View user's profile Send private message
PrSo
n00b
n00b


Joined: 01 Jun 2017
Posts: 36

PostPosted: Sat Jan 13, 2018 1:13 am    Post subject: Reply with quote

pjp wrote:

I'm asking for two reasons. First, I haven't seen a source for this claim other than that supposedly AMD says they aren't impacted. That's fine, but doesn't explain what C_P_T_I is actually doing.


Second that, but I think that you are asking about things restricted under patent protection and other information which constitutes the company secret and cannot be made generally available.


pjp wrote:
Which brings me to the second reason I'm seeking source clarification:
Meltdown vulnerability and KPTI napisał:
AMD x86 processors are not currently known to be affected by Meltdown and don't need KPTI to mitigate them.[13][24] However, AMD processors are still susceptible to KASLR bypass when KPTI is disabled.


Personally I think that the second question needs an explanation of CPU engineer with exact knowledge of AMD CPU architecture including mentioned above company secrets which could not be answered without making him a breacher.

I think that in this situation we have to trust Tom Lendacky and AMD for now.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 16821

PostPosted: Sat Jan 13, 2018 1:17 am    Post subject: Reply with quote

mike155 wrote:
pjp wrote:
First, I haven't seen a source for this claim other than that supposedly AMD says they aren't impacted.

Here are the sources that I know of:
1) Mail from Tom Lendacky (AMD). His explanation seems plausible, but we can't do more than believe him.
2) Linux kernel commit message: "Exclude AMD from the PTI enforcement. Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead"
Thanks. I have seen those. Given the date, the first message didn't seem necessarily definitive, which then made Linus' comment seem a bit like "if you say so."

But like I said, that's fine. Then there's the KASLR issue which the wikipedia page seems to relate to the page isolation table setting, which contradicts the claims or perception that AMD doesn't need the setting. So I guess it is mainly the KASLR issue I'm wondering about.

I have searched, but most links seem more noise than signal.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 16821

PostPosted: Sat Jan 13, 2018 1:24 am    Post subject: Reply with quote

PrSo wrote:
Second that, but I think that you are asking about things restricted under patent protection and other information which constitutes the company secret and cannot be made generally available.
Yeah, I can accept that. It is mainly how it relates to my second query.

PrSo wrote:
pjp wrote:
Which brings me to the second reason I'm seeking source clarification:
Meltdown vulnerability and KPTI napisał:
AMD x86 processors are not currently known to be affected by Meltdown and don't need KPTI to mitigate them.[13][24] However, AMD processors are still susceptible to KASLR bypass when KPTI is disabled.


Personally I think that the second question needs an explanation of CPU engineer with exact knowledge of AMD CPU architecture including mentioned above company secrets which could not be answered without making him a breacher.

I think that in this situation we have to trust Tom Lendacky and AMD for now.
Sure. With this event being released / announced in the way it has, the messaging seems to lack clarity. And I haven't seen much related to KASLR (it could be in one of the CVEs, which would demonstrate why marketing names for vulnerabilities is a Bad Idea).
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11613

PostPosted: Sat Jan 13, 2018 1:28 am    Post subject: Reply with quote

pjp wrote:
doesn't explain what C_P_T_I is actually doing.
CONFIG_PAGE_TABLE_ISOLATION=y builds and default-enables code that, if not disabled at boot time via kernel command line, removes many (but not all) kernel page table entries prior to running user code, then restores those page table entries when entering kernel mode. The commonly accepted code sequence for exploiting Meltdown requires that the page table entry for the kernel code/data be present, since affected CPUs can speculate past the permission restriction (reading in user mode a page that was marked as kernel-access-only), but cannot speculate a read when the entry is missing entirely, since it needs that page table entry to tell it what physical page to read. With the PTE wholly absent, it cannot tell where to speculatively read, so it doesn't read at all, and the Meltdown exploit fails.
pjp wrote:
Quote:
However, AMD processors are still susceptible to KASLR bypass when KPTI is disabled.
Emphasis added.
As I understand the underlying research, this KASLR bypass is implemented as:
  • Perform an expected-to-fail read of an address which may be unmapped or may be mapped as kernel-only.
  • After it fails, try again.
    • If the second failure is as slow as the first, it is (probably) because the address is unmapped, so the CPU performed a full page table walk each time.
    • If the second failure is faster, it is because the CPU had copied the kernel-only page table entry into the TLB while resolving the first fault, and so is able to quickly determine that access is still not allowed.
This technique was believed only to serve as a tri-state classifier of whether the page was: readable-to-user (and kernel), readable-to-kernel (but not user), unreadable-to-all (because it does not exist). By differentiating between r-t-k and u-t-a, you can find where kernel pages exist, even if you cannot read them. KAISER, and later KPTI, prevent this by causing all unnecessary kernel pages to be missing, so you cannot tell if the page is u-t-a because it never exists or if it is u-t-a because it exists only when the kernel is running.

The AMD claims that Meltdown do not apply to their CPUs appear to be specifically that AMD CPUs are immune to the new concept of divining memory contents by profiling the speculative execution. The researchers allege, and I have not seen AMD deny, that AMD CPUs are still vulnerable to the weaker attack of KASLR bypass, since that only requires determining whether the page exists in the page table (as a hidden kernel-only page) versus does not exist at all. KAISER was designed to stop that weaker attack, and KPTI, as a derivative of KAISER, stops KASLR bypass as a happy side effect. Most people are focused on using KPTI to stop the far more severe (and allegedly Intel-only out-of-order-only) Meltdown attack.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 16821

PostPosted: Sat Jan 13, 2018 1:36 am    Post subject: Reply with quote

@Hu:

Excellent, thank you!

That sounds to me like CONFIG_PAGE_TABLE_ISOLATION should be enabled for AMD processors. Or at least not setting it with the knowledge of leaving the vulnerability exposed.
Back to top
View user's profile Send private message
ian.au
Guru
Guru


Joined: 07 Apr 2011
Posts: 401
Location: Australia

PostPosted: Sat Jan 13, 2018 1:43 am    Post subject: Reply with quote

Hu,
Thanks for taking the trouble to post one of the clearest summaries of those measures I've read.
Back to top
View user's profile Send private message
PrSo
n00b
n00b


Joined: 01 Jun 2017
Posts: 36

PostPosted: Sat Jan 13, 2018 1:48 am    Post subject: Reply with quote

@Hu
IDKWTS, thank you very much.
Back to top
View user's profile Send private message
mike155
Apprentice
Apprentice


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

PostPosted: Sat Jan 13, 2018 3:00 am    Post subject: Reply with quote

Yesterday I posted performance measurement results and asked a question:
Quote:
The test shows a performance degradation of nearly 30% (!) for Linux systems running in a QEMU VM.
[...]
Does anyone have a clue, why the difference between pti and nopti is so much larger in a VM?

Good news: the performance degradation of nearly 30% I measured yesterday is - to a large extent - not a consequence of the Meltdown kernel patches, but a consequence of a missing CPU flag of my guest's CPU. During my tests yesterday, I started QEMU with the parameter "-cpu SandyBridge" and the guest's CPU did NOT have the CPU flag "pcid". Today I repeated the tests with QEMU parameter "-cpu SandyBridge,+pcid" and the guest's CPU had the CPU flag "pcid". Performance degradation between pti and nopti went down to (only) 9%.
Code:
Test: time emerge -B glibc >/dev/null

Yesterday's results (QEMU parameter: -cpu SandyBridge)
-------------------------------+---------------------+--------------+------
Kernel & config                | time [s]            | mean [s]     | rel.
of QEMU VM                     | (3 measurements)    |              |
-------------------------------+---------------------+--------------+------
4.9.65 as of Nov. 2017         | 320.8, 320.9, 320.7 | 320.8 ± 0.1  | 100%
4.14.13, CONFIG_PTI=no,        | 324.2, 324.6, 325.0 | 324.2 ± 0.4  | 101%
4.14.13, CONFIG_PTI=yes, nopti | 327.2, 326.6, 325,3 | 327.2 ± 1.0  | 102%
4.14.13, CONFIG_PTI=yes, pti   | 411.7, 417.4, 412.7 | 411.7 ± 3.0  | 128%
-------------------------------+---------------------+--------------+------

Today's results (QEMU parameter: -cpu SandyBridge,+pcid)
-------------------------------+---------------------+--------------+------
Kernel & config                | time [s]            | mean [s]     | rel.
of QEMU VM                     | (3 measurements)    |              |
-------------------------------+---------------------+--------------+------
4.14.13, CONFIG_PTI=yes, nopti | 322.1, 324.3, 323.0 | 323.1 ± 1.1  | 100%
4.14.13, CONFIG_PTI=yes, pti   | 349.1, 350.2, 350.9 | 350.1 ± 0.9  | 109%
-------------------------------+---------------------+--------------+------

Remarks:
- CONFIG_PTI: guest kernel configuration parameter 'CONFIG_PAGE_TABLE_ISOLATION'
- pti, npti: guest kernel command line parameter
- Host: Intel Xeon CPU E3-1245 V2, x86_64, 32GB Ram, Kernel 4.14.12, pti
- Qemu: 2.10.1-r1, virtio devices
- Guest: 2 Core x86_64, 4 GB RAM, /var/tmp is tmpfs

Conclusion:
In order to avoid performance degradation in VMs due to Meltdown / Spectre patches, it is important that hypervisors enable the CPU flag "pcid" for guest CPUs if the flag is supported by the host's CPU. The same is probably true for the CPU flag "invpcid" (I can't test it, since I don't have a Haswell+ CPU).
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6445
Location: almost Mile High in the USA

PostPosted: Sat Jan 13, 2018 3:53 am    Post subject: Reply with quote

...which is unfortunate, my VM host is a Core2 Quad...

Need to test a 32-bit world in a container, to see if it's a viable option...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
Aiken
Apprentice
Apprentice


Joined: 22 Jan 2003
Posts: 197
Location: Toowoomba/Australia

PostPosted: Sat Jan 13, 2018 4:41 am    Post subject: Reply with quote

mike155 wrote:

In order to avoid performance degradation in VMs due to Meltdown / Spectre patches, it is important that hypervisors enable the CPU flag "pcid" for guest CPUs if the flag is supported by the host's CPU. The same is probably true for the CPU flag "invpcid" (I can't test it, since I don't have a Haswell+ CPU).


Which comes back to what I was thinking during my last post, the core2 will now have problems being a kvm host. I have been using -cpu host so my testing on an i7 already showed that instruction. My normal vm host is an i5 2500k which has pcid. This does not help the core2 which does not have that instruction. My last test on it was showing both cores up to 50% just in syscalls. For various values of bad I am hoping the i5 won't be too bad. I have given up on any idea for running kvm on the core2.

On the i7 set -cpu core2duo and my kernel compile test with pti=on, the time went from 22 - 23 seconds up to 24 - 34 seconds.
_________________
Beware the grue.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 5408
Location: Room 101

PostPosted: Sat Jan 13, 2018 3:05 pm    Post subject: Reply with quote

WRT performance: retpoline fix supposedly solves performance hits for spectre.

best ... khay
Back to top
View user's profile Send private message
transsib
l33t
l33t


Joined: 26 Jul 2003
Posts: 787

PostPosted: Sat Jan 13, 2018 5:47 pm    Post subject: Reply with quote

Gotta make myself a sticky on desktop to pay attention to etc-update.
It wanted to overwrite /etc/grub.d/10_linux. The update would have removed
Code:
if test -e "${dirname}/${i}" ; then
      initrd="early_ucode.cpio ${rel_dirname}/${i}"
      break
    else
      initrd="early_ucode.cpio"
Back to top
View user's profile Send private message
Aiken
Apprentice
Apprentice


Joined: 22 Jan 2003
Posts: 197
Location: Toowoomba/Australia

PostPosted: Sat Jan 13, 2018 7:31 pm    Post subject: Reply with quote

Wondering how many people are going to get caught out by the cpio archive being moved from /lib/firmware/microcode.cpio to /boot/intel-uc.img. Not a nice surprise turning on my pc and being greeted by grub complaining file not found. Thankfully a couple of headless boxes had not been rebooted yet.
_________________
Beware the grue.
Back to top
View user's profile Send private message
luiztux
n00b
n00b


Joined: 31 Aug 2015
Posts: 25
Location: /usr/portage/distfiles

PostPosted: Sat Jan 13, 2018 11:08 pm    Post subject: Reply with quote

Here we go again. It seems that there is another security flaw with Intel firmwares.

https://arstechnica.com/information-technology/2018/01/researcher-finds-another-security-flaw-in-intel-management-firmware/
Back to top
View user's profile Send private message
ian.au
Guru
Guru


Joined: 07 Apr 2011
Posts: 401
Location: Australia

PostPosted: Sat Jan 13, 2018 11:19 pm    Post subject: Reply with quote

luiztux wrote:
Here we go again. It seems that there is another security flaw with Intel firmwares.

https://arstechnica.com/information-technology/2018/01/researcher-finds-another-security-flaw-in-intel-management-firmware/


That 'exploit' is neither new nor unique to intel, classic FUD
Back to top
View user's profile Send private message
mno
Guru
Guru


Joined: 29 Dec 2003
Posts: 304
Location: Toronto, Canada

PostPosted: Sun Jan 14, 2018 12:41 am    Post subject: Reply with quote

Sorry for a potentially stupid question. I run quite an old Intel Xeon 5500 arch, but run 'amd64' - most of the comments seem to be related to 'x86'. It doesn't seem to make a difference whether I ran amd64 or x86 in this case, as long as it's an Intel CPU, correct?
_________________
"Hello and goodbye. As always." | You can't use &nbsp; here?? | Unanswered
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3 ... 12, 13, 14, 15, 16  Next
Page 13 of 16

 
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