Re: Meltdown – Spectre

[Baho Utot]

On 1/8/2018 12:15 PM, Fernando Apesteguía wrote:
> 
> 
> On Mon, Jan 8, 2018 at 1:53 PM, Baho Utot <baho-utot at columbus.rr.com 
> <mailto:baho-utot at columbus.rr.com>> wrote:
>  >
>  >
>  > On 1/8/2018 7:37 AM, Aryeh Friedman wrote:
>  >>
>  >>
>  >>
>  >> On Mon, Jan 8, 2018 at 7:28 AM, Baho Utot <baho-utot at columbus.rr.com 
> <mailto:baho-utot at columbus.rr.com>
>  >> <mailto:baho-utot at columbus.rr.com 
> <mailto:baho-utot at columbus.rr.com>>> wrote:
>  >>
>  >>
>  >>
>  >> On 1/8/2018 4:15 AM, Aryeh Friedman wrote:
>  >>
>  >> On Mon, Jan 8, 2018 at 3:57 AM, Matthias Apitz <guru at unixarea.de 
> <mailto:guru at unixarea.de>
>  >> <mailto:guru at unixarea.de <mailto:guru at unixarea.de>>> wrote:
>  >>
>  >> As I side note, and not related to FreeBSD: My Internet
>  >> server is run by
>  >> some webhosting company (www.1blu.de <http://www.1blu.de> 
> <http://www.1blu.de>),
>  >>
>  >> they use Ubuntu servers and since
>  >> yesterday they have shutdown SSH access to the servers
>  >> argumenting that
>  >> they want
>  >> protect my (all's) servers against attacks of Meltdown and
>  >> Spectre.
>  >>
>  >> Imagine, next time we have to shutdown all IOT gadgets...
>  >>
>  >>
>  >>
>  >> Not always possible for things like medical test
>  >> equipment/devices. For
>  >> example I maintain a specialized EMR for interacting with Dr.
>  >> prescribed
>  >> remote cardiac monitors. Having those off line is not an
>  >> option since
>  >> they are used to detect if the patient needs something more
>  >> serious like a
>  >> pace maker (also almost always a IoT device these days) surgery.
>  >>
>  >> The actual monitoring is done on Windows and was attacked by some
>  >> ransomeware via a bit coin miner that somehow installed it
>  >> self. Since
>  >> all the users claim that they don't read email/upload/download
>  >> executables
>  >> or any other of the known attack vectors this leaves something
>  >> like
>  >> Meltdown or Spectre. We have also detected issues on the
>  >> CentOS that has
>  >> the non-medical corporate site on it. The only machine left on
>  >> touched on
>  >> the physical server (running some bare metal virtualization
>  >> tool) is the
>  >> FreeBSD machine that runs the actual EMR we wrote.
>  >>
>  >> TL;DR -- It seems Linux and Windows already have issues with
>  >> these holes
>  >> but I have seen little to no evidence that FreeBSD (when run as
>  >> a host).
>  >> In general when ever any virtualization issue (like the bleed
>  >> through on
>  >> Qemu last year) comes up FreeBSD is the one OS that seems to be
>  >> immune
>  >> (thanks to good design of the OS and bhyve). This is the main
>  >> reason why
>  >> I chose FreeBSD over Linux as the reference host for PetiteCloud.
>  >>
>  >>
>  >> This is not operating system specific, read the papers on theses
>  >> two. it attacks the cpu, usally through a JIT
>  >>
>  >>
>  >> Please learn a little OS design theory before making insane claims.
>  >> Specifically it *ONLY* effects OS's that rely on the specific CPU
>  >> architecture (vs. a generic one). Namely if you strictly partition 
> the page
>  >> table between userland and kernel space (which xxxBSD has always 
> done and
>  >> Linux has not) and don't use any CPU specific instructions to do so 
> (except
>  >> for protected vs. unprotected mode in the original 386 design 
> FreeBSD does
>  >> not do this while yet again microslut and linux do).
>  >>
>  >> For more info go read the more technical thread then here in 
> -hackers@ and
>  >> -current at .
>  >
>  >
>  >
>  > Go read the papers Spectre and Meltdown.
>  > This attacks Intel and Arm processors, AMD processors seems to not 
> have the
>  > issue. Intel is issuing new firmware for their processors.
>  > Why is does then Apple have the problem as well?
> 
> About AMD, they seem to be affected by at least two variants of these 
> attacks:
> 
> https://www.amd.com/en/corporate/speculative-execution
> 

Variant One 	Bounds Check Bypass 	Resolved by software / OS
					updates to be made available by
					system vendors and
					manufacturers. Negligible
					performance impact expected.

Variant Two 	Branch Target Injection 	Differences in AMD
						architecture mean there
						is a near zero risk of
						exploitation of this
						variant. Vulnerability
						to Variant 2 has not
						been demonstrated on AMD
						processors to date.

Variant Three 	Rogue Data Cache Load 	Zero AMD vulnerability due to
					AMD architecture differences.

For Variant 1 OS fix

For Variant 2 and 3 ZERO to near ZERO risk

So yes my statement stands