Re: Meltdown – Spectre

[Fernando Apesteguía]

On Mon, Jan 8, 2018 at 6:36 PM, Baho Utot <baho-utot at columbus.rr.com> wrote:
>
>
> 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

Sorry, I might have misunderstood. The statement was "AMD processors
seems to not have the issue".
But they acknowledge the issue. In variant 1 it exists and it is fixed
by OS (so if it is fixed, it means it affects AMD's processors), in
variant 2 exists (nearly zero is not zero), and in variant 3, yes, it
is not affected.

So it is kind of a 2/3 affected for AMD.

Cheers.

>
>