[coreboot] microcode updates
I had not seen this, maybe you all have, but: http://inertiawar.com/microcode/ ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] microcode updates
Hello! No I haven't. But I've known about the Intel Microcode update idea for about fifteen years. Turns out that the Linux Kernel 2.4.33.2 of course has it, and described the update process. The two responsible for that method have been out of business so to speak for a while now. But according to that site its still being done. Interesting. I do also know its volatile, in that if the computer gets shutdown and thence turned off, the feature would need to be flashed back onto its CPU and so forth. - Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." On Tue, Jul 8, 2014 at 12:27 PM, ron minnich wrote: > I had not seen this, maybe you all have, but: > http://inertiawar.com/microcode/ > > ron > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] microcode updates
you can no longer update microcode after the kernel boots (on modern Intel CPUs). It has to happen before you do Cache As Ram in many cases, or you'll get some pretty unpleasant consequences. ron On Tue, Jul 8, 2014 at 9:34 AM, Gregg Levine wrote: > Hello! > No I haven't. But I've known about the Intel Microcode update idea for > about fifteen years. Turns out that the Linux Kernel 2.4.33.2 of > course has it, and described the update process. The two responsible > for that method have been out of business so to speak for a while now. > > But according to that site its still being done. Interesting. I do > also know its volatile, in that if the computer gets shutdown and > thence turned off, the feature would need to be flashed back onto its > CPU and so forth. > - > Gregg C Levine gregg.drw...@gmail.com > "This signature fought the Time Wars, time and again." > > > On Tue, Jul 8, 2014 at 12:27 PM, ron minnich wrote: > > I had not seen this, maybe you all have, but: > > http://inertiawar.com/microcode/ > > > > ron > > > > -- > > coreboot mailing list: coreboot@coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] microcode updates
On Tue, Jul 8, 2014 at 10:39 AM, ron minnich wrote: > you can no longer update microcode after the kernel boots (on modern Intel > CPUs). It has to happen before you do Cache As Ram in many cases, or you'll > get some pretty unpleasant consequences. so even microcode_early will not help? config MICROCODE_EARLY bool "Early load microcode" depends on MICROCODE=y && BLK_DEV_INITRD select MICROCODE_INTEL_EARLY if MICROCODE_INTEL select MICROCODE_AMD_EARLY if MICROCODE_AMD default y help This option provides functionality to read additional microcode data at the beginning of initrd image. The data tells kernel to load microcode to CPU's as early as possible. No functional change if no microcode data is glued to the initrd, therefore it's safe to say Y. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] microcode updates
no, that is not early enough on some CPUs. ron On Tue, Jul 8, 2014 at 11:20 AM, yhlu wrote: > On Tue, Jul 8, 2014 at 10:39 AM, ron minnich wrote: > > you can no longer update microcode after the kernel boots (on modern > Intel > > CPUs). It has to happen before you do Cache As Ram in many cases, or > you'll > > get some pretty unpleasant consequences. > > so even microcode_early will not help? > > config MICROCODE_EARLY > bool "Early load microcode" > depends on MICROCODE=y && BLK_DEV_INITRD > select MICROCODE_INTEL_EARLY if MICROCODE_INTEL > select MICROCODE_AMD_EARLY if MICROCODE_AMD > default y > help > This option provides functionality to read additional microcode > data > at the beginning of initrd image. The data tells kernel to load > microcode to CPU's as early as possible. No functional change if > no > microcode data is glued to the initrd, therefore it's safe to > say Y. > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] microcode updates
ron minnich [mailto:rminn...@gmail.com] wrote: ]you can no longer update microcode after the kernel boots ](on modern Intel CPUs). It has to happen before you do Cache ]As Ram in many cases, or you'll get some pretty unpleasant ]consequences. ] ]ron ] ][...] While I am no expert on recent Intel processors, it appears Intel still distributes patch packages for OS use (goo.gl/ffLdyq) and Linux still applies them (goo.gl/oaBvdE). Thanks, Scott -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] microcode updates
Yes, and that's sensible for some cases, if you consider that people don't always keep their firmware up to date! To be honest, I'm trying a little bit to discourage the idea that it's safe to build coreboot without microcode blobs on modern CPUs. Might work on your x60. Not recommended on more recent chipsets. Yes, you might get it to boot. That's almost worse than having it fail. ron On Tue, Jul 8, 2014 at 11:26 AM, Scott Duplichan wrote: > ron minnich [mailto:rminn...@gmail.com] wrote: > > ]you can no longer update microcode after the kernel boots > ](on modern Intel CPUs). It has to happen before you do Cache > ]As Ram in many cases, or you'll get some pretty unpleasant > ]consequences. > ] > ]ron > ] > ][...] > > While I am no expert on recent Intel processors, it appears > Intel still distributes patch packages for OS use (goo.gl/ffLdyq) > and Linux still applies them (goo.gl/oaBvdE). > > Thanks, > Scott > > > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] microcode updates
Hello! Agreed on all points. Now Scott, I'm certainly no expert on Intel processors either, but in a word, "Thank you!", regarding all of that searching and finding out where that stuff is based. - Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." On Tue, Jul 8, 2014 at 2:57 PM, ron minnich wrote: > Yes, and that's sensible for some cases, if you consider that people don't > always keep their firmware up to date! > > To be honest, I'm trying a little bit to discourage the idea that it's safe > to build coreboot without microcode blobs on modern CPUs. Might work on your > x60. Not recommended on more recent chipsets. Yes, you might get it to boot. > That's almost worse than having it fail. > > ron > > > On Tue, Jul 8, 2014 at 11:26 AM, Scott Duplichan wrote: >> >> ron minnich [mailto:rminn...@gmail.com] wrote: >> >> ]you can no longer update microcode after the kernel boots >> ](on modern Intel CPUs). It has to happen before you do Cache >> ]As Ram in many cases, or you'll get some pretty unpleasant >> ]consequences. >> ] >> ]ron >> ] >> ][...] >> >> While I am no expert on recent Intel processors, it appears >> Intel still distributes patch packages for OS use (goo.gl/ffLdyq) >> and Linux still applies them (goo.gl/oaBvdE). >> >> Thanks, >> Scott >> >> >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > > > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] microcode updates
ron minnich wrote: > To be honest, I'm trying a little bit to discourage the idea that it's safe > to build coreboot without microcode blobs on modern CPUs. Might work on > your x60. Not recommended on more recent chipsets. Yes, you might get it to > boot. That's almost worse than having it fail. I think very specific details would strengthen this argument. I'm not saying that the argument is wrong, I'm saying that it would be great to learn about specific experience. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] microcode updates
On Tue, Jul 8, 2014 at 1:07 PM, Peter Stuge wrote: > > > I think very specific details would strengthen this argument. I'm not > saying that the argument is wrong, I'm saying that it would be great > to learn about specific experience. > > you are absolutely right. I'm just trying to figure out how much I can say. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] microcode updates
Am 08.07.2014 20:57, schrieb ron minnich: > Might work on your x60. Not recommended on more recent chipsets. Yes, > you might get it to boot. That's almost worse than having it fail. For a not-so-recent example, some of the later Via processors require a microcode update lest they hang when you change the processor clock. Similar non-obvious issues can happen with caches (I think Intel alluded to potential issues in that general area every now and then, maybe even on the Core/Core2 things you find in the X60 - I hope they're just being cautious here), and these issues might not be as prominent - you really are lucky if your system hangs hard instead of probabilistically flipping every 20th bit it processes. Since we really rely on caches when we enable _Cache_-as-RAM, having them fully functional is a good thing. Since Microcode usually comes without a (useful) change log (bad, bad CPU-vendors!), we have to be cautious here. Like many computing products, CPUs these days are banana-ware: shipped still "green", they mature at the customer's. If possible, apply the newest update you can find as soon as possible. Since people are so bad with updating their firmware, Linux can do a second run if necessary. Patrick signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] microcode updates
Thanks for the good examples, Patrick. So I'll say it one more time: while I understand the concerns about the microcode blob, and I appreciate the sincerity of those who want to build coreboot images that don't have them, I think it's a huge mistake to take that path on almost anything made in the last decade. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Microcode Updates PSA (New users please read)
I am making this due to seeing many mis-informed users that are engaging in dangerous practices. Microcode updates should ALWAYS be installed unless you are an expert user and have repeatedly verified that your CPU doesn't require them and you are prepared for the risks which include for instance on the piledriver CPU's (opteron 63xx/43xx and the G505S's laptop cpus) a userland to root exploit, a broken IOMMU and a timer issue that means games and certain applications don't work properly. Unfortunately x86 is stuck with non owner controlled undocumented proprietary microcode updates and in the case of intel they are encrypted for some reason - AFAIK only POWER has owner controlled microcode. Despite this it is still a good idea to install them - I do on my coreboot computers and thus I don't ruin my security for no good reason. NOTE: For microcode embedding in coreboot to work you must check both the "generate microcode update from tree" option and the "use non-free blob repo" option - doing the first but not the second will result in a silent fail. 0xDF372A17.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode Updates PSA (New users please read)
Regarding a NOTE from your last message: > For microcode embedding in coreboot to work you must check > both the "generate microcode update from tree" option and the > "use non-free blob repo" option - > doing the first but not the second will result in a silent fail. It works for KGPE-D16 but doesn't work for G505S and maybe some other AMD boards. Currently the only working way for those "other boards" to get the latest microcodes is to " xxd -i -c 8 " a microcode binary and then put this array of hex values into their .c file containing a microcode ( path like [1] ) . Tired of doing this manually, yesterday I wrote these microcode updating scripts : https://review.coreboot.org/c/coreboot/+/28425 AMD microcodes: scripts for applying the unofficial (not-merged-yet) updates Put those 4 files to your freshly cloned coreboot directory, run ./get_ucode_patches.sh , ./check... and ./apply... , and your fresh coreboot now has the latest microcodes ;-) But thats only for those "other boards" like G505S. To get the latest microcode for your KGPE-D16, you may also need to patch its' microcode_amd_fam15h.bin with a new 2018 microcode which sadly is not merged yet neither to linux-firmware nor to coreboot [1] example of a path to .c file with microcode - ./coreboot/src/vendorcode/amd/agesa/f16kb/Proc/CPU/Family/0x16/KB/F16KbId7001MicrocodePatch.c On Sat, Sep 1, 2018 at 10:41 PM taii...@gmx.com wrote: > > I am making this due to seeing many mis-informed users that are engaging > in dangerous practices. > > Microcode updates should ALWAYS be installed unless you are an expert > user and have repeatedly verified that your CPU doesn't require them and > you are prepared for the risks which include for instance on the > piledriver CPU's (opteron 63xx/43xx and the G505S's laptop cpus) a > userland to root exploit, a broken IOMMU and a timer issue that means > games and certain applications don't work properly. > > > Unfortunately x86 is stuck with non owner controlled undocumented > proprietary microcode updates and in the case of intel they are > encrypted for some reason - AFAIK only POWER has owner controlled microcode. > > Despite this it is still a good idea to install them - I do on my > coreboot computers and thus I don't ruin my security for no good reason. > > > NOTE: > For microcode embedding in coreboot to work you must check both the > "generate microcode update from tree" option and the "use non-free blob > repo" option - doing the first but not the second will result in a > silent fail. > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
I am curious of any intel insiders know if there will be microcode updates released for older intel CPU's (ex: sandy/ivybridge) and failing that, what can be done in regards to securing them from meltdown/spectre. I believe this is a relevant coreboot topic considering how many coreboot boards have these and older CPU'swithout a fix there will be only one coreboot compatible laptop with open source hardware initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD CPU) and theoretically owner controllable (as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently) At this point even a massive performance loss is better than having to throw out so much now-useless hardware. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
Hello, Off-topic: Top-posted as Protonmail Android App is still unable to correctly use inline answers without correct quote layout/line breaks. Bug has been reported months ago :-/ Taiidan wrote: "(...) CPU'swithout a fix there will be only one coreboot compatible laptop with open source hardware initiation that is remotely secure (...)" Currently I am using two laptops for my work setup: A 12.5" Lenovo X230 and a 15.x" Lenovo W540 both machines are running with Qubes OS 4rc3 and 16GB RAM. The W540 is a Dual-Boot system with Win10, the x230 is running Coreboot. Honestly I am shocked and angry if there will be no Intel Updates for the X230 and W540. On the other hand, if I am running Qubes and Coreboot, wouldn't this reduce the risk of Meltdown/Spectre attacks as Coreboot will protect me against remote attacks (stripped down AMT/Intel ME) and Qubes might reduce the attack surface as I am using several VMs and DVMs for browsing? If I compare the Lenovo X230 to Lenovo G505s this looks like a step back: the G505s is targeted at another audience that Lenovo ThinkPad Users. It looks to me like an entry level desktop, which is also very bulky (without the additional performance of a W540). CPU comparison X230 CPU vs G505s http://www.cpu-world.com/Compare/725/AMD_A6-Series_for_Notebooks_A6-5350M_vs_Intel_Core_i5_Mobile_i5-3360M_(BGA).html Also the G505s has less cores/no HT Frustration. Can't "we" build one or maybe two crowd founded secure Laptops (12", 15.x") with reasonable specs, good keyboard, hardware kill switches, internal wan (kill-switchable)? I can't think that choice is limited in 2018 to only 1 (in words "one") laptop modell, which is no nearly 5 years old (08/2013). Brave new world. [799] Gesendet von ProtonMail mobile Original-Nachricht An 11. Jan. 2018, 03:55, taii...@gmx.com schrieb: > I am curious of any intel insiders know if there will be microcode > updates released for older intel CPU's (ex: sandy/ivybridge) and failing > that, what can be done in regards to securing them from meltdown/spectre. > > I believe this is a relevant coreboot topic considering how many > coreboot boards have these and older CPU'swithout a fix there will > be only one coreboot compatible laptop with open source hardware > initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD > CPU) and theoretically owner controllable (as the previous C2D/C2Q's > such as the X200 are now permanently insecure without intervention from > intel apparently) > > At this point even a massive performance loss is better than having to > throw out so much now-useless hardware. > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
On Wed, 10 Jan 2018 21:55:18 -0500 "taii...@gmx.com" wrote: > I am curious of any intel insiders know if there will be microcode > updates released for older intel CPU's (ex: sandy/ivybridge) and > failing that, what can be done in regards to securing them from > meltdown/spectre. Not an Intel insider, but here is a list from Lenovo listing affected products and when microcode updates will be available addressing Spectre v2: https://support.lenovo.com/de/en/solutions/len-18282 X230 is scheduled for 2/2/2018. I don't know about the X200, but I doubt there will be further microcede updates :/ But actually I don't know. For meltdown, running the latest kernel should be sufficient I guess, since it has the KPTI patches. > > I believe this is a relevant coreboot topic considering how many > coreboot boards have these and older CPU'swithout a fix there > will be only one coreboot compatible laptop with open source hardware > initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD > CPU) and theoretically owner controllable (as the previous C2D/C2Q's > such as the X200 are now permanently insecure without intervention > from intel apparently) > > At this point even a massive performance loss is better than having > to throw out so much now-useless hardware. > > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- Merlin Büge -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
Hi Taiidan, On 11.01.2018 03:55, taii...@gmx.com wrote: > I am curious of any intel insiders know if there will be microcode > updates released for older intel CPU's (ex: sandy/ivybridge) and failing > that, what can be done in regards to securing them from meltdown/spectre. > > I believe this is a relevant coreboot topic considering how many > coreboot boards have these and older CPU'swithout a fix there will > be only one coreboot compatible laptop with open source hardware > initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD > CPU) and theoretically owner controllable you seem to be misinformed about the G505s. There is no open-source gfx init for AMD (not in firmware, not in the OS), so within your require- ments it's not usable as a laptop. > (as the previous C2D/C2Q's > such as the X200 are now permanently insecure without intervention from > intel apparently) It depends on the software you run. Please read more about Meltdown and Spectre. When you understood it, you can still start to worry. > > At this point even a massive performance loss is better than having to > throw out so much now-useless hardware. Yes? and that can be accomplished without microcode updates, AFAIK. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
On Thu, January 11, 2018 10:05 am, Nico Huber wrote: > On 11.01.2018 03:55, taii...@gmx.com wrote: >> only one coreboot compatible laptop with open source hardware initiation >> that is remotely secure (lenovo g505s as has a pre-PSP AMD CPU) and >> theoretically owner controllable > > you seem to be misinformed about the G505s. There is no open-source gfx > init for AMD (not in firmware, not in the OS), so within your require- > ments it's not usable as a laptop. In its defense, it's one of the few usable laptops that don't have ME or PSP. I did a full Debian kernel build inside a Xen HVM on it the other day in 2.5 hours. I'm sure there's faster but for day to day use it's plenty good for me, even though I do need to tolerate a handful of blobs. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
[799] via coreboot wrote: > Can't "we" build one or maybe two crowd founded secure Laptops (12", 15.x") The short answer to that is no, no we can't. The long answer is a discussion over beers or another prefered beverage. //Peter -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
> If I compare the Lenovo X230 to Lenovo G505s this looks like a step back: the G505s is targeted at another audience that Lenovo ThinkPad Users. It looks to me like an entry level desktop, which is also very bulky (without the additional performance of a W540). > CPU comparison X230 CPU vs G505s > AMD_A6-Series_for_Notebooks_A6-5350M_vs_Intel_Core_i5_Mobile_i5-3360M_(BGA) > Also the G505s has less cores/no HT Sorry, but what are you comparing with? G505S is a laptop, not a desktop. and G505S laptop has been sold with different CPUs (which are removable), as well as at least three motherboard versions! ( only integrated GPU / integrated + HD 8570M discrete / integrated + R5 M230 discrete ) That A6-5350M cpu you have been comparing to - could be found at the very low end version of G505S, and this A6 is probably not even supported by coreboot Most (if not all) of G505S+coreboot owners here - have A10-5750M AMD CPU which is a powerful quad core CPU with functional virtualization, not 2 core weak A6-5350M So, this link should have been http://www.cpu-world.com/Compare/815/AMD_A10-Series_for_Notebooks_A10-5750M_vs_Intel_Core_i5_Mobile_i5-3360M_(BGA).html Looks like the performance of A10-5750M (G505S cpu) and i5-3360M (X230 cpu) is almost the same, but now we should substract 5-30% or even more from i5-3360M benchmarks - because the Meltdown vulnerability, for which this horrible "5-30% or even more slowdown patch" is required ---> is Intel specific vulnerability ( cpu_insecure , as reported by Linux kernel ) And... "thanks" to Intel Meltdown, the results are suddenly very favorable for A10-5750M CPU, and for G505S in general Best regards, Ivan Ivanov 2018-01-11 8:34 GMT+03:00 [799] via coreboot : > Hello, > > Off-topic: > Top-posted as Protonmail Android App is still unable to correctly use inline > answers without correct quote layout/line breaks. Bug has been reported > months ago :-/ > > Taiidan wrote: > > "(...) CPU'swithout a fix there will > be only one coreboot compatible laptop with open source hardware > initiation that is remotely secure (...)" > > Currently I am using two laptops for my work setup: > A 12.5" Lenovo X230 and a 15.x" Lenovo W540 both machines are running with > Qubes OS 4rc3 and 16GB RAM. The W540 is a Dual-Boot system with Win10, the > x230 is running Coreboot. > > Honestly I am shocked and angry if there will be no Intel Updates for the > X230 and W540. > On the other hand, if I am running Qubes and Coreboot, wouldn't this reduce > the risk of Meltdown/Spectre attacks as Coreboot will protect me against > remote attacks (stripped down AMT/Intel ME) and Qubes might reduce the > attack surface as I am using several VMs and DVMs for browsing? > > If I compare the Lenovo X230 to Lenovo G505s this looks like a step back: > the G505s is targeted at another audience that Lenovo ThinkPad Users. It > looks to me like an entry level desktop, which is also very bulky (without > the additional performance of a W540). > > CPU comparison X230 CPU vs G505s > http://www.cpu-world.com/Compare/725/AMD_A6-Series_for_Notebooks_A6-5350M_vs_Intel_Core_i5_Mobile_i5-3360M_(BGA).html > > Also the G505s has less cores/no HT > > Frustration. Can't "we" build one or maybe two crowd founded secure Laptops > (12", 15.x") with reasonable specs, good keyboard, hardware kill switches, > internal wan (kill-switchable)? > I can't think that choice is limited in 2018 to only 1 (in words "one") > laptop modell, which is no nearly 5 years old (08/2013). > > Brave new world. > > [799] > > > > > Gesendet von ProtonMail mobile > > > > Original-Nachricht > > An 11. Jan. 2018, 03:55, taii...@gmx.com schrieb: > > > I am curious of any intel insiders know if there will be microcode > updates released for older intel CPU's (ex: sandy/ivybridge) and failing > that, what can be done in regards to securing them from meltdown/spectre. > > I believe this is a relevant coreboot topic considering how many > coreboot boards have these and older CPU'swithout a fix there will > be only one coreboot compatible laptop with open source hardware > initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD > CPU) and theoretically owner controllable (as the previous C2D/C2Q's > such as the X200 are now permanently insecure without intervention from > intel apparently) > > At this point even a massive performance loss is better than having to > throw out so much now-useless hardware. > > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
Hi, afaik, Intel did not publish any info about the affectedness of the Core2Duo generation to date. I tried the Spectre-Demos for variant 1 on the X200 [1], and it seems unaffected while e.g. the Opterons on the KGPE-D16 are just as affected as all those Intel CPUs. Nevertheless, this should be fixable by OS updates only so nothing to worry about. It's only that ATM afaik only CentOS/RHEL ships updates for v1, as they have not been integrated into the Linux kernel yet. Regarding v3, there is not much to worry about either since it's also fixable by the KPTI-Kernel patch most distros should already have included by now (the one that is known to cause performance impact). The remaining and most important question is regarding v2, where the situation is unclear. And no, Qubes will not protect you from v2 because it allows the "isolated" stuff you run in your VM to escape this isolation and e.g. read the Host's memory - i.e. Dom0 in Qubes-speak. Regarding the 2nd and 3rd core-i-gen: Since Lenovo announced to release updates for the T530, and taking into account that some early "low-end" versions of the T530 had a 2nd-gen core-i CPU, there is (very) slight hope Intel will provide microcode updates for this generation. However, I haven't seen any other vendor than Lenovo making announcements about devices from these generations, so I have some doubt that Lenovo will provide updates at all. Regarding the impact: Not having fixes for v2 does not render the machine completely insecure, but you basically know for sure that you can't expect getting any secure isolation by running untrusted code in VMs. However, since the X200 has no IOMMU, I am not sure to which degree the level of isolation provided before was secure anyways. Cheers, Daniel [1] https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
On 01/11/2018 05:05 AM, Nico Huber wrote: you seem to be misinformed about the G505s. There is no open-source gfx init for AMD (not in firmware, not in the OS), so within your require- ments it's not usable as a laptop. I forgot to include my usual suffix mentioning that blobs are required for video (and power management) I believe it is still much better than the C2D laptops in terms of security despite the video blob as it has an IOMMU [1] and no ME/PSP. [1] with the high end quad core CPU option (as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently) It depends on the software you run. Please read more about Meltdown and Spectre. When you understood it, you can still start to worry. At this point even a massive performance loss is better than having to throw out so much now-useless hardware. Yes? and that can be accomplished without microcode updates, AFAIK. I was and still am under the impression that fixing both issue classes requires microcode updates, can you link to a better explanation? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
On Thu, 11 Jan 2018 17:22:48 -0500 "taii...@gmx.com" wrote: > On 01/11/2018 05:05 AM, Nico Huber wrote: > > > you seem to be misinformed about the G505s. There is no open-source > > gfx init for AMD (not in firmware, not in the OS), so within your > > require- ments it's not usable as a laptop. > I forgot to include my usual suffix mentioning that blobs are > required for video (and power management) > > I believe it is still much better than the C2D laptops in terms of > security despite the video blob as it has an IOMMU [1] and no ME/PSP. > [1] with the high end quad core CPU option > >> (as the previous C2D/C2Q's > >> such as the X200 are now permanently insecure without intervention > >> from intel apparently) > > It depends on the software you run. Please read more about Meltdown > > and Spectre. When you understood it, you can still start to worry. > > > >> At this point even a massive performance loss is better than > >> having to throw out so much now-useless hardware. > > Yes? and that can be accomplished without microcode updates, AFAIK. > I was and still am under the impression that fixing both issue > classes requires microcode updates, can you link to a better > explanation? https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- Merlin Büge -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What I'm more concerned about right now is something I'd term "security apathy". We just learned 99% of the world's computers are insecure in one way or another; security is now something that (to most people) apparently cannot be purchased. In such an environment, the cheapest system per unit performance always wins, even if it happens to contain rampant abuses of privacy / backdoors. Probably a discussion best had over coffee, since it's largely unfixable, but suffice it to say we're already starting to see this even in our original customer base. On 01/11/2018 04:22 PM, taii...@gmx.com wrote: > On 01/11/2018 05:05 AM, Nico Huber wrote: > >> you seem to be misinformed about the G505s. There is no open-source gfx >> init for AMD (not in firmware, not in the OS), so within your require- >> ments it's not usable as a laptop. > I forgot to include my usual suffix mentioning that blobs are required > for video (and power management) > > I believe it is still much better than the C2D laptops in terms of > security despite the video blob as it has an IOMMU [1] and no ME/PSP. > [1] with the high end quad core CPU option >>> (as the previous C2D/C2Q's >>> such as the X200 are now permanently insecure without intervention from >>> intel apparently) >> It depends on the software you run. Please read more about Meltdown and >> Spectre. When you understood it, you can still start to worry. >> >>> At this point even a massive performance loss is better than having to >>> throw out so much now-useless hardware. >> Yes? and that can be accomplished without microcode updates, AFAIK. > I was and still am under the impression that fixing both issue classes > requires microcode updates, can you link to a better explanation? > - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJaV+TkAAoJEK+E3vEXDOFbghEH/ivQ84bm11KHSDs8+EIWSP1J XeQvhxHlsz5ZNYA16a7QU+dWhn8vOo6es3yBmTgOPsVzu1PUgXwgX1QnfUyAzrml 59d7TZE7p8MtgCAmsUruNgVdPgXEPK/Qh/6uUarVh8U7bRpaOEVcc2thJZCRDLQw U4m8+Z5RudnDz9ZiPVfMKhpqSVJ+FTBzr3uCp+Mqr9CFIV3GxbwWCkoEPbo1hNrq O+ZfCk24GseFfI8fjfpP523nARd8bX0WEUodRaw/l58+vspjGo3DyvjrWpcdJRHg X+dg0I9CKVPt7doFh4NscPmNAhia9R8JfeTj3qCoMiFAvSHcBgb7p8Q8xitIkw0= =gkEr -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
Peter, To initiate this "discussion over beers, etc" (which I hope that we will have at this FOSDEM 2018...), can you give some factual "entry points" sustaining your sharp assertion "no, no we can't"? Thanx, Florentin - Mail d'origine - De: Peter Stuge À: coreboot@coreboot.org Envoyé: Thu, 11 Jan 2018 17:13:31 +0100 (CET) Objet: Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre [799] via coreboot wrote: > Can't "we" build one or maybe two crowd founded secure Laptops (12", 15.x") The short answer to that is no, no we can't. The long answer is a discussion over beers or another prefered beverage. //Peter -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'll give a few: 1.) Lack of appropriate silicon. Everything non-ARM in the appropriate power envelope has a vendor-controlled master processor (ME/PSP/etc.), and even high end ARM has vendor control processors built in. 2.) Lack of volume. Think 100k units or higher before prices even start to come down into "expensive but acceptable", and this plays badly with point #1 above (non-free == why pay 10x or more for such a machine when the $200 Clevo model has the same amount of owner control). 3.) Bikeshedding. Yes, this. Laptops are a more personal choice than e.g. desktops; some people want big clunky workstation replacements, some people want little thin Macbook clones, many want something in between but with large variation in features. That's not even getting into architecture selection problems, since x86 is the root cause of point #1 being a problem. Everyone would have to want one model and pay extra for it to even start looking at volumes reaching the correct level. 4.) Financing. This is a ~ $200 million or more project from start to finish; unless someone sympathetic has a lot of Bitcoin stashed away it's going to be hard to get this to happen. These are basically the reasons we haven't launched a laptop yet despite really wanting to -- the market simply isn't ready at this point. Also see my earlier post from today on "Security Apathy"; this is helping to make the market worse, not better, for such a machine. On 01/11/2018 06:27 PM, eche...@free.fr wrote: > Peter, > To initiate this "discussion over beers, etc" (which I hope that we will have > at this FOSDEM 2018...), can you give some factual "entry points" sustaining > your sharp assertion "no, no we can't"? > Thanx, > Florentin > > - Mail d'origine - > De: Peter Stuge > À: coreboot@coreboot.org > Envoyé: Thu, 11 Jan 2018 17:13:31 +0100 (CET) > Objet: Re: [coreboot] Microcode updates for slightly older intel CPU's re: > meltdown/spectre > > [799] via coreboot wrote: >> Can't "we" build one or maybe two crowd founded secure Laptops (12", 15.x") > > The short answer to that is no, no we can't. The long answer is a > discussion over beers or another prefered beverage. > > > //Peter > - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJaWANZAAoJEK+E3vEXDOFbicoH/RQoHYNp5TV5bbhaSuPQ6n3D nBvNuIfzbGe/PaSkmPxSLOLJF1xDVJByRxjdOme3gekXF9oQQtWhCDeXRH8PF+Ma DCm28eCm9Io9PTy3E1wZlUmG71ClJJdubuq/WH55TEI+tjFliY+Dv8aXT9v4Igqg 507dvcdchArBVfiUeRA7d48zrsGs2Ny7yxZQQZQulJgCtTioTprtDmjP1U59ogbp hzb5WxZ9ZR9uP2yLOqXPiwUnPsrEgVutLqapZRfIdzdmmNmtUM1IFQQzeuB2z5Ok Sdsollp+IICkqgS87Kcq0GLhWhwgIvoBuB+d5ph3GGltGWKBdYuysJUJKuvHe2Q= =PEM9 -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
Hi Nico, > > you seem to be misinformed about the G505s. There is no > open-source gfx init for AMD (not in firmware, not in the OS), > so within your requirements it's not usable as a laptop > I've had a small discussion with bridgman from AMD (at Phoronix forums) and he told me that VBIOS needed by G505S - aka "gfx init for AMD" - - is "effectively open source" - a byte code which is possible to parse with [AtomDis] open source interpreter Only problem is that the last update of AtomDis was at 2011 - so, while it should be able to parse 100% of G505S integrated / discrete GPUs AtomBIOSes (because these GPUs were developed before 2011 if I am correct) maybe AtomDis couldn't parse everything for the modern AMD GPUs Me: " @bridgman why you don't just open source the complete source code of VBIOS, to let the open source community improve it and fix some bugs? With the help of flashrom open source project, anyone is able to reflash their VBIOS through In-System-Programming. We just don't have the original source code of VBIOS, and the creation of open source VBIOS from scratch is like reinventing the wheel - a huge wheel, which is way too much for unpaid work Just share the complete source code of VBIOS and let the open source community fix the bugs for you for free! A win-win solution. Why not do it? For the bystanders like me, it gives an impression that either 1) VBIOS source code is a horrible quality, too ashamed to release it to public 2) VBIOS contains some hidden backdoors, hence the need for secrecy 3) AMD is not that friendly to open source community, if instead of sharing what you already got, you want the people to start reinventing the wheel and waste countless of unpaid work hours on it " brigman: " It is effectively open source. The data tables are all documented in atombios.h. They are just data structures. The command table parameters are all documented in atombios.h (also just data structures). The command tables are all written in byte code to begin with. The source to the interpreter is open source so you can dump command tables and see exactly what they are doing. You can even write your own command tables in byte code or edit exiting ones if you wanted to. Those are the only things the driver uses from the vbios. The whole point of the data and command tables is to encapsulate board specific configuration details on the actual board itself so that the driver doesn't need explicit knowledge about every board configuration out there. To summarize: 1. We use an interpreter in VBIOS in order to (a) fit a lot of functionality into a small ROM, (b) give us a degree of CPU independence. My understanding is that this is pretty common practice; either way it's not likely to change unless OEMs buying AMD chips are willing to spend more $$ on the ROM for our hardware than for competitors hardware AND we are willing to go back to having different BIOS code for each of the different CPUs our chips are used with. 2. As agd5f said, the VBIOS source code is bytecode similar to what you get out of the disassembler, although the disassembler output is formatted more neatly. It's not like there is a single master copy of VBIOS source written in C that could be "opened once" - every HW vendor tweaks their BIOS images before production and AFAIK those changes are not ours to publish. Relatively more of the changes are in data tables than in command tables but both get changed and so we need to use both in the driver if we want driver functionality to correctly match the HW config. There are literally thousands of different HW subsystems, each with their own VBIOS image and hence each with their own slightly different source code... and the associated HW differences DO generally need to be considered when the driver runs. 3. A couple of people have started projects to replace VBIOS with a fully open solution, but my impression is that they all run into the same issues: - initial implementation is straightforward but ongoing maintenance is a big and boring effort nobody wants to own - you lose CPU independence unless you are willing to maintain AND TEST a lot more different VBIOS builds - without an interpreter the resulting implementation won't fit in the on-card ROM unless you cut back functionality We make enough information for an open source BIOS replacement available as part of the open source driver effort (data table & command table headers, bytecode interpreter, open source drivers using the tables) although I don't think we support VBIOS re-flashing in general. It is easy to get the same result by over-riding tables in the driver code, however, and I believe there is an existing quirk mechanism. 4. Over time I think you will see a trend away from using AtomBIOS calls simply because ROM size limits the amount of complexity that can be supported in ROM-resident tables while HW complexity is continuing to grow as quickly as ever. My understanding is that DAL/DC makes somewhat less use o
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
Hi, On 12.01.2018 10:51, Mike Banon wrote: > Hi Nico, > >> >> you seem to be misinformed about the G505s. There is no >> open-source gfx init for AMD (not in firmware, not in the OS), >> so within your requirements it's not usable as a laptop >> > > I've had a small discussion with bridgman from AMD (at Phoronix forums) > and he told me that VBIOS needed by G505S - aka "gfx init for AMD" - > - is "effectively open source" - a byte code which is possible to parse > with [AtomDis] open source interpreter well, the same holds for every program where an open-source emulator for its architecture exists. So thanks John Bridgman for open-sourcing the majority of programs in the world! lol... > > Only problem is that the last update of AtomDis was at 2011 - so, while it > should be able to parse 100% of G505S integrated / discrete GPUs AtomBIOSes > (because these GPUs were developed before 2011 if I am correct) > maybe AtomDis couldn't parse everything for the modern AMD GPUs I'm not interested in any disassembly. To my knowledge, there is no OSS implementation because it's not docu- mented what the AtomBIOS byte code does, i.e. how AMDs display engine works and is configured (I might be wrong, if so please tell me and I might start to write code for it soon). If that is true, it shows that there is no technically reason for keeping it under wraps but the de- cision not to document the hardware is pure political. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
Maybe I am very wrong here, but I just looked at this AtomBIOS disassembly https://pastebin.com/raw/Q35JMU1b and there are functions like "MemoryControllerInit / AdjustDisplayPll / AdjustMemoryController ", as well as data blocks like LVDS_Info Could you please tell if it at least appears to be somehow useful for the OSS implementation? By the way, Damien Zammit wrote me that Alex (aka mrnuke) already did 95% of open source VGA init for G505S hardware: https://www.coreboot.org/Board:hp/pavilion_m6_1035dx#Native_graphics_init ( ARUBA is GPU family to which A10-5750M 's HD 8650G belongs) Wonder what are the remaining 5% ;-) On Fri, Jan 12, 2018 at 1:16 PM, Nico Huber wrote: > Hi, > > On 12.01.2018 10:51, Mike Banon wrote: >> Hi Nico, >> >>> >>> you seem to be misinformed about the G505s. There is no >>> open-source gfx init for AMD (not in firmware, not in the OS), >>> so within your requirements it's not usable as a laptop >>> >> >> I've had a small discussion with bridgman from AMD (at Phoronix forums) >> and he told me that VBIOS needed by G505S - aka "gfx init for AMD" - >> - is "effectively open source" - a byte code which is possible to parse >> with [AtomDis] open source interpreter > > well, the same holds for every program where an open-source emulator for > its architecture exists. So thanks John Bridgman for open-sourcing the > majority of programs in the world! lol... > >> >> Only problem is that the last update of AtomDis was at 2011 - so, while it >> should be able to parse 100% of G505S integrated / discrete GPUs AtomBIOSes >> (because these GPUs were developed before 2011 if I am correct) >> maybe AtomDis couldn't parse everything for the modern AMD GPUs > > I'm not interested in any disassembly. > > To my knowledge, there is no OSS implementation because it's not docu- > mented what the AtomBIOS byte code does, i.e. how AMDs display engine > works and is configured (I might be wrong, if so please tell me and I > might start to write code for it soon). If that is true, it shows that > there is no technically reason for keeping it under wraps but the de- > cision not to document the hardware is pure political. > > Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
This assumes security was a concern in the first place, which is not what I see where I live/work. On 01/11/2018 11:27 PM, Timothy Pearson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > What I'm more concerned about right now is something I'd term "security > apathy". We just learned 99% of the world's computers are insecure in > one way or another; security is now something that (to most people) > apparently cannot be purchased. In such an environment, the cheapest > system per unit performance always wins, even if it happens to contain > rampant abuses of privacy / backdoors. > > Probably a discussion best had over coffee, since it's largely > unfixable, but suffice it to say we're already starting to see this even > in our original customer base. > > On 01/11/2018 04:22 PM, taii...@gmx.com wrote: >> On 01/11/2018 05:05 AM, Nico Huber wrote: >> >>> you seem to be misinformed about the G505s. There is no open-source gfx >>> init for AMD (not in firmware, not in the OS), so within your require- >>> ments it's not usable as a laptop. >> I forgot to include my usual suffix mentioning that blobs are required >> for video (and power management) >> >> I believe it is still much better than the C2D laptops in terms of >> security despite the video blob as it has an IOMMU [1] and no ME/PSP. >> [1] with the high end quad core CPU option (as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently) >>> It depends on the software you run. Please read more about Meltdown and >>> Spectre. When you understood it, you can still start to worry. >>> At this point even a massive performance loss is better than having to throw out so much now-useless hardware. >>> Yes? and that can be accomplished without microcode updates, AFAIK. >> I was and still am under the impression that fixing both issue classes >> requires microcode updates, can you link to a better explanation? >> > > - -- > Timothy Pearson > Raptor Engineering > +1 (415) 727-8645 (direct line) > +1 (512) 690-0200 (switchboard) > https://www.raptorengineering.com > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJaV+TkAAoJEK+E3vEXDOFbghEH/ivQ84bm11KHSDs8+EIWSP1J > XeQvhxHlsz5ZNYA16a7QU+dWhn8vOo6es3yBmTgOPsVzu1PUgXwgX1QnfUyAzrml > 59d7TZE7p8MtgCAmsUruNgVdPgXEPK/Qh/6uUarVh8U7bRpaOEVcc2thJZCRDLQw > U4m8+Z5RudnDz9ZiPVfMKhpqSVJ+FTBzr3uCp+Mqr9CFIV3GxbwWCkoEPbo1hNrq > O+ZfCk24GseFfI8fjfpP523nARd8bX0WEUodRaw/l58+vspjGo3DyvjrWpcdJRHg > X+dg0I9CKVPt7doFh4NscPmNAhia9R8JfeTj3qCoMiFAvSHcBgb7p8Q8xitIkw0= > =gkEr > -END PGP SIGNATURE- > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
On 01/11/2018 03:55 AM, taii...@gmx.com wrote: I am curious of any intel insiders know if there will be microcode updates released for older intel CPU's (ex: sandy/ivybridge) and failing that, what can be done in regards to securing them from meltdown/spectre. Looks like they're available now. Has anyone tested them yet? https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File smime.p7s Description: S/MIME Cryptographic Signature -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
Am 14.03.2018 22:46 schrieb David Hobach: On 01/11/2018 03:55 AM, taii...@gmx.com wrote: I am curious of any intel insiders know if there will be microcode updates released for older intel CPU's (ex: sandy/ivybridge) and failing that, what can be done in regards to securing them from meltdown/spectre. Looks like they're available now. Has anyone tested them yet? https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File I have. I have the relevant patchset up for review: https://review.coreboot.org/#/c/blobs/+/23315/ and currently always apply it on top of my coreboot build (for the Thinkpad X230 in my case; has then revision "1f" and verified functionality using https://github.com/speed47/spectre-meltdown-checker or similar tools) martin -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
So you are saying that sandy and ivybridge have spectre microcode updates? I hate how unclear intel is about this. How do I patch my coreboot? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
> So you are saying that sandy and ivybridge have spectre microcode > updates? > > I hate how unclear intel is about this. https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf -- Merlin Büge -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
Am 20.03.2018 00:15 schrieb taii...@gmx.com: So you are saying that sandy and ivybridge have spectre microcode updates? I hate how unclear intel is about this. How do I patch my coreboot? Like I said, the update is here for anybody to cherry-pick and test: https://review.coreboot.org/#/c/blobs/+/23315/ I expect this change to be merged sometime "soon", when reviewed. Yes, they even updated sandybridge and ivybridge. (For those, you only need the first of those 4 patches) Intel doesn't seem to care about informing users directly, at least this time around. They've worked with and for their "industry partners" and have left packaging updates to BIOS vendors. In the end we have a full release from Intel again though, so we're happy at last :) martin -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
On 03/20/2018 04:17 AM, Martin Kepplinger wrote: Yes, they even updated sandybridge and ivybridge. (For those, you only need the first of those 4 patches) There are some of the last released high end xeon/core 771/775 CPU's getting updates in the future too. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
Yeah I tried that but it didn't work. git fetch https://review.coreboot.org/blobs refs/changes/15/23315/6 && git cherry-pick FETCH_HEAD warning: no common commits remote: Counting objects: 555, done remote: Finding sources: 100% (30/30) remote: Total 1426 (delta 1), reused 1418 (delta 1) Receiving objects: 100% (1426/1426), 13.30 MiB | 4.21 MiB/s, done. Resolving deltas: 100% (396/396), done. From https://review.coreboot.org/blobs * branch refs/changes/15/23315/6 -> FETCH_HEAD error: could not apply 4f04985590... cpu: intel: microcode update for currently tracked models to 20180312 hint: after resolving the conflicts, mark the corrected paths hint: with 'git add ' or 'git rm ' hint: and commit the result with 'git commit What do I do now? I have never used git before. These patches need to be added stat - the stakes are too high for this to take months. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
On 20.03.2018 22:25, taii...@gmx.com wrote: > Yeah I tried that but it didn't work. > > git fetch https://review.coreboot.org/blobs refs/changes/15/23315/6 && > git cherry-pick FETCH_HEAD > > warning: no common commits > remote: Counting objects: 555, done > remote: Finding sources: 100% (30/30) > remote: Total 1426 (delta 1), reused 1418 (delta 1) > Receiving objects: 100% (1426/1426), 13.30 MiB | 4.21 MiB/s, done. > Resolving deltas: 100% (396/396), done. > From https://review.coreboot.org/blobs > * branch refs/changes/15/23315/6 -> FETCH_HEAD > error: could not apply 4f04985590... cpu: intel: microcode update for > currently tracked models to 20180312 > hint: after resolving the conflicts, mark the corrected paths > hint: with 'git add ' or 'git rm ' > hint: and commit the result with 'git commit > > What do I do now? I have never used git before. It's probably easier for you if you load the microcode update from your OS. > > These patches need to be added stat You obviously have no idea what you are talking about. AFAIK, nobody who has the right to submit to the blobs repository has commented yet on newer microcode updates or was asked personally if this is acceptable. You might have noticed that microcode updates are not public domain but licensed. > - the stakes are too high for this > to take months. You still didn't get what Spectre is about, did you? It's just one of many side-channel attacks that are possible when you run untrusted code on your machine. These updates just help with one instance of a much bigger problem and won't magically make your computer (and the software you run) secure. Have a look at [1] or uMatrix. These are much better mitigations, IMHO. But if you are really security concerned you already know that anyway. Nico [1] https://noscript.net/ -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
On 03/20/2018 06:14 PM, Nico Huber wrote: >> These patches need to be added stat > You obviously have no idea what you are talking about. What makes you say that? > AFAIK, nobody who has the right to submit to the blobs repository has > commented yet on > newer microcode updates or was asked personally if this is acceptable. > You might have noticed that microcode updates are not public domain but > licensed. Almost every linux distro redistributes them without issue and intel is suppository a coreboot contributor (to which I have been reminded of multiple times) I don't see as to how that is something that can't be worked around by asking people to download it themselves from a browser or making a shell script that imports intel's EULA and asks the user to agree to it before downloading it when they compile coreboot. Other microcode updates are included coreboot so are a variety of ME images and other binary blobs from intel so I fail to see the distinction here. >> - the stakes are too high for this to take months. > You still didn't get what Spectre is about, did you? I do. > It's just one of many side-channel attacks that are possible when you run > untrusted code on your machine. The whole point of a VM is that you are able to run untrusted code with some decent level of isolation and spectre ruins this. What other exploits exist which can easily read data from a VM's host? If there is a fixable problem why not fix it? The idea that the only way to go about things is to trust all the code that runs on your computer is backwards and unrealistic as even if you only ran foss programs on a modern linux you still have millions of lines of un-audited code loaded with exploits. > These updates just help with one instance of a much bigger problem and won't > magically make your computer (and the software you run) secure. Yes obviously but this is saying that because you can't be fully secure you shouldn't bother with anything at all. > Have a look at [1] or uMatrix. These are much better mitigations, IMHO. > But if you are really security concerned you already know that anyway. That wasn't the question and I don't appreciate replies like this. Should firmware programmers be the only ones using coreboot? I have patched my kernel and various other programs before but I have no reason to use git and I couldn't figure this out myself. If you were a sysadmin for a large company would you tell them to not bother applying the spectre mitigations? should their users use umatrix instead and that anyone who accidentally enables a site with encryption key/password stealing malicious javascript gets fired? Enabling javascript on a per site basis is like playing minesweeper - eventually you will step on a mine no matter how careful you are. I have to use javascript for many websites I need which is why I have a browser in a VM just for them but I don't want them to be able to be able to read host memory or the memory of other VM's. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
On 21.03.2018 00:03, taii...@gmx.com wrote: > On 03/20/2018 06:14 PM, Nico Huber wrote: > >>> These patches need to be added stat >> You obviously have no idea what you are talking about. > What makes you say that? You. You seem to rate the convenience to have a binary in the blobs repository higher than possible redistribution issues. Though, we might have a simple misunderstanding here. I now realized that you were trying to cherry-pick that commit into a different re- pository. This thread is about a change to the blobs repository which is independent of the coreboot source repository and has different rules. Anyway, I wasn't telling not to fix it, I was just offended by the way you want to fix it and your arrogance. You can mitigate Spectre in many ways. These microcode updates are just part of one way. And putting them into coreboot is just one way to apply them. And having them in the blobs repository is just for convenience. Yet, you claimed the lat- ter must happen. >> AFAIK, nobody who has the right to submit to the blobs repository has >> commented yet on >> newer microcode updates or was asked personally if this is acceptable. >> You might have noticed that microcode updates are not public domain but >> licensed. > Almost every linux distro redistributes them without issue and intel is > suppository a coreboot contributor (to which I have been reminded of > multiple times) The files are explicitly distributed by Intel for Linux distributors, we are not a Linux distributor. And, FWIW, Intel hasn't ever contributed to our blobs repository. > I don't see as to how that is something that can't be worked around by > asking people to download it themselves from a browser or making a shell > script that imports intel's EULA and asks the user to agree to it before > downloading it when they compile coreboot. You are already free to add any microcode update to coreboot you want. And we kind of ask people by prompting during coreboot configuration. Not every license is an EULA btw. > > Other microcode updates are included coreboot so are a variety of ME > images and other binary blobs from intel so I fail to see the > distinction here. Yep, but they were submitted a long time ago. And that stopped at some point. I don't know yet if due to licensing issues or just because it's more convenient for Google to maintain their own, hidden blobs repo. >>> - the stakes are too high for this to take months. >> You still didn't get what Spectre is about, did you? > I do. >> It's just one of many side-channel attacks that are possible when you >> run untrusted code on your machine. > The whole point of a VM is that you are able to run untrusted code with > some decent level of isolation and spectre ruins this. So does Rowhammer, any caching related side-channel attacks, hyper- threading related side-channel attacks, I don't know maybe more. These attacks exist and are possible, some may be more complicated than Spectre but most of all: They are not as popular as Spectre. > What other exploits exist which can easily read data from a VM's host? Sorry, easily? Even a Spectre attack isn't that easy. It depends a lot on the code around your VM (no matter the microcode updates in ques- tion). You can make it secure against Spectre even without these micro- code updates. > If you were a sysadmin for a large company would you tell them to not > bother applying the spectre mitigations? should their users use umatrix > instead and that anyone who accidentally enables a site with encryption > key/password stealing malicious javascript gets fired? Enabling > javascript on a per site basis is like playing minesweeper - eventually > you will step on a mine no matter how careful you are. Good analogy, you are right. No matter how careful you are, you may get powned at some point. But what you suggest doesn't seem much better, trigger all mines you can spot all day with a gas mask on that only protects you against one kind of mines that hasn't been spotted yet in the wild. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
Am 21.03.2018 11:13 schrieb Nico Huber: On 21.03.2018 00:03, taii...@gmx.com wrote: On 03/20/2018 06:14 PM, Nico Huber wrote: These patches need to be added stat You obviously have no idea what you are talking about. What makes you say that? You. You seem to rate the convenience to have a binary in the blobs repository higher than possible redistribution issues. Though, we might have a simple misunderstanding here. I now realized that you were trying to cherry-pick that commit into a different re- pository. This thread is about a change to the blobs repository which is independent of the coreboot source repository and has different rules. Anyway, I wasn't telling not to fix it, I was just offended by the way you want to fix it and your arrogance. You can mitigate Spectre in many ways. These microcode updates are just part of one way. And putting them into coreboot is just one way to apply them. And having them in the blobs repository is just for convenience. Yet, you claimed the lat- ter must happen. AFAIK, nobody who has the right to submit to the blobs repository has commented yet on newer microcode updates or was asked personally if this is acceptable. You might have noticed that microcode updates are not public domain but licensed. Almost every linux distro redistributes them without issue and intel is suppository a coreboot contributor (to which I have been reminded of multiple times) The files are explicitly distributed by Intel for Linux distributors, we are not a Linux distributor. And, FWIW, Intel hasn't ever contributed to our blobs repository. I don't see as to how that is something that can't be worked around by asking people to download it themselves from a browser or making a shell script that imports intel's EULA and asks the user to agree to it before downloading it when they compile coreboot. You are already free to add any microcode update to coreboot you want. And we kind of ask people by prompting during coreboot configuration. Not every license is an EULA btw. Other microcode updates are included coreboot so are a variety of ME images and other binary blobs from intel so I fail to see the distinction here. Yep, but they were submitted a long time ago. And that stopped at some point. I don't know yet if due to licensing issues or just because it's more convenient for Google to maintain their own, hidden blobs repo. FWIW, my understanding is that Intel *calls* this microcode release "Linux". Nothing in the license text refers to Linux or Linux distributors. In principal it is distributable. The relevant OEM part of the license basically says * only use with Intel CPUs, only under this license * don't reverse engineer * only distribute in conjunction with a "written license aggreement" like a "break-the-seal license" to "safeguard Intel's ownership rights". That last part may indeed be tricky. Other than that, it may be good to include the license text in the blobs repo directly. IANAL, but coreboot might not be compliant indeed now. I can imagine *some* way of achieving compliance like a prominent statement with "press any key" during the build process though. Coreboot should (only) care about *it's* users and pass on this license to them (distributors or whoever, who then can deal with it too). In short: We can greatly improve the situation quite easily, and probably should do so. Thanks for bringing this up. - the stakes are too high for this to take months. You still didn't get what Spectre is about, did you? I do. It's just one of many side-channel attacks that are possible when you run untrusted code on your machine. The whole point of a VM is that you are able to run untrusted code with some decent level of isolation and spectre ruins this. So does Rowhammer, any caching related side-channel attacks, hyper- threading related side-channel attacks, I don't know maybe more. These attacks exist and are possible, some may be more complicated than Spectre but most of all: They are not as popular as Spectre. What other exploits exist which can easily read data from a VM's host? Sorry, easily? Even a Spectre attack isn't that easy. It depends a lot on the code around your VM (no matter the microcode updates in ques- tion). You can make it secure against Spectre even without these micro- code updates. If you were a sysadmin for a large company would you tell them to not bother applying the spectre mitigations? should their users use umatrix instead and that anyone who accidentally enables a site with encryption key/password stealing malicious javascript gets fired? Enabling javascript on a per site basis is like playing minesweeper - eventually you will step on a mine no matter how careful you are. Good analogy, you are right. No matter how careful you are, you may get powned at some point. But what you suggest doesn't seem much better, trigger all mines you can spot all day with a gas mask on that only protects you
