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 ... 7, 8, 9 ... 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
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7170

PostPosted: Sat Jan 06, 2018 10:27 pm    Post subject: Reply with quote

josephg wrote:
linus separates amd64 from x86 in his kernel architectures: http://github.com/torvalds/linux/tree/master/arch

LOL good example because he did not, you must have mistake with arm64 or ia64 (which is use by itanium).
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 783
Location: usually offline

PostPosted: Sat Jan 06, 2018 10:31 pm    Post subject: Reply with quote

:) good catch.. i misread that, now updated.
Back to top
View user's profile Send private message
Wallsandfences
Guru
Guru


Joined: 29 Mar 2010
Posts: 368

PostPosted: Sat Jan 06, 2018 10:36 pm    Post subject: Reply with quote

Sure, you're right, sorry.

Arrgh... 'make' it is, just spotted it...

Code:
./meltdown-checker
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 0xffffffff81a00160 ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...

System not affected (take it with a grain of salt though as false negative may be reported for specific environments; Please consider running it once again).


But spectre is another matter... on AMD Athlon(tm) II X4 630 Processor

R.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Sat Jan 06, 2018 10:46 pm    Post subject: Reply with quote

32bit is affected
_________________
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
Guru
Guru


Joined: 23 Jul 2017
Posts: 300

PostPosted: Sat Jan 06, 2018 10:46 pm    Post subject: Reply with quote

I upgraded to the newest intel-microcode stabilized today "20171117_p20171215" and did "iucode_tool -S -l /lib64/firmware/intel-ucode/*"

Unfortunately still the old microcodes from 2017-04-09 become loaded.
Code:
microcode: microcode updated early to revision 0xba, date = 2017-04-09


All files in /lib64/firmware/intel-ucode/* are created on 6. Jan. Same issue when I copy the microcode.cpio from /lib64/firmware/microcode.cpio to /boot.

I have added the microcodes in grub.cfg as initrd.

What am I doing wrong?
_________________
___________________
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
gengreen
Tux's lil' helper
Tux's lil' helper


Joined: 23 Dec 2017
Posts: 84

PostPosted: Sat Jan 06, 2018 10:55 pm    Post subject: Reply with quote

Spargeltarzan wrote:
I upgraded to the newest intel-microcode stabilized today "20171117_p20171215" and did "iucode_tool -S -l /lib64/firmware/intel-ucode/*"

Unfortunately still the old microcodes from 2017-04-09 become loaded.
Code:
microcode: microcode updated early to revision 0xba, date = 2017-04-09


All files in /lib64/firmware/intel-ucode/* are created on 6. Jan. Same issue when I copy the microcode.cpio from /lib64/firmware/microcode.cpio to /boot.

I have added the microcodes in grub.cfg as initrd.

What am I doing wrong?


Same issue....
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Sat Jan 06, 2018 10:55 pm    Post subject: Reply with quote

have you tried baking the firmware upgrade into the kernel rather than using an initrc?
I am about to build a new kernel with the ryzen img
_________________
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
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18085

PostPosted: Sat Jan 06, 2018 11:55 pm    Post subject: Re: "gentoo-sources" package: versions fixed again Reply with quote

Pearlseattle wrote:
Hi

Which versions of "gentoo-sources" have gotten the patches against the "Meltdown"-attack?


mahdi1234 wrote:
Hi,

I'm not sure but why is sys-kernel/gentoo-sources-4.14.12 having PAGE_TABLE_ISOLATION being dependent on X86_64?


Merged both Pearlseattle's and mahdi1234's threads.
_________________
Those who know what's best for us must rise and save us from ourselves.
Back to top
View user's profile Send private message
Vrenn
Apprentice
Apprentice


Joined: 15 Dec 2004
Posts: 290

PostPosted: Sun Jan 07, 2018 12:57 am    Post subject: Reply with quote

I'm late on this threat to so please apologise. I know gentoo devs are now doing good (and probably heavy) work, I just want to tell my experience.
Spargeltarzan wrote:
I upgraded to the newest intel-microcode stabilized today "20171117_p20171215" and did "iucode_tool -S -l /lib64/firmware/intel-ucode/*"

Unfortunately still the old microcodes from 2017-04-09 become loaded.
Same here:
Code:
eshowkw linux-firmware: [I]20180103-r1 amd64

iucode_tool -S -l /lib/firmware/intel-ucode/*
...
microcode bundle 49: /lib/firmware/intel-ucode/06-3c-03
...
selected microcodes:
  049/001: sig 0x000306c3, pf_mask 0x32, 2017-01-27, rev 0x0022, size 22528
Same old revision 0x22 is loaded. (naked BIOS-microcode-revision would be 0x1c, doublechecked)
Code:
/usr/src/linux # dmesg | grep micro
[    1.355964] microcode: sig=0x306c3, pf=0x20, revision=0x22
[    1.356723] microcode: Microcode Update Driver: v2.2.

I have baking in the firmware ("intel-ucode/06-3c-03"-External firmware blobs to build into the kernel binary, "/lib/firmware"-Firmware blobs root directory, Haswell Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz)
Seems to be the same as on the beginning of the last year. The Gentoo-meltdown-wiki tells me it should be revision 3b?
of course I have compiled/installed the kernel new.
Either the wiki is wrong UNDERSTOOD by me with Revision 3b (they might mean with Haswell-X the Xenon-consumer-version of Haswell),
or there are different Haswell, not all getting new revision,
or intel/gentoo just not released the new revision for my cpu,
or I did something horrible wrong...
What might be true?

Edit: wiki is not wrong with Revision 3b I think, I just misread it.
_________________
With nice greetings
Vrenn
Back to top
View user's profile Send private message
Zazzman
n00b
n00b


Joined: 09 May 2012
Posts: 32

PostPosted: Sun Jan 07, 2018 2:42 am    Post subject: Reply with quote

kajzer wrote:
Smells like a ploy to buy new hardware which will then have serious backdoors and kill switches.
Of course. Or we could continue on hardware that discernibly has them now. Intel motherboards especially. https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668
Joseph Powers wrote:
Can I patch the Meltdown bug with Gentoo hardened sources?
Nice thought, but no.
kajzer wrote:
eccerr0r wrote:
Anyone have the PoC code, and whether disabling L1/L2 caches would mitigate the problem?
PoC code :
http://cxsecurity.com/issue/WLB-2018010039
Yes, this deserves being quoted so no one can bury their heads in the sand.
Atom2 wrote:
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
And here I was ready to dive into another Xen install. At least, before the ZFS update to 0.7.5 cooked my goose.

The Global Github hub for this mess: https://github.com/hannob/meltdownspectre-patches

As for mitigation:

Perfectly "fixing" these hardware glitches in software is impossible. But making them harder to exploit? Yeah, we can do that. At least, that's what GCC seems to think:
Spectre Variant 1: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00205.html
Spectre Variant 2: https://sourceware.org/ml/binutils/2018-01/msg00030.html

Or there's this variant of GCC: http://git.infradead.org/users/dwmw2/gcc-retpoline.git

And llvm: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513630.html
https://lkml.org/lkml/2018/1/3/780
https://lkml.org/lkml/2018/1/4/615 (404s for me - maybe a better update is out there?)

Microcode updates are still pending, to my knowledge. Any chance a BDver2 or AMD fam15h firmware came out yet?

In the 'kernel hacking' section under 'memory hacking' there's an option to poison freed memory pages... I'm just sayin' this feels relevant for folks to double check.

I'm willing to throw an old 8core Piledriver at these gcc patches. It already runs gcc-7.2.0 globally under the 17.1 profile, and that unsupported "custom optimizations", "custom cflags", and "-jit" use flags are all enabled in my make.conf. This system is plenty stable under this setup. Or at least it was until the zfs-0.7.5 update hit with a bad handroll of my initramfs (plain dmcrypt on a zraid seemed to make this necessary). Time to start over, since the only place those keys now exist is inside the crypt, on a zraid! 0,__0, Screw it, I'm on my flash drive rescue install!

Even with KPTI, since "why the f*^k not? You expect these to be the only other problems out there that such fixes?" Para-nothing. Full-noid or bust. But the 'nopti' flag in grub's linux line turns off kpti like on any other distro.

I'm not quite sure how to add these patches to ebuilds for gcc and binutils. Otherwise I'd already be running them.

I'd love for *a* system to be covered by a 'emerge -NauvD --with-bdeps=y --complete-graph --emptytree @world' even if it isn't mine.

We *are* running the meta-distro. We *ARE* the guys, gals, etc that can take a pile o' parts and patches, and make freaking FIPS compliance look like a Joke! Are we gonna sit here, lamenting the false security we lost, or shall we patch boldly forward?

I'd be posting ebuilds if the toolchain's ebuilds would make that accessible. And if I knew how to clone sources through git in an ebuild (Somehow, that's not on any wiki entry I found). And so on and so forth. Come on team! Maybe this can be a teaching moment for some of us? I'm here to learn and patch. And I can't exactly patch any more without learning.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


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

PostPosted: Sun Jan 07, 2018 7:50 am    Post subject: Reply with quote

I just built 4.14.11-r2 for my general purpose workstation, which is an x86_64.
However I noted, since
Code:
        config PAGE_TABLE_ISOLATION
        bool "Remove the kernel mapping in user mode"
        default y
        depends on X86_64 && !UML
        default y

Can we expect our 32-bit machines to be unsafe...for how long? Or is this snippet a bit more confusing than it seems, since it has "default y" twice...
_________________
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
unheatedgarage
n00b
n00b


Joined: 19 Sep 2016
Posts: 51

PostPosted: Sun Jan 07, 2018 11:20 am    Post subject: Reply with quote

I just want to give a hearty, heartfelt shout-out to our Gentoo developers. Thank you for all your hard work!
_________________
I'm not even mad; I'm impressed!
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3401

PostPosted: Sun Jan 07, 2018 11:25 am    Post subject: Reply with quote

eccerr0r wrote:
I just built 4.14.11-r2 for my general purpose workstation, which is an x86_64.
However I noted, since
Code:
        config PAGE_TABLE_ISOLATION
        bool "Remove the kernel mapping in user mode"
        default y
        depends on X86_64 && !UML
        default y

Can we expect our 32-bit machines to be unsafe...for how long? Or is this snippet a bit more confusing than it seems, since it has "default y" twice...


I believe using PAE may make 32-bit machines safe, it does effectively the same thing for them - at a performance cost.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
PrSo
Tux's lil' helper
Tux's lil' helper


Joined: 01 Jun 2017
Posts: 129

PostPosted: Sun Jan 07, 2018 12:08 pm    Post subject: Reply with quote

NVIDIA is also affected:
http://nvidia.custhelp.com/app/answers/detail/a_id/4611
Back to top
View user's profile Send private message
tholin
Apprentice
Apprentice


Joined: 04 Oct 2008
Posts: 178

PostPosted: Sun Jan 07, 2018 1:46 pm    Post subject: Reply with quote

Spargeltarzan wrote:
I upgraded to the newest intel-microcode stabilized today "20171117_p20171215" and did "iucode_tool -S -l /lib64/firmware/intel-ucode/*"

Unfortunately still the old microcodes from 2017-04-09 become loaded.

My cpu i7-4790K (sig=0x306c3) didn't have any update in the 20171117_p20171215 update. The latest update was from the beginning of the year. Debian is shipping a .deb with newer microcode.
I downloaded it from http://ftp.us.debian.org/debian/pool/non-free/i/intel-microcode/intel-microcode_3.20171215.1_amd64.deb
That deb had a microcode update from 2017-11-20. I'm not sure if that is the right one for fixing "Variant 2: Branch target injection".
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6294

PostPosted: Sun Jan 07, 2018 4:26 pm    Post subject: Reply with quote

depontius wrote:
eccerr0r wrote:
I just built 4.14.11-r2 for my general purpose workstation, which is an x86_64.
However I noted, since
Code:
        config PAGE_TABLE_ISOLATION
        bool "Remove the kernel mapping in user mode"
        default y
        depends on X86_64 && !UML
        default y

Can we expect our 32-bit machines to be unsafe...for how long? Or is this snippet a bit more confusing than it seems, since it has "default y" twice...


I believe using PAE may make 32-bit machines safe, it does effectively the same thing for them - at a performance cost.

The point is that PAGE_TABLE_ISOLATION cannot be actived in 32 bit kernels, because the dependency X86_64 is not satisfied: The .config in 32 bit kernels does not even have that option.
So either the code is written such that it cannot run on 32 bit systems or it is not necessary (or the above dependency is a bug which I consider unlikely).
Unfortunately, the earlier mentioned meltdown test for does not compile for 32 bit x86 systems. (BTW, the spectre test does not compile, either).

Edit: :oops: In the above text I had misunderstood that PAE should just mean a shortcut for PAGE_TABLE_ISOLATION. Only now I understand that it means another feature of 32 bit kernels.


Last edited by mv on Sun Jan 07, 2018 8:02 pm; edited 1 time in total
Back to top
View user's profile Send private message
albright
Advocate
Advocate


Joined: 16 Nov 2003
Posts: 2549
Location: Near Toronto

PostPosted: Sun Jan 07, 2018 6:19 pm    Post subject: Reply with quote

Quote:
I have added the microcodes in grub.cfg as initrd.


dumb question, but have you reloaded grub?
_________________
.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme)
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


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

PostPosted: Sun Jan 07, 2018 6:48 pm    Post subject: Reply with quote

depontius wrote:
I believe using PAE may make 32-bit machines safe, it does effectively the same thing for them - at a performance cost.

That's what I speculated (ha) initially, but indeed this is still unconfirmed. This still does not help one of my still somewhat used 32-bit laptop which corrupts memory when PAE is forced on (otherwise it claims PAE not available.)
_________________
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
tholin
Apprentice
Apprentice


Joined: 04 Oct 2008
Posts: 178

PostPosted: Sun Jan 07, 2018 8:58 pm    Post subject: Reply with quote

Here is an important post by Andrew Lutomirski I stumbled upon on hacker news:
https://news.ycombinator.com/item?id=16087736

I'll quote the entire thing:
Quote:
One thing I'll reiterate: as Greg mentioned, the backports to kernels prior to 4.14 are derived from a rather old KAISER version. They do not match what 4.14 and 4.15 do. This has several consequences.

1. They will have bugs. There's a reason PTI was heavily modified from the old KAISER code. They will also tend to diverge from upstream just because the code is so different. This means that the next time low-level x86 changes need to be backported, it'll be a huge mess.

2. There is only minimal upstream support. I, for example, am already largely ignoring two bugs in the backports that aren't in the upstream version. Why? Because I have no affiliation with a distro using an old kernel.

3. Contrary to its marketing, KAISER does not effectively mitigate the old kASLR leaks. PTI very nearly does, and I intend to improve it further once I find some time to do so. I doubt those improvements will get backported to pre-4.14 kernels.

4. At least some versions of "KAISER", on meltdown-affected hardware, expose the kernel stack to userspace. If that's not usable for rooting a box, I'll eat my hat. KPTI doesn't have this problem.

If you can put pressure on your organization or suppliers to update to 4.14 or better, please do so. Red Hat, especially, should seriously consider moving to 4.14 for RHEL 8.

The takeaway seems to be that kernel developers are ignoring bugs, including security bugs in the backports.
Back to top
View user's profile Send private message
mike155
Veteran
Veteran


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

PostPosted: Sun Jan 07, 2018 11:10 pm    Post subject: Reply with quote

@thonlin: thanks for your post!

I wanted to run kernel 4.9 on my productive servers a little longer - but after reading Andy's post, I started to migrate all servers to 4.14...
Back to top
View user's profile Send private message
transpetaflops
Tux's lil' helper
Tux's lil' helper


Joined: 16 May 2005
Posts: 139

PostPosted: Sun Jan 07, 2018 11:27 pm    Post subject: Reply with quote

Doesn't this contradict the information given here?
https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre#sys-kernel.2Fgentoo-sources
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


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

PostPosted: Mon Jan 08, 2018 12:38 am    Post subject: Reply with quote

I recall a posting somewhere that running PTI on a VM really kills VM performance... has anyone seen such? This sounds very concerning... Might have to look into containers and stop running a VM.
_________________
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
Pearlseattle
Apprentice
Apprentice


Joined: 04 Oct 2007
Posts: 162
Location: Switzerland

PostPosted: Mon Jan 08, 2018 12:49 am    Post subject: Reply with quote

tholin wrote:
Spargeltarzan wrote:
I upgraded to the newest intel-microcode stabilized today "20171117_p20171215" and did "iucode_tool -S -l /lib64/firmware/intel-ucode/*"

Unfortunately still the old microcodes from 2017-04-09 become loaded.

My cpu i7-4790K (sig=0x306c3) didn't have any update in the 20171117_p20171215 update. The latest update was from the beginning of the year. Debian is shipping a .deb with newer microcode.
I downloaded it from http://ftp.us.debian.org/debian/pool/non-free/i/intel-microcode/intel-microcode_3.20171215.1_amd64.deb
That deb had a microcode update from 2017-11-20. I'm not sure if that is the right one for fixing "Variant 2: Branch target injection".


New version "20171117_p20171215-r1" of "sys-firmware/intel-microcode" has been released (contains updates as well for at least some non-X Intel processors => confirming that my i5-6200U loaded the update).
(https://bugs.gentoo.org/643794)
Back to top
View user's profile Send private message
Thistled
Guru
Guru


Joined: 06 Jan 2011
Posts: 548
Location: Scotland

PostPosted: Mon Jan 08, 2018 1:10 am    Post subject: Reply with quote

Count yourself lucky.
I am stuck with a microcode update from 2010. :evil:

I get the impression Intel won't be providing Wolfdales E5400 with any updates because they say they no longer support the chip.
What annoys me is the chip is fine, and my system runs great. There's nothing wrong with the chip for everyday use.
But, like the rest of the industry, you should be purchasing the latest "must have" every 6 months. Sucks.
_________________
Whatever you do, do it properly!
Back to top
View user's profile Send private message
kajzer
Guru
Guru


Joined: 27 Nov 2014
Posts: 469

PostPosted: Mon Jan 08, 2018 2:20 am    Post subject: Reply with quote

Indeed, same here with the microcode from 2010, and I'm pretty happy with my old CPU, they will have to actually kill it before I buy new one :)

One thing puzzles me though, when I load microcode with initramfs I get this :
Code:
$ dmesg | grep microcode                     
[    0.000000] microcode: microcode updated early to revision 0xa4, date = 2010-10-02
[    0.794279] microcode: sig=0x6fd, pf=0x1, revision=0xa4
[    0.794339] microcode: Microcode Update Driver: v2.2.


When I include it in the kernel I get this :
Code:
dmesg | grep microcode                                                                                                                                                                                               
[    0.294653] microcode: sig=0x6fd, pf=0x1, revision=0xa1
[    0.294718] microcode: Microcode Update Driver: v2.2.


Different revisions, depending on the method, I'm not able to figure this one out.

Code:
# iucode_tool -S -l /lib/firmware/intel-ucode/*                                                                                                                                                                 
iucode_tool: system has processor(s) with signature 0x000006fd
microcode bundle 1: /lib/firmware/intel-ucode/06-03-02
microcode bundle 2: /lib/firmware/intel-ucode/06-05-00
microcode bundle 3: /lib/firmware/intel-ucode/06-05-01
microcode bundle 4: /lib/firmware/intel-ucode/06-05-02
microcode bundle 5: /lib/firmware/intel-ucode/06-05-03
microcode bundle 6: /lib/firmware/intel-ucode/06-06-00
microcode bundle 7: /lib/firmware/intel-ucode/06-06-05
microcode bundle 8: /lib/firmware/intel-ucode/06-06-0a
microcode bundle 9: /lib/firmware/intel-ucode/06-06-0d
microcode bundle 10: /lib/firmware/intel-ucode/06-07-01
microcode bundle 11: /lib/firmware/intel-ucode/06-07-02
microcode bundle 12: /lib/firmware/intel-ucode/06-07-03
microcode bundle 13: /lib/firmware/intel-ucode/06-08-01
microcode bundle 14: /lib/firmware/intel-ucode/06-08-03
microcode bundle 15: /lib/firmware/intel-ucode/06-08-06
microcode bundle 16: /lib/firmware/intel-ucode/06-08-0a
microcode bundle 17: /lib/firmware/intel-ucode/06-09-05
microcode bundle 18: /lib/firmware/intel-ucode/06-0a-00
microcode bundle 19: /lib/firmware/intel-ucode/06-0a-01
microcode bundle 20: /lib/firmware/intel-ucode/06-0b-01
microcode bundle 21: /lib/firmware/intel-ucode/06-0b-04
microcode bundle 22: /lib/firmware/intel-ucode/06-0d-06
microcode bundle 23: /lib/firmware/intel-ucode/06-0e-08
microcode bundle 24: /lib/firmware/intel-ucode/06-0e-0c
microcode bundle 25: /lib/firmware/intel-ucode/06-0f-02
microcode bundle 26: /lib/firmware/intel-ucode/06-0f-06
microcode bundle 27: /lib/firmware/intel-ucode/06-0f-07
microcode bundle 28: /lib/firmware/intel-ucode/06-0f-0a
microcode bundle 29: /lib/firmware/intel-ucode/06-0f-0b
microcode bundle 30: /lib/firmware/intel-ucode/06-0f-0d
microcode bundle 31: /lib/firmware/intel-ucode/06-16-01
microcode bundle 32: /lib/firmware/intel-ucode/06-17-06
microcode bundle 33: /lib/firmware/intel-ucode/06-17-07
microcode bundle 34: /lib/firmware/intel-ucode/06-17-0a
microcode bundle 35: /lib/firmware/intel-ucode/06-1a-04
microcode bundle 36: /lib/firmware/intel-ucode/06-1a-05
microcode bundle 37: /lib/firmware/intel-ucode/06-1c-02
microcode bundle 38: /lib/firmware/intel-ucode/06-1c-0a
microcode bundle 39: /lib/firmware/intel-ucode/06-1d-01
microcode bundle 40: /lib/firmware/intel-ucode/06-1e-05
microcode bundle 41: /lib/firmware/intel-ucode/06-25-02
microcode bundle 42: /lib/firmware/intel-ucode/06-25-05
microcode bundle 43: /lib/firmware/intel-ucode/06-26-01
microcode bundle 44: /lib/firmware/intel-ucode/06-2a-07
microcode bundle 45: /lib/firmware/intel-ucode/06-2d-06
microcode bundle 46: /lib/firmware/intel-ucode/06-2d-07
microcode bundle 47: /lib/firmware/intel-ucode/06-2f-02
microcode bundle 48: /lib/firmware/intel-ucode/06-3a-09
microcode bundle 49: /lib/firmware/intel-ucode/06-3c-03
microcode bundle 50: /lib/firmware/intel-ucode/06-3d-04
microcode bundle 51: /lib/firmware/intel-ucode/06-3e-04
microcode bundle 52: /lib/firmware/intel-ucode/06-3e-06
microcode bundle 53: /lib/firmware/intel-ucode/06-3e-07
microcode bundle 54: /lib/firmware/intel-ucode/06-3f-02
microcode bundle 55: /lib/firmware/intel-ucode/06-3f-04
microcode bundle 56: /lib/firmware/intel-ucode/06-45-01
microcode bundle 57: /lib/firmware/intel-ucode/06-46-01
microcode bundle 58: /lib/firmware/intel-ucode/06-47-01
microcode bundle 59: /lib/firmware/intel-ucode/06-4e-03
microcode bundle 60: /lib/firmware/intel-ucode/06-4f-01
microcode bundle 61: /lib/firmware/intel-ucode/06-55-04
microcode bundle 62: /lib/firmware/intel-ucode/06-56-02
microcode bundle 63: /lib/firmware/intel-ucode/06-56-03
microcode bundle 64: /lib/firmware/intel-ucode/06-56-04
microcode bundle 65: /lib/firmware/intel-ucode/06-5c-09
microcode bundle 66: /lib/firmware/intel-ucode/06-5e-03
microcode bundle 67: /lib/firmware/intel-ucode/06-7a-01
microcode bundle 68: /lib/firmware/intel-ucode/06-8e-09
microcode bundle 69: /lib/firmware/intel-ucode/06-8e-0a
microcode bundle 70: /lib/firmware/intel-ucode/06-9e-09
microcode bundle 71: /lib/firmware/intel-ucode/06-9e-0a
microcode bundle 72: /lib/firmware/intel-ucode/06-9e-0b
microcode bundle 73: /lib/firmware/intel-ucode/0f-00-07
microcode bundle 74: /lib/firmware/intel-ucode/0f-00-0a
microcode bundle 75: /lib/firmware/intel-ucode/0f-01-02
microcode bundle 76: /lib/firmware/intel-ucode/0f-02-04
microcode bundle 77: /lib/firmware/intel-ucode/0f-02-05
microcode bundle 78: /lib/firmware/intel-ucode/0f-02-06
microcode bundle 79: /lib/firmware/intel-ucode/0f-02-07
microcode bundle 80: /lib/firmware/intel-ucode/0f-02-09
microcode bundle 81: /lib/firmware/intel-ucode/0f-03-02
microcode bundle 82: /lib/firmware/intel-ucode/0f-03-03
microcode bundle 83: /lib/firmware/intel-ucode/0f-03-04
microcode bundle 84: /lib/firmware/intel-ucode/0f-04-01
microcode bundle 85: /lib/firmware/intel-ucode/0f-04-03
microcode bundle 86: /lib/firmware/intel-ucode/0f-04-04
microcode bundle 87: /lib/firmware/intel-ucode/0f-04-07
microcode bundle 88: /lib/firmware/intel-ucode/0f-04-08
microcode bundle 89: /lib/firmware/intel-ucode/0f-04-09
microcode bundle 90: /lib/firmware/intel-ucode/0f-04-0a
microcode bundle 91: /lib/firmware/intel-ucode/0f-06-02
microcode bundle 92: /lib/firmware/intel-ucode/0f-06-04
microcode bundle 93: /lib/firmware/intel-ucode/0f-06-05
microcode bundle 94: /lib/firmware/intel-ucode/0f-06-08
selected microcodes:
  025/002: sig 0x000006f2, pf_mask 0x20, 2010-10-02, rev 0x005c, size 4096
  025/001: sig 0x000006f2, pf_mask 0x01, 2010-10-02, rev 0x005d, size 4096
  026/003: sig 0x000006f6, pf_mask 0x20, 2010-10-01, rev 0x00d1, size 4096
  026/002: sig 0x000006f6, pf_mask 0x04, 2010-10-01, rev 0x00d2, size 4096
  026/001: sig 0x000006f6, pf_mask 0x01, 2010-09-30, rev 0x00d0, size 4096
  027/002: sig 0x000006f7, pf_mask 0x40, 2010-10-02, rev 0x006b, size 4096
  027/001: sig 0x000006f7, pf_mask 0x10, 2010-10-02, rev 0x006a, size 4096
  028/001: sig 0x000006fa, pf_mask 0x80, 2010-10-02, rev 0x0095, size 4096
  029/007: sig 0x000006fb, pf_mask 0x80, 2010-10-03, rev 0x00ba, size 4096
  029/006: sig 0x000006fb, pf_mask 0x40, 2010-10-03, rev 0x00bc, size 4096
  029/005: sig 0x000006fb, pf_mask 0x20, 2010-10-03, rev 0x00ba, size 4096
  029/004: sig 0x000006fb, pf_mask 0x10, 2010-10-03, rev 0x00ba, size 4096
  029/003: sig 0x000006fb, pf_mask 0x08, 2010-10-03, rev 0x00bb, size 4096
  029/002: sig 0x000006fb, pf_mask 0x04, 2010-10-03, rev 0x00bc, size 4096
  029/001: sig 0x000006fb, pf_mask 0x01, 2010-10-03, rev 0x00ba, size 4096
  030/003: sig 0x000006fd, pf_mask 0x80, 2010-10-02, rev 0x00a4, size 4096
  030/002: sig 0x000006fd, pf_mask 0x20, 2010-10-02, rev 0x00a4, size 4096
  030/001: sig 0x000006fd, pf_mask 0x01, 2010-10-02, rev 0x00a4, size 4096


I've picked bundle 30 to include in the kernel, there's no revision 0xa1, anyone knows why this happens ?
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 ... 7, 8, 9 ... 21, 22, 23  Next
Page 8 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