From owner-freebsd-questions@freebsd.org Mon Jan 8 17:37:10 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 678D9E79C7A for ; Mon, 8 Jan 2018 17:37:10 +0000 (UTC) (envelope-from baho-utot@columbus.rr.com) Received: from cdptpa-cmomta01.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F13063F8C for ; Mon, 8 Jan 2018 17:37:09 +0000 (UTC) (envelope-from baho-utot@columbus.rr.com) Received: from raspberrypi.bildanet.com ([65.186.67.174]) by cmsmtp with ESMTP id YbIJeBSl0U2piYbIMei6Y5; Mon, 08 Jan 2018 17:33:10 +0000 Received: from [192.168.1.143] by raspberrypi.bildanet.com with esmtp (Exim 4.84) (envelope-from ) id 1eYbM8-0000zr-O3; Mon, 08 Jan 2018 17:37:04 +0000 Subject: =?UTF-8?Q?Re:_Meltdown_=e2=80=93_Spectre?= To: =?UTF-8?Q?Fernando_Apestegu=c3=ada?= Cc: Aryeh Friedman , User Questions References: <3AECDC7F-8838-4C09-AC7F-117DFBAA326C@sigsegv.be> <20180108085756.GA3001@c720-r314251> <48211515-cc6b-522b-ccd2-4d0c1f6a2072@columbus.rr.com> <44279dcb-7b15-865a-ca71-938b3832d0e7@columbus.rr.com> From: Baho Utot Message-ID: Date: Mon, 8 Jan 2018 12:36:59 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfKZJVqmw8E/bFB8ak0QDi5tBItWWo2henEAeQAMGNMlDVCCla0BMJCjHpKi9Xipf9J2s2bbsamfU/rQfbzFlJK4NdQDec+H8TGZCGpOg/0FR70KvO5i/ NcD/scTyicZxPcCqj9NsuQxFgltsQJN/X+Ba5g2K/2GFiFeWqY0XP+scDrWMvLV0zrFnLtwlrfIgsefDQkf67cG1jN4IieWlgEAAZN8e0iIEewDQmNio1tsr aXCsStpNQ8/OgxWoj6mTOKz3Ydkc5EYW4MACgPM3N+a4AK9Kc+NcpxBAIpBIyHEq X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 17:37:10 -0000 On 1/8/2018 12:15 PM, Fernando Apesteguía wrote: > > > On Mon, Jan 8, 2018 at 1:53 PM, Baho Utot > wrote: > > > > > > On 1/8/2018 7:37 AM, Aryeh Friedman wrote: > >> > >> > >> > >> On Mon, Jan 8, 2018 at 7:28 AM, Baho Utot > >> >> wrote: > >> > >> > >> > >> On 1/8/2018 4:15 AM, Aryeh Friedman wrote: > >> > >> On Mon, Jan 8, 2018 at 3:57 AM, Matthias Apitz > >> >> wrote: > >> > >> As I side note, and not related to FreeBSD: My Internet > >> server is run by > >> some webhosting company (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@. > > > > > > > > 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