From owner-freebsd-questions@freebsd.org Mon Jan 8 17:15:49 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 6957CE78A07 for ; Mon, 8 Jan 2018 17:15:49 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4BAA3887 for ; Mon, 8 Jan 2018 17:15:48 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id w23so2711908lfd.11 for ; Mon, 08 Jan 2018 09:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eGTw6dvYqXVcwdQzbKoF7TBahtMSVQrMVeW+0jFaDpQ=; b=I9PkOZBgg2hyvA08nbAuS1QALeuPlm/y79bobnXjQB4MYgTODO2oP198+sOd3Qm3Ze 3RYApI1Y/nfVU/4KET48SGeK6omSjkc0B7xZ1hPBvOkKswq83hKWH7DiZDeuwnXFKaCl crXXO5CakkXwnK2FLQdPTN2unp6hIRJq3BPr15KQ37wb76ywBG7BPTtsGDlTLAimGZh/ vveBMFIV7ykH4thNPpvGZI359LjetHfxEvyB92TRp/OtGUP5R1xDk/WSuWm0pFkgkfug Cubdz1GBVbeElIbTXSbTTbVsUzlfoMmkSVy4nhn8fe4r9qotdnbOWU+WfvWWKvEI8UNV pC7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eGTw6dvYqXVcwdQzbKoF7TBahtMSVQrMVeW+0jFaDpQ=; b=DTRxSnW//xZwY/tKQ5BIq1g3TKsbbehIzVSwEr6u5IF0Tgt9zxFDb9IAXSw+NyDMED sHz1TNalicIHKJfEzDs55LPx5BYAxCFTv1nbpVD91FmaVBvg41Tf3/ZBReJ2OZOPz9TD HakEV+XCND+4GVQDcsvxdnqnC3dxH+m53YkJ8lSJUhIeT+iZBwoZX9o35ocuewfblmDc mfELkGgvlEwOsh5iVAL/u8cpxapwVtTGHYFSZfpXRx8o1nzpPA+CPs42HMBgeflwpbwn ac2XlmQyLlRj70kM8jDZIPsLi7F+y+XTD46mFUMB4np50Fn/j3UE/GbjVwHqwR2+snBa T3fA== X-Gm-Message-State: AKwxytfHD0r8en2UCTRsmQ0JOGRRham3KRdJ8oobNUCcRQ888tjp8D2h X5rrtTCe6dpTD9uLuboTJ3dUYpbfyMbUd9kltWI= X-Google-Smtp-Source: ACJfBovqHwl8cE61EsjfCZPB37oX3WxEVk4mcCUqRaFTac00FhDyeaAl/okaiVhPjemMMQd8gWmpnriiXHuM+OQsoJo= X-Received: by 10.25.216.90 with SMTP id p87mr6446240lfg.11.1515431746717; Mon, 08 Jan 2018 09:15:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.19.219 with HTTP; Mon, 8 Jan 2018 09:15:45 -0800 (PST) Received: by 10.25.19.219 with HTTP; Mon, 8 Jan 2018 09:15:45 -0800 (PST) In-Reply-To: <44279dcb-7b15-865a-ca71-938b3832d0e7@columbus.rr.com> 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: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Mon, 8 Jan 2018 18:15:45 +0100 Message-ID: Subject: =?UTF-8?B?UmU6IE1lbHRkb3duIOKAkyBTcGVjdHJl?= To: Baho Utot Cc: Aryeh Friedman , User Questions Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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:15:49 -0000 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 an= d >> 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 Cheers > > 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=E2=80=99s > 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=E2=80=99s > 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=E2=80=99s 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=E2=80=99s operating > systems is memory isolation. Operating systems ensure > that user applications cannot access each other=E2=80=99s 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=E2=80=99s operating > systems is memory isolation. Operating systems ensure > that user applications cannot access each other=E2=80=99s 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. > > Your turn > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " freebsd-questions-unsubscribe@freebsd.org"