Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities

[DJ Lucas]

On 01/08/2018 05:44 PM, Bruce Dubbs wrote:

DJ Lucas wrote:

I might be confused, but I thought microcode updates on consumer 
processors is handled by BIOS update from the motherboard 
manufacturer, the AGESA part of the BIOS version, currently 1.0.0.7. 
I'm not sure if we'll see a late-load .bin for the consumer 
processors. If anybody can confirm or deny, please speak up.


BLFS shows how to update the microcode in an initrd.  That's really just 
having the kernel do what the BIOS update would do.




Bruce, the AGESA comment is specific to AMD R5/R7 processors. They 
obviously intend to provide the files for at least Epyc. Nothing has 
surfaced yet for Ryzen or Threadripper outside of the BIOS updates.


--DJ


--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities

[DJ Lucas]

On 01/08/2018 03:12 PM, Michael Shell wrote:

On Sun, 7 Jan 2018 16:47:00 -0600
DJ Lucas  wrote:


I might be confused, but I thought microcode updates on consumer
processors is handled by BIOS update from the motherboard manufacturer,
the AGESA part of the BIOS version, currently 1.0.0.7. I'm not sure if
we'll see a late-load .bin for the consumer processors.



   DJ,

Given that a microcode update would apply to all processors of a given
type and given this is a security related matter, the chances are very
good that *somebody* will extract and "leak" the microcode files to
the public even if Intel/AMD does not (officially) do so >
IMHO, tis kind of silly of Intel/AMD to expect microcode updates to
come only by way of BIOS updates given how reluctantly motherboard
makers issue BIOS updates.



Agreed, however, it seems to be the case. AGESA (AMD Generic 
Encapsulated Software Architecture) is the working name. I suppose you 
can do so without a BIOS update, but somebody will have to either 
extract it, or break NDA (probably equally frowned upon in many 
jurisdictions).


--DJ

--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities

[Bruce Dubbs]

DJ Lucas wrote:

I might be confused, but I thought microcode updates on consumer 
processors is handled by BIOS update from the motherboard manufacturer, 
the AGESA part of the BIOS version, currently 1.0.0.7. I'm not sure if 
we'll see a late-load .bin for the consumer processors. If anybody can 
confirm or deny, please speak up.


BLFS shows how to update the microcode in an initrd.  That's really just 
having the kernel do what the BIOS update would do.


On my latest build (yesterday), I have:

menuentry 'LFS SVN-20180106 kernel 4.14.12' {
   linux   /vmlinuz-4.14.12-lfs-SVN-20180106 root=/dev/sda9 ro
   initrd  /microcode-06-5e-03.img
}
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities

[Michael Shell]

On Sun, 7 Jan 2018 16:47:00 -0600
DJ Lucas  wrote:

> I might be confused, but I thought microcode updates on consumer 
> processors is handled by BIOS update from the motherboard manufacturer, 
> the AGESA part of the BIOS version, currently 1.0.0.7. I'm not sure if 
> we'll see a late-load .bin for the consumer processors. 


  DJ,

Given that a microcode update would apply to all processors of a given
type and given this is a security related matter, the chances are very
good that *somebody* will extract and "leak" the microcode files to
the public even if Intel/AMD does not (officially) do so.

IMHO, tis kind of silly of Intel/AMD to expect microcode updates to
come only by way of BIOS updates given how reluctantly motherboard
makers issue BIOS updates.


   Cheers,

   Mike
 

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities

[Ken Moffat]

On Sun, Jan 07, 2018 at 04:47:00PM -0600, DJ Lucas wrote:
> 
> 
> I might be confused, but I thought microcode updates on consumer processors
> is handled by BIOS update from the motherboard manufacturer, the AGESA part
> of the BIOS version, currently 1.0.0.7. I'm not sure if we'll see a
> late-load .bin for the consumer processors. If anybody can confirm or deny,
> please speak up.
> 
In theory you can get a new BIOS/UEFI from the motherboard
manufacturer.  But linux has supported updating the microcode for a
long time (but you need to do it on every boot).  All my Intel
motherboards now load newer firmware than what is in the BIOS, but
of my AMDs only the oldest (Athlon64x2) has newer firmware available
from linux-firmware.

BLFS, Part II, Chapter 3, 'About Firmware'.

ĸen
-- 
Truth, in front of her huge walk-in wardrobe, selected black leather
boots with stiletto heels for such a barefaced truth.
 - Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities

[DJ Lucas]

On 01/07/2018 04:11 PM, Ken Moffat wrote:

On Fri, Jan 05, 2018 at 08:43:11PM -0500, Michael Shell wrote:

On Fri, 5 Jan 2018 17:26:13 +
Ken Moffat  wrote:


Does anybody have a link for (any) updated AMD firmware?  Ryzen is
model 17h, AFAICS linux firmware has nothing for that, and the
firmware for earlier models has not been updated in a long time.



I also sure would like a link to that if anyone here knows it. That
said, the Debian page for the AMD microcode is here:

https://packages.debian.org/sid/amd64-microcode

There is also a place on github where Linux related firmware is
distributed from. The AMD CPU microcode area of that is here:

https://github.com/wkennington/linux-firmware/tree/master/amd-ucode

But no updates since 2016 so far. Sigh.


If anybody has an EPYC[1], SuSe has a srpm - but it doesn't apply to
Ryzens, and the kerneli might need a patch because it had known
nothing about Ryzen microcode and tests against an old default size
(not sure which versions have that patch) - details at
https://bugs.archlinux.org/task/56951



Yes, I had seen this as well, but this is specific to Epyc.


Clearly this is aimed at Spectre.

I saw the kernel patch a while ago, which is why I was hopeful about
microcode.  But I don't even have a Ryzen so for me that part is
academic.

1. The server version of Zen, aimed at Data Centres, so I can
understand why that would get priority.


I might be confused, but I thought microcode updates on consumer 
processors is handled by BIOS update from the motherboard manufacturer, 
the AGESA part of the BIOS version, currently 1.0.0.7. I'm not sure if 
we'll see a late-load .bin for the consumer processors. If anybody can 
confirm or deny, please speak up.


--DJ

--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities

[Michael Shell]

On Fri, 5 Jan 2018 17:26:13 +
Ken Moffat  wrote:

> Does anybody have a link for (any) updated AMD firmware?  Ryzen is
> model 17h, AFAICS linux firmware has nothing for that, and the
> firmware for earlier models has not been updated in a long time.


I also sure would like a link to that if anyone here knows it. That
said, the Debian page for the AMD microcode is here:

https://packages.debian.org/sid/amd64-microcode

There is also a place on github where Linux related firmware is
distributed from. The AMD CPU microcode area of that is here:

https://github.com/wkennington/linux-firmware/tree/master/amd-ucode

But no updates since 2016 so far. Sigh.

The Intel area (in the github link) does not seem to carry anything for
CPUs. Intel's own distribution page for CPU microcode is here (tis the
same link Ken gave earlier):

https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File

"This microcode data file contains the latest microcode definitions
 for all Intel processors."

But, as Ken mentioned, it seems that the Debian page has versions more
recent than Intel has officially released. Sigh.

> Like you, I'm very wary of bios updates (I've bricked enough
> hardware over the years).



As long as it is for the correct motherboard, it should work. I've
upgraded motherboard BIOSes many times and doing so has allowed me to
overcome lots of annoyances. Just be sure and record any critical
settings before the update. Be prepared to have to reset your CMOS
settings (or even have them automatically reset by the update process
itself) and then reenter all your settings. One other thing, I never
use the "network BIOS update" feature found on many modern
motherboards. I always download the BIOS file manually and update
from that. Always be sure and get the correct one.

The bigger problem in my eyes is motherboard OEMs not creating/releasing
BIOS updates, especially for older hardware. Now, when they are motivated
enough to do so, it usually means something serious was fixed.

I've also become a fan of the linux flash utility flashrom:

https://www.flashrom.org/Flashrom

Although I have not yet used it to update a motherboard BIOS, it worked
great to update the BIOS on a SATA card. And it allows us to *save* a
copy of the flash rom contents before we overwrite it with an update.

Also, it's good to know that there are sellers on Ebay who are selling
BIOS chips in the $15 range. Do a search for 

BIOS chip yourmotherboard model

to see what's available. Some of these chips are plugin DIPs, but others
are SMT devices that will require the use of soldering skills to replace.
However, it's a venue that will allow you (or your local electronics
technician) an emergency means to unbrick.


IMHO, every firmware update-able device should carry two copies of its
firmware - one that is always read only and is forever fixed at the
factory and the other copy which can be updated by the user. This way,
if an update fails, a switch/jumper can be set to fallback to the OEM
firmware to allow booting so the second (writable) copy can be reflashed.
Also, there should be a second jumper that would force the second
(writable) copy to be read only as well. In this way, malware could be
kept out of firmware - all firmware updates locked out in hardware.





In anycase, from what I understand at present, the Meltdown/Spectre class
of bugs don't allow for things like arbitary code execution - they just
leak information. The spillage of the entire kernel memory area is most
troubling. But, even so, it should be tough for an attacker without shell
access to use that to gain root access. I think the biggest concern here
is for (shared) hosting companies and companies with public servers that
are handling sensitive information, not the normal desktop.

Lastly, IMHO, no application facing the outside world should ever allow
users to be able to craft and execute code at level low enough to permit
such exploits. I think such an ability is a security-related bug in and
of itself.



  Cheers,

  Mike

  
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities

[Ken Moffat]

On Fri, Jan 05, 2018 at 02:58:57AM -0500, Michael Shell wrote:
> 
> Most interesting, but also scary. Here's my own summary take on the info
> which I found at:
> 
[ snipping - people can, and should, follow the links in your original
post, but I've got a question on one item ]
> 
> There is, however, conflicting information when it comes to the AMD
> (Zen/Ryzen) CPUs and variant 2: 
> https://www.realworldtech.com/forum/?threadid=173741=173810
> 
> Suse and Red Hat have released a firmware/microcode update for the AMD 17h
> family (Zen). This new firmware claims to 
> 
>  " This new firmware disables branch prediction on AMD family 17h processor.
> 

Does anybody have a link for (any) updated AMD firmware ?  Ryzen is
model 17h, AFAICS linux firmware has nothing for that, and the
firmware for earlier models has not been updated in a long time.

>Also the CPU microcode for Intel Haswell-X, Skylake-X and Broadwell-X
>chipsets was updated to report both branch prediction control via CPUID
>flag and ability to control branch prediction via an MSR register.
>  "
Ah, the high-end -X CPUs.  I'm still hopeful of seeing new intel
firmware, but the last comment I read on lkml last night was that it
had not been released yet.

I looked at RedHat updates, they are still using microcode_ctl and
the date of that was not recent.

ĸen
-- 
Truth, in front of her huge walk-in wardrobe, selected black leather
boots with stiletto heels for such a barefaced truth.
 - Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities

[Michael Shell]

On Thu, 4 Jan 2018 20:16:18 +
Ken Moffat  wrote:

> There are two vulnerabilities, with the shiny names of Meltdown and
> Spectre. Both refer to ways of userspace finding where the kernel
> has been mapped, to try to do harm. Page Table Isolation addresses
> the first of these. Google claim it affects some AMD processors,
> AMD deny this.


Most interesting, but also scary. Here's my own summary take on the info
which I found at:

http://www.tomshardware.com/news/meltdown-spectre-exploits-intel-amd-arm-nvidia,36219.html
https://wccftech.com/intel-affected-by-critical-kernel-bug-amd-hit/
https://overclock3d.net/news/cpu_mainboard/amd_releases_response_to_meltdown_and_spectre_exploits/
https://www.phoronix.com/scan.php?page=news_item=Linux-Tip-Git-Disable-x86-PTI
https://www.theregister.co.uk/2018/01/04/intel_amd_arm_cpu_vulnerability/

There are three variants of this new class of vulnerability which all
involve gaining illegal read access to memory:

Variant 1:
Bounds check bypass, aka "Spectre (Version 1)", CVE-2017-5753, 
Supposedly, is to be fixed within the kernel. It is promised to be an easy
and painless fix. Almost all modern processors are affected.

Variant 2:
Branch target injection, aka "Spectre (Version 2)", CVE-2017-5715
May require a CPU microcode update or recompiling all the applications
to fix. More mystery and conflicting info over this one than the other
variants. AMD claims vulnerability is "almost zero". The Zen family may
be an exception (see below).

Variant 3:
Rogue data cache load aka "Meltdown", CVE-2017-5754
The new Linux kernel Page Table Isolation (PTI) feature protects against
this exploit. All post-1995, except Itanium and pre-2013 Atom, Intel
CPUs and Arm Cortex-A15, Cortex-A57, Cortex-A72 and Cortex-A75 cores
are vulnerable. No AMD CPUs are vulnerable to variant 3.

From https://wccftech.com/intel-affected-by-critical-kernel-bug-amd-hit/
"Variant 1 is software [OS] patchable and affects almost all modern
 processors. The patch itself will have negligible performance hit.
 Variant 2 and 3 are rooted further in hardware and are not patchable
 by any known means of code. Attempting to patch these using software
 will result in performance hits and so far these only seem to affect
 Intel and ARM processors with near zero risk to AMD CPUs."


However, the above quote is a little misleading because the Linux kernel
Page Table Isolation (PTI) feature should be able to prevent Variant 3,
albeit with a load dependent performance penalty.

Tis real bad news for folks using Intel because Intel's processors are
impacted much more severely than those of AMD.

In particular, "it is said that Meltdown (Variant 3) has been tested
on all Intel processor generations since 2011, with 'effectively every
processor since 1995' being affected (with a few exceptions)".

AMD claims its processors are not vulnerable to Variant 3 (and the
upcoming Linux kernel releases will disable the PTI protection config
option by default for AMD processors), and that they have "near zero"
risk from variant 2 (but see below for evidence that Ryzen CPUs might
have an issue with variant 2).

Variant 1 affects almost all modern processors, including those of AMD,
and may require future hardware architecture changes to totally mitigate
without the need for OS patches/protection. However, AMD now claims it
has developed a patch (kernel or microcode level?) that "can mitigate
variant 1 with minimal performance impact."

From https://wccftech.com/intel-affected-by-critical-kernel-bug-amd-hit/
there were four proof of concept exploits that have been demonstrated:

 "During the course of our research, we developed the following proofs
  of concept (PoCs):

  1. A PoC that demonstrates the basic principles behind variant 1 in
 userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU,
 the AMD PRO CPU and an ARM Cortex A57. This PoC only tests for the
 ability to read data inside mis-speculated execution within the
 same process, without crossing any privilege boundaries.

  2. A PoC for variant 1 that, when running with normal user privileges
 under a modern Linux kernel with a distro-standard config, can
 perform arbitrary reads in a 4GiB range [3] in kernel virtual
 memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is
 enabled (non-default configuration), it also works on the AMD PRO
 CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be
 read at a rate of around 2000 bytes per second after around 4
 seconds of startup time.

  3. A PoC for variant 2 that, when running with root privileges inside
 a KVM guest created using virt-manager on the Intel Haswell Xeon
 CPU, with a specific (now outdated) version of Debian's distro kernel
 running on the host, can read host kernel memory at a rate of around
 1500 bytes/second, with room for optimization. Before the attack can
 be performed, some