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 ... 11, 12, 13 ... 21, 22, 23  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
blopsalot
Apprentice
Apprentice


Joined: 28 Jan 2017
Posts: 231

PostPosted: Thu Jan 11, 2018 6:14 pm    Post subject: Reply with quote

Tony0945 wrote:
Quote:
remainder of these CPUs available by the end of January
Not remainder of our CPU's. It's clearly referring to CPU's from the last five years.


Yeah I took this part "We will then focus on issuing updates for older products as prioritized by our customers." as "If we get hassled by other large corporations to fix certain older products, we will. Everyone else can go $#@# themselves."
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


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

PostPosted: Thu Jan 11, 2018 6:15 pm    Post subject: Reply with quote

blopsalot wrote:
Yeah I took this part "We will then focus on issuing updates for older products as prioritized by our customers." as "If we get hassled by other large corporations to fix certain older products, we will. Everyone else can go $#@# themselves."

A safe interpretation.
Back to top
View user's profile Send private message
PrSo
Tux's lil' helper
Tux's lil' helper


Joined: 01 Jun 2017
Posts: 95

PostPosted: Thu Jan 11, 2018 6:30 pm    Post subject: Reply with quote

Maybe I am wrong, but IMHO reading paragraph as one thought, as a whole, you should think about it as "scheduling amendments releases".

Last edited by PrSo on Thu Jan 11, 2018 10:07 pm; edited 2 times in total
Back to top
View user's profile Send private message
transpetaflops
Tux's lil' helper
Tux's lil' helper


Joined: 16 May 2005
Posts: 132

PostPosted: Thu Jan 11, 2018 6:45 pm    Post subject: Reply with quote

Tony0945 wrote:
blopsalot wrote:
Yeah I took this part "We will then focus on issuing updates for older products as prioritized by our customers." as "If we get hassled by other large corporations to fix certain older products, we will. Everyone else can go $#@# themselves."

A safe interpretation.

This wouldn't be consistent with past Intel behaviour. Two previous incidents come to mind. With the Pentium FDIV bug they offered to replace every faulty CPU and with the faulty RDRAM MTH they replaced every motherboard and even included working memory. These are examples of taking responsibility which has made me stick to Intel for the past 30 years. I fully understand that there's no practical way they can replace every Intel CPU out there this time but I expect them to provide updated microcode, even for CPUs older than 5 years. If the financial burden for this would be overwhelming, I would accept to pay a nominal fee to have my older CPUs updated.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 6636

PostPosted: Thu Jan 11, 2018 6:59 pm    Post subject: Reply with quote

It's not because you deploy update kernels and fix on all "latest" cpu in your network, that it is ok to have your network fuck because that poor little server that doesn't need better than its "old" cpu to do its job, can be use to leak informations that will destroy your network security.

They have lot of work to do, and it will take time, they are putting time on newer cpu, because logically more used.
But it doesn't mean older "affected" cpu will be kept affected, even it's true they will be handle as second class citizens.

All big structures have such kind of computer running, because they do the job and don't need any upgrade cpu do keep doing it.
And obviously, there's no security in putting steel doors in an house with open windows.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


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

PostPosted: Thu Jan 11, 2018 7:36 pm    Post subject: Reply with quote

One thing companies have done in the past is give vouchers for "latest and greatest" which is unacceptable for many installations (due to revalidation costs, etc.) ...

Anyway, despite it being able to leak information, with ASLR, other than scanning the whole memory for accessing juicy bits, are there fixed address tables that can be used to pinpoint specific information in O(1) instead of O(n)?

I still use 32-bit... this really irritating.
_________________
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
mike155
Guru
Guru


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

PostPosted: Thu Jan 11, 2018 7:45 pm    Post subject: Reply with quote

Aiken: thanks for your performance measurements. I was shocked by the performance degradation you reported - especially since patches for Spectre have not even been merged.

I tried to repeat your measurements. Here are my results for time emerge -B glibc >/dev/null running in a QEMU VM on a Intel Xeon CPU E3-1245 V2 host:
Code:
-------------------------------+---------------------+--------------+------
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%
-------------------------------+---------------------+--------------+------

Remarks:
- CONFIG_PTI: kernel configuration parameter 'CONFIG_PAGE_TABLE_ISOLATION'
- pti, npti: 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

The test shows a performance degradation of nearly 30% (!) for Linux systems running in a QEMU VM. This degradation will probably become worse after Spectre patches have been merged.

The difference between pti and nopti for a Linux kernel 4.14.13 running on bare metal is only 3% - 5%.

Does anyone have a clue, why the difference between pti and nopti is so much larger in a VM? Does this happen only with QEMU? Or does it happen also with VMWare? Do we have to live with that? Or is it something that can be fixed in the kernel or in QEMU?
Back to top
View user's profile Send private message
mahdi1234
Guru
Guru


Joined: 19 Feb 2005
Posts: 534
Location: far from new world orderia

PostPosted: Thu Jan 11, 2018 9:03 pm    Post subject: Reply with quote

eccerr0r wrote:

I still use 32-bit... this really irritating.

I second this ... does it mean we're thrown away to die now?

The silly thing is gentoo doesn't really have 32 --> 64 path other than fresh install ... but I DO NOT BLAME gentoo here, just to be clear ... the whole situation just shows some animals are more equal, the story goes on farewell to all our dreams.
_________________
http://gentoo.mahdi.cz <-- gentoo package search engine
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Thu Jan 11, 2018 9:13 pm    Post subject: Reply with quote

mahdi1234 wrote:
eccerr0r wrote:

I still use 32-bit... this really irritating.

I second this ... does it mean we're thrown away to die now?

The silly thing is gentoo doesn't really have 32 --> 64 path other than fresh install ... but I DO NOT BLAME gentoo here, just to be clear ... the whole situation just shows some animals are more equal, the story goes on farewell to all our dreams.
it's not a gentoo issue, its an OS issue. If you boot a 32bit kernel it can only deal with 32bit instructions (as it switching the cpu to 32bit mode) so you are not in a position to execute 64bit instructions.

if you had a complete 32bit system and de-compressed a 64bit stage3 over your base system BUT then you have essencially polluted your system with what the 32bit kernel can only interpret as binaries with illegal instructions... you wouldn't be able to shutdown, open things etc... Lets say you did manage a clean shutdown what kernel would you then boot with? you only have a 32bit kernel and init would then segfault

The best solution is a clean install. The next best solution is booting off a sysrescue CD/USB with its 64bit kernel, de-compressing a 64bit stage3 over your /<root>, chroot into this messed up system, recompile your kernel so it is now 64bit & then do an emerge -e @world to rebuild your entire system
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
Pearlseattle
Tux's lil' helper
Tux's lil' helper


Joined: 04 Oct 2007
Posts: 135
Location: Switzerland

PostPosted: Thu Jan 11, 2018 10:49 pm    Post subject: Reply with quote

Fyi just to recap about my CPUs:

  • i5-6200U (000406E3) patched with sys-firmware/intel-microcode-20171117_p20171215-r1
  • E3-1260L v5 (000506E3) patched with sys-firmware/intel-microcode-20180108

E3-1271 v3 (000306C3) (which I think are a relatively big bunch of servers on hetzner.de) haven't been patched yet (my current microcode still stuck to "0x1d" after having downloaded "sys-firmware/intel-microcode-20180108-r1") :cry:
Didn't check yet other servers/PCs as low priority... .
Back to top
View user's profile Send private message
Aiken
Apprentice
Apprentice


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

PostPosted: Fri Jan 12, 2018 1:11 am    Post subject: Reply with quote

mike155 wrote:

Does anyone have a clue, why the difference between pti and nopti is so much larger in a VM? Does this happen only with QEMU? Or does it happen also with VMWare? Do we have to live with that? Or is it something that can be fixed in the kernel or in QEMU?


Repeated the same test on an i7 7700k with ssd. The run time on the i7 was not long enough to get a good % time difference. 22 seconds with no kpti in the guest and 22 - 23 seconds with kpti in the guest. On the i7 I let qemu have all 4 cores. Only difference I noticed was on the host where cpu load was higher with host + guest having kpti on vs off and no danger of running out of cpu. Storage was a 20G file. 22 seconds on the i7 vs a min of 21 minutes on the core2.

On the core2 letting qemu use both cores I think the host was running out of cpu. Watching top both the sy and wa columns are higher with kpti on. It was spending a lot more time in syscalls and waiting for io. Also the core2 does not have the pcid instruction which a few things on the net say helps with any speed loss. For storage with qemu tried both a 20G file and a 20G slice on lvm.

The machine I want to run kvm on is still at 3.14.17 due to some old stuff that is still in use and not wanting to touch something that "just works". It is an i5 2500k, has the pcid instruction, faster ram, still hard drives instead of ssd. Not sure what it will be like. My take away from this is while the core2 is still overkill for general use for some people I know forget about using it as a kvm server.

Naib wrote:

it's not a gentoo issue, its an OS issue. If you boot a 32bit kernel it can only deal with 32bit instructions (as it switching the cpu to 32bit mode) so you are not in a position to execute 64bit instructions.


It is not hard to do a 32 to 64 bit conversion. The 1st thing is install crossdev to build a 64 bit tool chain to build a 64 bit kernel. Have done a few 32 to 64 conversions. A mistake will leave a person needing their favourite install media. The worst bit I found was the apprehension after typing reboot on the headless boxes.
_________________
Beware the grue.
Back to top
View user's profile Send private message
transsib
l33t
l33t


Joined: 26 Jul 2003
Posts: 795

PostPosted: Fri Jan 12, 2018 3:54 pm    Post subject: Reply with quote

For the new gcc revision I started a emerge -e @world for test purposes only.
After one hour only 280 packages have been compiled.
I don't know % but performance drop is palpable.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Fri Jan 12, 2018 4:08 pm    Post subject: Reply with quote

transsib,

Ask genlop if you want a wall time comparison.
Its not very scientific as its elapsed time for a build, which varies with whatever else is going on at the time.
_________________
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
PrSo
Tux's lil' helper
Tux's lil' helper


Joined: 01 Jun 2017
Posts: 95

PostPosted: Fri Jan 12, 2018 4:16 pm    Post subject: Reply with quote

I will wait with microcode update. They F***** smth up :
https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/

EDIT:

Affected chips Broadwell and Haswell. That must be the reason of delay for some CPUs.


Last edited by PrSo on Fri Jan 12, 2018 5:10 pm; edited 3 times in total
Back to top
View user's profile Send private message
transsib
l33t
l33t


Joined: 26 Jul 2003
Posts: 795

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

NeddySeagoon, will try genlop next time I start this experiment.
Will have to interrupt it soon because I don't wanna have it run all night long.
I know I can trust my feeling though; before the patch more than twice as many packages
have been done within the same time.

Also I'm not certain if I have the current microcode for my Haswell Xeon(R) CPU E3-1240 v3:
Code:
# dmesg | grep micro
[    0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27
[    0.498616] microcode: sig=0x306c3, pf=0x2, revision=0x22
[    0.499391] microcode: Microcode Update Driver: v2.2.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Fri Jan 12, 2018 4:31 pm    Post subject: Reply with quote

transsib,

You can use
Code:
genlop -t
any time. It parses elapsed times from /var/log/emerge.log
Your entire emerge history should be there.

-- edit --

date = 2017-01-27 may be the current microcode but its too old for the latest round of security fixes.
_________________
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
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 6636

PostPosted: Fri Jan 12, 2018 4:37 pm    Post subject: Reply with quote

transsib wrote:
Also I'm not certain if I have the current microcode for my Haswell Xeon(R) CPU E3-1240 v3:
Code:
# dmesg | grep micro
[    0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27
[    0.498616] microcode: sig=0x306c3, pf=0x2, revision=0x22
[    0.499391] microcode: Microcode Update Driver: v2.2.

->
Code:
[    0.444478] microcode: sig=0x306c3, pf=0x2, revision=0x23
Back to top
View user's profile Send private message
transsib
l33t
l33t


Joined: 26 Jul 2003
Posts: 795

PostPosted: Fri Jan 12, 2018 5:20 pm    Post subject: Reply with quote

NeddySeagoon, which package has genlop; my system doesn't know the command.

Krinn, current microcode doesn't load. Looks like I need to do
Code:
iucode_tool -S --write-earlyfw=/boot/early_ucode.cpio /lib/firmware/intel-ucode/*

again ( updated to sys-firmware/intel-microcode-20180108) unless it gives "cannot write - file exists" ?

It's almost tragic because no effort completely safeguards our systems.
And if you think spending money for a new system would do the trick don't get your hopes up
because *spoilers* no existing CPU is safe.
May be we are all part of the problem because we all wanted fast systems. We got fast systems
at cost of security.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

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

Code:

 eix genlop
[I] app-portage/genlop
     Available versions:  0.30.9-r1 (~)0.30.10 (~)0.30.10-r1 **9999
     Installed versions:  0.30.10-r1(12:56:09 14/05/17)
     Homepage:            https://wiki.gentoo.org/wiki/Project:Perl
     Description:         A nice emerge.log parser

_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
Spargeltarzan
Apprentice
Apprentice


Joined: 23 Jul 2017
Posts: 214

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

Does gcc-r1 have something todo with spectre?
_________________
___________________
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
keet
Guru
Guru


Joined: 09 Sep 2008
Posts: 527

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

mike155 wrote:
Does anyone have a clue, why the difference between pti and nopti is so much larger in a VM? Does this happen only with QEMU? Or does it happen also with VMWare? Do we have to live with that? Or is it something that can be fixed in the kernel or in QEMU?


Might this be related?

"As the fixes for CVE-2017-5715 will also need adjustments in the QEMU virtualization host to pass through CPUID flags and MSRs from host to guest system, Gentoo will also be providing an updated app-emulation/qemu package once available. You can subscribe to bug #643432 to get notified or wait for the GLSA release. Note that the XEN Hypervisor also needs mitigations for the described problems, the XEN team is currently developing a fix. You can subscribe to bug #643350 to get notified or wait for the GLSA release."
Back to top
View user's profile Send private message
transsib
l33t
l33t


Joined: 26 Jul 2003
Posts: 795

PostPosted: Fri Jan 12, 2018 7:23 pm    Post subject: Reply with quote

Spargeltarzan, there's no fix against Spectre.
Also each and every patch applied by us now will only mitigate any
possible unknown danger.
Back to top
View user's profile Send private message
Spargeltarzan
Apprentice
Apprentice


Joined: 23 Jul 2017
Posts: 214

PostPosted: Fri Jan 12, 2018 7:50 pm    Post subject: Reply with quote

I understand...

So the mitigations in CentOS/RHEL and iOS are protective mechanisms how Spectre could be used, but different malware, trying a new approach, could succeed? Too bad that we even can't quit Intel and by AMD instead. And I even dont want to think on my android phone, which will even not get Android 8 any more and Android Security Updates are also only September 2017.

We try too secure our Gentoo Boxes as much as we can and than we suffer from a java script Google Chrome exploit on Android on the phone which contains more sensitive data than my Gentoo Box. It sucks.
_________________
___________________
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
transsib
l33t
l33t


Joined: 26 Jul 2003
Posts: 795

PostPosted: Fri Jan 12, 2018 8:01 pm    Post subject: Reply with quote

The patch only addresses and mitigates Meltdown.
Back to top
View user's profile Send private message
Spargeltarzan
Apprentice
Apprentice


Joined: 23 Jul 2017
Posts: 214

PostPosted: Fri Jan 12, 2018 8:09 pm    Post subject: Reply with quote

On the blog of iOS they write " To help defend against Spectre, Apple has released mitigations in iOS 11.2.2, the macOS High Sierra 10.13.2 Supplemental Update, and Safari 11.0.2 for macOS Sierra and OS X El Capitan." Blog and the same for RHEL: here they have "fixes" for all 3 types of vulnerabilities
_________________
___________________
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
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3 ... 11, 12, 13 ... 21, 22, 23  Next
Page 12 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