Re: [gentoo-user] Microcode updates for "old" Intel CPU's
I have a less-two-old N3700 CPU on a Asrock N3700-ITX board that (was)is perfect for my NAS, but without pcid instruction that mitigates the last pti patches slowdown. Asrock said nothing about the microcode/bios update and I asked for warranty return because I consider a factory defect but I think that I will fight with the seller. BTW, the European Community Law requires at least 2 years of warranty coverage on factory defects... Proud to be European. ciao luigi On Mon, Jan 8, 2018 at 1:00 AM, Peter Humphrey wrote: > On Sunday, 7 January 2018 20:46:52 GMT taii...@gmx.com wrote: > > I have several sandy/ivybridge CPU's and I was wondering if anyone knows > > as to if intel is releasing microcode updates for them. > > > > It sure would be funny if intel wanted you to buy a new CPU to fix a > > problem that was their fault to begin with. > > Welcome to unbridled capitalism, USA-style. > > -- > Regards, > Peter. > > > -- Luigi 'Comio' Mantellini R&D - Software Industrie Dial Face S.p.A. Via Canzo, 4 20068 Peschiera Borromeo (MI), Italy Tel.: +39 02 5167 2813 Fax: +39 02 5167 2459 web: www.idf-hit.com mail: luigi.mantell...@idf-hit.com
Re: [gentoo-user] microcode applied?
On Tue, 09 Jan 2018 00:15:03 +, Peter Humphrey wrote: > > > How do you build the microcode into the kernel? The only > > > place I can see to do that in menuconfig is under Device Drivers; > > > there's no such field under Firmware. > > > > The Device Drivers section is exactly where the microcode is included. > > CONFIG_EXTRA_FIRMWARE is the relevant symbol. > > Right. So which of the 95 files under /lib/firmware/intel-ucode do I > specify? That's in addition to the 14 files I have for my amdgpu. I found the simplest way to do it was to emerge intel-microcode with the initramfs uSE flag. Then copy /lib/firmware/microcode.cpio to /boot and add it as an initrd - before the existing one if you already use one. That way it is still loaded at the same time but you don't need to recompile your kernels (most of us probably have more than one in /boot) each time there is a microcode update. The USE flag takes care of selecting the correct file for your CPU. -- Neil Bothwick Top Oxymorons Number 20: Synthetic natural gas pgpNQjdJJjvIs.pgp Description: OpenPGP digital signature
Re: [gentoo-user] How do I customize x11-terms/xterm?
On Mon, 8 Jan 2018 22:57:30 -0700, Grant Taylor wrote: > I have been playing with a customized version of Xterm outside of > portage and I'd like to migrate my customizations to the copy of Xterm > that is emerged as part of the system. > > So far my customizations consist of a modified ./configure command to > enable options that I want. You can usually add extra configure items by creating, in your case /etc/portage/env/x11-terms/xterm containing > How do I replicate that via portage? EXTRA_ECONF="--enable-blah..." > What would I need to do if I wanted to patch a source file? Putting the patch in /etc/portage/patches/x11-xterms/xterm should do it. Both of these features are on by default in EAPI6, the xterm ebuild uses EAPI5 so try it and see. -- Neil Bothwick Everyone has a photographic memory. Some don't have film. pgplREVOsSdD0.pgp Description: OpenPGP digital signature
Re: [gentoo-user] microcode applied?
>
> > The Device Drivers section is exactly where the microcode is included.
> > CONFIG_EXTRA_FIRMWARE is the relevant symbol.
>
> Right. So which of the 95 files under /lib/firmware/intel-ucode do I
> specify? That's in addition to the 14 files I have for my amdgpu.
>
>
For intel;
iucode_tool -L /lib/firmware/intel-ucode/* | grep -B 1 `iucode_tool -S 2>&1
| awk '{print $7}'`
As Mick posted, iucode_tool -S will let you know what the CPU signature is,
and running iucode_tool -L against the microcode files dumps out which CPU
sig each file is for, so the above command just searches the files for the
right signature.
Hopefully there's an equivalent for AMD.
Re: [gentoo-user] microcode applied?
On Tue, Jan 9, 2018 at 12:15 AM, Peter Humphrey wrote: > On Monday, 8 January 2018 10:29:41 GMT Max Zettlmeißl wrote: >> > How do you build the microcode into the kernel? The only >> > place I can see to do that in menuconfig is under Device Drivers; >> > there's no such field under Firmware. >> >> The Device Drivers section is exactly where the microcode is included. >> CONFIG_EXTRA_FIRMWARE is the relevant symbol. > > Right. So which of the 95 files under /lib/firmware/intel-ucode do I > specify? That's in addition to the 14 files I have for my amdgpu. > In my system (intel): $ iucode_tool -S iucode_tool: system has processor(s) with signature 0x000906e9 $ iucode_tool -L /lib/firmware/intel-ucode | grep 0x000906e9 -B 1 microcode bundle 18: /lib/firmware/intel-ucode/06-9e-09 018/001: sig 0x000906e9, pf_mask 0x2a, 2017-04-06, rev 0x005e, size 97280 018/002: sig 0x000906e9, pf_mask 0x2a, 2017-04-06, rev 0x005e, size 97280 So in this example "intel-ucode/06-9e-09" is what you'll write in the kernel form. There is a amd-ucode dir in /lib/firmware, so I assume it will be the same. Jorge Almeida
Re: [gentoo-user] microcode applied?
On 08/01/18 13:52, Rich Freeman wrote: > There is also a lot of discussion on lkml about the right fix. We > might very well end up seeing both AMD- and Intel-specific fixes with > conditional logic. The two vendors don't really seem to be > coordinating on this. Intel is pushing patches that apparently don't > work on AMD, or aren't necessary on AMD. AMD for its part hasn't been > pushing much in public at all, but has made a few list posts, and they > have that mystery microcode update. Probably not much point co-operating. The *internals* of AMD chips and Intel chips are very different. I suspect both of them have a RISC core with an x86 instruction set interpretation layer, but that's where the similarities end ... Bit like expecting a turbo-prop engine company to co-ordinate their designs with a piston engine company. The two engines might look very similar on the outside, but the internal machinery bears no resemblance whatsoever one to the other. Cheers, Wol
Re: [gentoo-user] microcode applied?
On Tuesday, 9 January 2018 07:31:35 GMT Mick wrote: > On Tuesday, 9 January 2018 00:15:03 GMT Peter Humphrey wrote: > > On Monday, 8 January 2018 10:29:41 GMT Max Zettlmeißl wrote: > > > > How do you build the microcode into the kernel? The only > > > > place I can see to do that in menuconfig is under Device Drivers; > > > > there's no such field under Firmware. > > > > > > The Device Drivers section is exactly where the microcode is included. > > > CONFIG_EXTRA_FIRMWARE is the relevant symbol. > > > > Right. So which of the 95 files under /lib/firmware/intel-ucode do I > > specify? That's in addition to the 14 files I have for my amdgpu. > > There may be a cleverer way, but this is how I have been doing it. > > Install sys-apps/iucode_tool. Run: > > # iucode_tool -S > > It will report the microcode signature for your CPU. For example, one of > mine: > > iucode_tool: system has processor(s) with signature 0x000106e5 > > > (Re)emerge sys-firmware/intel-microcode and capture all its output. Then > search for the above signature, again from the same CPU, as an example, > this matches: > > intel-ucode/06-1e-05 > signature: 0x106e5<== > flags: 0x13 > revision: 0x07 > date: 2013-08-20 > size: 7168 > > > Add the first line above in your CONFIG_EXTRA_FIRMWARE and rebuild your > kernel. Thanks Mick. After asking that, I discovered this web page, which confirms your method: https://wiki.gentoo.org/wiki/Intel_microcode . Then I found that I was already loading the right microcode, though I really have no idea where I'd got the information from. Thanks to the others who answered as well. -- Regards, Peter.
Re: [gentoo-user] microcode applied?
>
> Hopefully there's an equivalent for AMD.
>
Here's what I came up with. This is very hacky and unreliable, but get the
CPUID with;
cpuid -r | grep "0x0001 0x00" | awk '{ print $3}' | uniq | cut -d x -f 3
then grab MCE (thanks Max for the suggestion) from
https://github.com/platomav/MCExtractor
unzip MCExtractor-master.zip
cd MCExtractor-master
chmod +x MCE.py
dos2unix MCE.py
./MCE.py /lib/firmware/amd-ucode/*bin
(at this stage it complained about missing dev-python/colorama and
dev-python/prettytable, so i had to emerge them)
Then press enter and it dumps out CPUID and version for each file.
Other than case differences i found the CPUID for my fam10 AMD system. eg
# cpuid -r | grep "0x0001 0x00" | awk '{ print $3}' | uniq | cut -d x
-f 3
00100f43
And in the MCE output;
| 4 | 00100F43 | 01C8 | 2010-03-11 | Latest |
Dmesg had
microcode: CPU0: patch_level=0x01c8
So its confirmed its at the latest microcode, from 2010
[gentoo-user] Firefox-57.0.4 won't accept TLS certificate exception
I just noticed I am not able to override FF's protestations about the domain name of the loaded TLS certificate not matching the visited domain. When I click on Advance/"Confirm Security Exception" to permanently store this exception nothing happens. All I can do thereafter is cancel this pop up window. Of course the page will not load. How can I overcome this intransigence by the browser, who thinks it knows better what I wish to do? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Firefox-57.0.4 won't accept TLS certificate exception
On Tuesday, 9 January 2018 11:34:24 GMT Mick wrote: > I just noticed I am not able to override FF's protestations about the > domain name of the loaded TLS certificate not matching the visited > domain. When I click on Advance/"Confirm Security Exception" to > permanently store this exception nothing happens. All I can do > thereafter is cancel this pop up window. Of course the page will not > load. I've noticed something similar, but it varies from one site to another. Sometimes, confirming an exception works as before, but at other times I'm not even offered the option to make an exception. In that latter case I fire up another browser and use that instead. > How can I overcome this intransigence by the browser, who thinks it knows > better what I wish to do? I wish I knew. -- Regards, Peter.
Re: [gentoo-user] Firefox-57.0.4 won't accept TLS certificate exception
On Tuesday, 9 January 2018 11:50:56 GMT Peter Humphrey wrote: > On Tuesday, 9 January 2018 11:34:24 GMT Mick wrote: > > I just noticed I am not able to override FF's protestations about the > > domain name of the loaded TLS certificate not matching the visited > > domain. When I click on Advance/"Confirm Security Exception" to > > permanently store this exception nothing happens. All I can do > > thereafter is cancel this pop up window. Of course the page will not > > load. > > I've noticed something similar, but it varies from one site to another. > Sometimes, confirming an exception works as before, but at other times I'm > not even offered the option to make an exception. In that latter case I fire > up another browser and use that instead. > > > How can I overcome this intransigence by the browser, who thinks it knows > > better what I wish to do? > > I wish I knew. :-) It seems it won't allow me to accept the certificate *permanently* but it accepts it temporarily. Phew! I also had to remove a number of security addons which no longer work, but this was not related to the certificate problem. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] microcode applied?
On Tue, Jan 9, 2018 at 4:26 AM, Wols Lists wrote: > On 08/01/18 13:52, Rich Freeman wrote: >> There is also a lot of discussion on lkml about the right fix. We >> might very well end up seeing both AMD- and Intel-specific fixes with >> conditional logic. The two vendors don't really seem to be >> coordinating on this. Intel is pushing patches that apparently don't >> work on AMD, or aren't necessary on AMD. AMD for its part hasn't been >> pushing much in public at all, but has made a few list posts, and they >> have that mystery microcode update. > > Probably not much point co-operating. The *internals* of AMD chips and > Intel chips are very different. I suspect both of them have a RISC core > with an x86 instruction set interpretation layer, but that's where the > similarities end ... > The fact that their internals are very different is EXACTLY why they need to cooperate. Spectre cannot be remediated in existing CPUs with a microcode update only. It might not even be possible to completely fix it in future CPUs with only a hardware change. Spectre remediation (at least at present) requires software changes as well. Software is written to the ISA, and both Intel and AMD share a common ISA for the most part. It is impossible for a programmer to know how the internals of the CPU actually work, so they write their code to the ISA specifications. If the ISA says to insert an LFENCE instruction immediately after every bounds check then programmers (or at least compiler designers) will do just that. If it says to insert a CPUID instruction after every bounds check then that is what programmers/compilers will do. However, if one of the major vendors tells everybody to do one thing, and the other tells everybody to do another, and each writes their microcode fixes to work only their way, then programmers are stuck trying to reconcile them. The two vendor CPUs are no longer truly instruction-set compatible for typical software. Adding a lot of conditional branching anytime there is a bounds check to try to detect the CPU and deal with it isn't a great workaround either, because branching is what causes the problem in the first place - it would be better to determine the correct fix at compile-time and not runtime. Intel and AMD don't need to agree on how to fix the internals of their CPUs. What they do need to agree on is the changes that need to be made in the ISA. Since AMD has been relatively quiet I suspect they intend to just let Intel define the fix, and then quietly patch their CPUs to accept the same fix, or at least to not have any issues when the Intel fix is used. However, the fact that they quietly issued a microcode update doesn't go along with that, especially since they haven't provided any clarification on what it does, or whether anything needs to be done with software to take advantage of it. Intel, while not being all that cooperative, has at least issued unambiguous statements on what needs to be done to remediate everything. -- Rich
[gentoo-user] Re: microcode applied?
On Mon, 08 Jan 2018 11:53:58 +, Mick wrote: > On Monday, 8 January 2018 09:05:02 GMT Max Zettlmeißl wrote: >> It seems like there are no microcode updates for your specific CPU >> bundled in linux-firmware. > > Only two out of three Intel boxen here report an early update of microcode in > dmesg. Even when they do, it is not certain the latest firmware has brought > new code: > > [0.00] microcode: microcode updated early to revision 0x7, date = > 2013-08-20 > > This date above puzzles me. Is it that on this PC's CPU the Intel bugs > cannot > be ameliorated by the latest intel-ucode release, or is it that Intel have > not > bothered to release microcode revisions for all their products. The latter - older CPUs simply don't get updates. My server & workstation are i5/i7 SandyBridge built in early 2012, and their last microcode updates are from 2013 as well. > Therefore if microcode for my CPU was included in intel-ucode releases since > 2017-01-01, is this the same unchanged microcode being released since the > date > reported in dmesg of 2013-08-20? Seems like it. -h
[gentoo-user] Re: microcode applied?
On Tue, 09 Jan 2018 14:21:10 +, Holger Hoffstätte wrote: > On Mon, 08 Jan 2018 11:53:58 +, Mick wrote: > >> On Monday, 8 January 2018 09:05:02 GMT Max Zettlmeißl wrote: >>> It seems like there are no microcode updates for your specific CPU >>> bundled in linux-firmware. >> >> Only two out of three Intel boxen here report an early update of microcode >> in >> dmesg. Even when they do, it is not certain the latest firmware has brought >> new code: >> >> [0.00] microcode: microcode updated early to revision 0x7, date = >> 2013-08-20 >> >> This date above puzzles me. Is it that on this PC's CPU the Intel bugs >> cannot >> be ameliorated by the latest intel-ucode release, or is it that Intel have >> not >> bothered to release microcode revisions for all their products. > > The latter - older CPUs simply don't get updates. My server & workstation > are i5/i7 SandyBridge built in early 2012, and their last microcode updates > are from 2013 as well. > >> Therefore if microcode for my CPU was included in intel-ucode releases since >> 2017-01-01, is this the same unchanged microcode being released since the >> date >> reported in dmesg of 2013-08-20? > > Seems like it. Just read that Intel plans to ship microcode updates for CPUs built in and after *2013*, so I guess that means anything after & including Ivy Bridge. Announcement: https://www.youtube.com/watch?v=RlJ9zB74G_U All my machines will be running AMD very soon. I need more cores anyway. -h
Re: [gentoo-user] How do I customize x11-terms/xterm?
On 01/09/2018 01:52 AM, Neil Bothwick wrote: You can usually add extra configure items by creating, in your case /etc/portage/env/x11-terms/xterm containing EXTRA_ECONF="--enable-blah..." That seems simple enough. Putting the patch in /etc/portage/patches/x11-xterms/xterm should do it. Okay. I suppose that it will need to be some sort of diff that will automatically get applied? Do you know what directory the diff needs to be based in? Where can I read more about this? - Sorry for the n00b like questions. I do appreciate the help. :-) I assume removing both my customizations and re-emerging xterm will revert back to Gentoo default. Both of these features are on by default in EAPI6, the xterm ebuild uses EAPI5 so try it and see. Fair enough. I'll give it a try in the next few days and report my findings. Thank you again Neil. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-user] How do I customize x11-terms/xterm?
Hi Grant, I believe this wiki page is what you're looking for: https://wiki.gentoo.org/wiki//etc/portage/patches -- Andrew
Re: [gentoo-user] How do I customize x11-terms/xterm?
On Tue, 9 Jan 2018 10:14:50 -0700, Grant Taylor wrote: > > Putting the patch in /etc/portage/patches/x11-xterms/xterm should do > > it. > > Okay. > > I suppose that it will need to be some sort of diff that will > automatically get applied? > > Do you know what directory the diff needs to be based in? The directory created when the tarball is unpacked AFAIR. > Where can I read more about this? - Sorry for the n00b like questions. devmanual.gentoo.org is the definitive guide, there's also information spread around the wiki. -- Neil Bothwick Accept that some days you're the pigeon, and some days you're the statue. pgp0G830_a2BS.pgp Description: OpenPGP digital signature
[gentoo-user] WARNING: DO NOT update to sys-apps/attr-2.4.48
Desaster Warning Time! Unless you enjoy restoring from backups in the most creative ways, DO NOT casually install today's update of sys-apps/attr-2.4.48, or your box WILL be hosed. If you are on ~arch pmask that thing _right now_: $echo "=sys-apps/attr-2.4.48" >> /etc/portage/package.mask See https://bugs.gentoo.org/644048 for more. -h
Re: [gentoo-user] WARNING: DO NOT update to sys-apps/attr-2.4.48
On Tue, Jan 9, 2018 at 2:47 PM, Holger Hoffstätte wrote: > > Desaster Warning Time! > > Unless you enjoy restoring from backups in the most creative ways, > DO NOT casually install today's update of sys-apps/attr-2.4.48, or > your box WILL be hosed. > > If you are on ~arch pmask that thing _right now_: > > $echo "=sys-apps/attr-2.4.48" >> /etc/portage/package.mask > > See https://bugs.gentoo.org/644048 for more. > Thanks for the heads up - this just got everybody's attention. The package is masked for now (an emerge --sync will eventually pull that mask in). It won't be unmasked until this is sorted out. Anybody who recently synced should be careful until the mirrors catch up. -- Rich
[gentoo-user] Re: Profile 17.0, PIE, USE="pic", C(XX)FLAGS "-fpic", "-fPIC"?
Walter Dnes wrote: > Question: does PIE imply pic/PIC? The code is somewhat different, but in principle yes. > I.e does a PIE build also require USE="pic" Assembler code which breaks pic will also break pie, so better do not use that code. > and CFLAGS/CXXFLAGS="-fpic -fPIC"? These are usually added for libraries anyway. They do not belong into your "manual" configuration file. > If so, is there a way to disable PIE in profile 17.0? If you want to switch it off for a particular binary, there are -fno-PIE -no-pie. Ebuilds should add it automatically if needed. So far, I only needed it for clisp: https://bugs.gentoo.org/show_bug.cgi?id=618170
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
On 01/09/2018 01:56 AM, Mick wrote: > On Monday, 8 January 2018 17:47:03 GMT Corbin Bird wrote: >> On 01/07/2018 02:46 PM, taii...@gmx.com wrote: >>> I have several sandy/ivybridge CPU's and I was wondering if anyone >>> knows as to if intel is releasing microcode updates for them. >>> >>> It sure would be funny if intel wanted you to buy a new CPU to fix a >>> problem that was their fault to begin with. >> Do you remember the x87 bugs discovered in the original i586 Pentiums? >> Never fixed. >> Still built into every Intel CPU. >> Intel does NOT replace "defective-by-design" hardware. >> Instead, every OS is required to "software emulate" the FPU. >> >> Search for "errata-not-bug". >> Intel's term for their screw-ups in their CPUs. >> >> Intel is only releasing patch code for the last five years of products. >> >> And ... if you read up on the "e-mails" being posted ... >> ... It looks as if Intel is NOT going to fix this in future CPUs either. >> Instead, every OS will be required to "work-around-this". >> >> Perhaps the reason "someone" tried to implicate this effects ALL CPU >> architectures? >> ( IBM RISC 6000, PowerPC, DEC Alpha, IBM System/390, Sun SPARC64, for >> example ) >> >> Intel did try to make their "patch" mandatory for AMD CPUs ( with NO >> disable switch ). >> Why? >> Think about it. >> >> Corbin > So what affordable and available CPUs should one be looking into for a new > desktop build? > > Also, laptops? > At this point, the only sure bet, is a non x86, x86_64, ARM, ARM64 CPU. Don't know enough to make a recommendation on a particular CPU arch at this point. Try asking taii...@gmx.com or Ian Zimmerman ( both on gentoo-users mailing list ) about PPC/PPC64. Re-post of saved e-mail : > On 12/25/2017 06:33 PM, Ian Zimmerman wrote: > >> On 2017-12-24 14:44, taii...@gmx.com wrote: >> >>> POWER 9: TALOS 2 (server/workstation, brand new and very high >>> performance - the only brand new hardware that is legitimately libre) >> This is interesting, but can it run gentoo? There's a handbook edition >> for PPC64, but that's not quite the same, is it? > It is. > PPC64 is big endian, PPC64LE is little endian. > > POWER8/9 are Bi-Endian so you can use both (most linux distros only > support little) > > PPC64 compile covers PowerPC and POWER. > > > TALOS 2 is an end user obtainable derivative of the Romulus POWER 9 > development board, there are a variety of modifications and it is more > open source than Romulus - you can also pay for it with bitcoin. > It supports dual sforza CPU's which have up to 24 cores per socket > with SMT4 (4 threads at the same time per core)
Re: [gentoo-user] Microcode updates for "old" Intel CPU's
On Tue, Jan 9, 2018 at 8:33 PM, Corbin Bird wrote: > > On 01/09/2018 01:56 AM, Mick wrote: > > At this point, the only sure bet, is a non x86, x86_64, ARM, ARM64 CPU. > > Don't know enough to make a recommendation on a particular CPU arch at this > point. > Good luck with that... If you aren't hearing about Spectre fixes for a CPU it is most likely because it is so obscure that nobody has bothered to check whether it is vulnerable. Sure, there are some CPUs that have been tested and found to be ok. However, almost anything modern is vulnerable to spectre. I just wasn't something that was on anybody's radar. New CPUs are likely to be resistant to these types of attacks regardless of vendor. Sure, if I was about to place an order for 1000 CPUs tomorrow I'd probably pick AMD over Intel to avoid the PTI overhead, but that is about as far as I'd let these vulnerabilities affect purchase decisions. There are lots of good reasons to go with ARM vs x86, but this isn't really one of them. And outside of x86/ARM I think almost any other CPU choice is going to be a niche item. -- Rich
