Date: Mon, 8 Jan 2018 11:10:12 -0600 From: Valeri Galtsev <galtsev@kicp.uchicago.edu> To: Baho Utot <baho-utot@columbus.rr.com>, Aryeh Friedman <aryeh.friedman@gmail.com> Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: =?UTF-8?Q?Re:_Meltdown_=e2=80=93_Spectre?= Message-ID: <aa4bd069-1e7a-c06a-118a-72fdbb311109@kicp.uchicago.edu> In-Reply-To: <44279dcb-7b15-865a-ca71-938b3832d0e7@columbus.rr.com> References: <f9cc484e-be92-7aff-52fe-38655e85dbaa@columbus.rr.com> <CAH78cDqPnOUGoU=6x-BiugnpjmjYcd=CZS3fSNaX5tq-Uvma7g@mail.gmail.com> <bc9ad15b-a718-b901-76fa-bc43ce0c1f1a@columbus.rr.com> <3AECDC7F-8838-4C09-AC7F-117DFBAA326C@sigsegv.be> <20180108085756.GA3001@c720-r314251> <CAGBxaXnSRwtS=mbdsePyKvyZjTpu1tvo2O61SW60yQfdDJH4gA@mail.gmail.com> <48211515-cc6b-522b-ccd2-4d0c1f6a2072@columbus.rr.com> <CAGBxaXm=6NbZ%2Bcz6WGB7YY7NT_%2BxOhdxb17ORTsQs5e7RvqKaQ@mail.gmail.com> <44279dcb-7b15-865a-ca71-938b3832d0e7@columbus.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/08/18 06:53, Baho Utot wrote: > > > On 1/8/2018 7:37 AM, Aryeh Friedman wrote: >> >> >> On Mon, Jan 8, 2018 at 7:28 AM, Baho Utot <baho-utot@columbus.rr.com >> <mailto:baho-utot@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@unixarea.de >> <mailto:guru@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>), >> 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? > > From the papaer > > Modern processors use branch prediction and speculative > execution to maximize performance. For example, if > the destination of a branch depends on a memory value > that is in the process of being read, CPUs will try guess > the destination and attempt to execute ahead. When the > memory value finally arrives, the CPU either discards or > commits the speculative computation. Speculative logic > is unfaithful in how it executes, can access to the victim’s > memory and registers, and can perform operations with > measurable side effects. > Spectre attacks involve inducing a victim to speculatively > perform operations that would not occur during > correct program execution and which leak the victim’s > confidential information via a side channel to the adversary. > This paper describes practical attacks that combine > methodology from side channel attacks, fault attacks, > and return-oriented programming that can read arbitrary > memory from the victim’s process. More broadly, the > paper shows that speculative execution implementations > violate the security assumptions underpinning numerous > software security mechanisms, including operating system > process separation, static analysis, containerization, > just-in-time (JIT) compilation, and countermeasures to > cache timing/side-channel attacks. These attacks represent > a serious threat to actual systems, since vulnerable > speculative execution capabilities are found in microprocessors > from Intel, AMD, and ARM that are used in billions > of devices. > > And: > > Abstract > The security of computer systems fundamentally relies > on memory isolation, e.g., kernel address ranges are > marked as non-accessible and are protected from user > access. In this paper, we present Meltdown. Meltdown > exploits side effects of out-of-order execution on modern > processors to read arbitrary kernel-memory locations > including personal data and passwords. Out-of-order > execution is an indispensable performance feature and > present in a wide range of modern processors. The attack > is independent of the operating system, and it does not > rely on any software vulnerabilities. Meltdown breaks > all security assumptions given by address space isolation > as well as paravirtualized environments and, thus, > every security mechanism building upon this foundation. > On affected systems, Meltdown enables an adversary to > read memory of other processes or virtual machines in > the cloud without any permissions or privileges, affecting > millions of customers and virtually every user of a > personal computer. We show that the KAISER defense > mechanism for KASLR [8] has the important (but inadvertent) > side effect of impeding Meltdown. We stress > that KAISER must be deployed immediately to prevent > large-scale exploitation of this severe information leakage. > > > One of the central security features of today’s operating > systems is memory isolation. Operating systems ensure > that user applications cannot access each other’s memories > and prevent user applications from reading or writing > kernel memory. This isolation is a cornerstone of our > computing environments and allows running multiple applications > on personal devices or executing processes of > multiple users on a single machine in the cloud. > On modern processors, the isolation between the kernel > and user processes is typically realized by a superviOne of the central > security features of today’s operating > systems is memory isolation. Operating systems ensure > that user applications cannot access each other’s memories > and prevent user applications from reading or writing > kernel memory. This isolation is a cornerstone of our > computing environments and allows running multiple applications > on personal devices or executing processes of > multiple users on a single machine in the cloud. > On modern processors, the isolation between the kernel > and user processes is typically realized by a supervisor > bit of the processor that defines whether a memory > page of the kernel can be accessed or not. The basic > idea is that this bit can only be set when entering kernel > code and it is cleared when switching to user processes. > This hardware feature allows operating systems to map > the kernel into the address space of every process and > to have very efficient transitions from the user process > to the kernel, e.g., for interrupt handling. Consequently, > in practice, there is no change of the memory mapping > when switching from a user process to the kernel > novel attack that allows overcoming memory isolation > completely by providing a simple way for any user process > to read the entire kernel memory of the machine it > executes on, including all physical memory mapped in > the kernel region. Meltdown does not exploit any software > vulnerability, i.e., it works on all major operating > systems. Instead, Meltdown exploits side-channel information > available on most modern processors, e.g., modern > Intel microarchitectures since 2010 and potentially > on other CPUs of other vendors. > > Notice: > > Meltdown does not exploit any software vulnerability, i.e., it works on > all major operating systems. Hi Baho, This above information aside, your logic somewhat escapes me. On one hand you are expecting kernel fix (are you?) which FreeBSD is working on (the sooner the better!). On the other hand you insist on conclusion that this trouble is independent on operating system, implying, FreeBSD is in the same level of danger than any other operating system. The truth may be somewhere in between. That is: yes, all systems as they are can potentially be impacted. However, depending on architecture, the impact may be different. Someone clever (with deeper knowledge of FreeBSD architecture and better insight into problem) may correct me here. The fact that FreeBSD still works on this problem whereas Microsoft and Linux kernel folks already released their patches to me speaks highly of FreeBSD. FreeBSD appears to do really thorough job. As example, I would mention this: Linux (CentOS aka "binary replica" of RedHat Enterprise) often after releasing kernel patch, releases second kernel patch 2-3 days later. Which makes all who maintain parks of Linux machines and patch them promptly reboot the machines twice in a course of few days. There are special cases sometimes, but mostly this is indication of not thorough enough work. I don't remember similar things happen to FreeBSD. This pretty much reminds me how someone concluded that ATI does more thorough work on drivers compared to NVIDIA, pointing to the fact that ATI releases drivers only twice a year, whereas NVIDIA has to constantly release drivers updates: Monthly. Just my $0.02 Valeri -- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aa4bd069-1e7a-c06a-118a-72fdbb311109>