Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Jan 2018 17:53:37 +0100 (CET)
From:      Wojciech Puchar <wojtek@puchar.net>
To:        Warner Losh <imp@bsdimp.com>
Cc:        Eric McCorkle <eric@metricspace.net>, Wojciech Puchar <wojtek@puchar.net>,  "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: Fwd: A more general possible meltdown/spectre countermeasure
Message-ID:  <alpine.BSF.2.20.1801061752540.46832@puchar.net>
In-Reply-To: <CANCZdfqZnZhKXD3SKgyro%2BYLX7j5BYrmCZ7xEGwYY6AWkQpKzg@mail.gmail.com>
References:  <c98b7ac3-26f0-81ee-2769-432697f876e5@metricspace.net> <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <alpine.BSF.2.20.1801061701200.40627@puchar.net> <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net> <CANCZdfqZnZhKXD3SKgyro%2BYLX7j5BYrmCZ7xEGwYY6AWkQpKzg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
>       While is doesn't defeat the attack, tt does still complicate attacks, so
>       I think it's worth considering.
> 
> 
> The problem is that the attempts to access kernel space are speculative. There's no way to get the 'speculative trap' that would
> have been generated had the code actually executed. There literally is no signal to the kernel this just happened.
> 
> Warner 
> 
> 
f..k. so there are no real workarounds. Anyway - if CPU companies would be 
honest they would replace at least all server CPUs that are on warranty
From owner-freebsd-arch@freebsd.org  Sat Jan  6 17:04:56 2018
Return-Path: <owner-freebsd-arch@freebsd.org>
Delivered-To: freebsd-arch@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 C3B38EC2596
 for <freebsd-arch@mailman.ysv.freebsd.org>;
 Sat,  6 Jan 2018 17:04:56 +0000 (UTC)
 (envelope-from wlosh@bsdimp.com)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com
 [IPv6:2607:f8b0:4001:c06::22c])
 (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 85C7077060
 for <freebsd-arch@freebsd.org>; Sat,  6 Jan 2018 17:04:56 +0000 (UTC)
 (envelope-from wlosh@bsdimp.com)
Received: by mail-io0-x22c.google.com with SMTP id k18so8869145ioc.11
 for <freebsd-arch@freebsd.org>; Sat, 06 Jan 2018 09:04:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bsdimp-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:sender:in-reply-to:references:from:date:message-id
 :subject:to:cc;
 bh=qxK6lHUIqiRkSC4De4cwFKYEOyQwjG9L2o6RG5K6ra4=;
 b=Bm3/brLnlFsGlX3cWd668tKRBgeXfyGd0Nxi8LZH0M2pJtmNueKSRgjX0WEpVmV12l
 DkDzwd7PmsxI2kCGotD8LYfsVylBbhNl3/DbCZy74U4VRCRRB3AVjKKadS7YK0FRhXDD
 S+In0OX1jtoFN1KbzafnqdIIbLm/5Jr6i/ysYALezZC2rGZmN4U+OTm09NrpfaQ0L9lS
 Lq8iJNPBVgUqmCkxagPxSW/Z125Z/1HlamI5vko3QUBSF9X4BWhjFYtcA6zcFXczA2AZ
 G04IOLy4tYIfvN6D59oaeBHQX29BVUIGaunAuIqhD/TIVAoEurOegvFAM6AMbN4McDfJ
 oayw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
 :date:message-id:subject:to:cc;
 bh=qxK6lHUIqiRkSC4De4cwFKYEOyQwjG9L2o6RG5K6ra4=;
 b=StM0G8BNwE8KRnzGe50N7WeYoB3h2j1GV9vewNaaCNdl41g7hlE5nykzczNrTO79x9
 LO3hKY7dQMtCF0VDTdvZGEPiRGekrphfSBRwYHrHA2wc7LFzcIQ+GyVeoRgD61+o9LMN
 c6oPDbQL2mGzB/Et8TaW11v6pVnhfihPtmvdFHWRWygUlWyfzkb0yna+LLpH5TRofrHv
 U/YTtVGPifwnny+cn0D0fpHBrfoBMiQvu9quVvittKUjqu0H0fsDKerfsBXa4HlG8Izb
 WSf6bLgLscVplxah8YlMcqnqjt45bz5XTZ75oXJKAithowG1TbfPHnBo9htGZYn0xx94
 fkMg==
X-Gm-Message-State: AKwxytcxBgQfkGpwEVAifU8O1+qDLCVUVD4mIlNpAKwFiyrPid65XbtX
 kcoPCdg1XxvIgCK3Urrq/zQdBxeRkHlWjukmsAwILw==
X-Google-Smtp-Source: ACJfBots7zwFP9w7ezasUUVZfZNLHrO8er3Sm5ib1lGQtE8vgsfs7WEl5LYD6cPFRhv3re/dmXN3DzXarhPu0UD8K0o=
X-Received: by 10.107.78.12 with SMTP id c12mr6337340iob.63.1515258295739;
 Sat, 06 Jan 2018 09:04:55 -0800 (PST)
MIME-Version: 1.0
Sender: wlosh@bsdimp.com
Received: by 10.79.160.217 with HTTP; Sat, 6 Jan 2018 09:04:54 -0800 (PST)
X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d]
In-Reply-To: <alpine.BSF.2.20.1801061752540.46832@puchar.net>
References: <c98b7ac3-26f0-81ee-2769-432697f876e5@metricspace.net>
 <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net>
 <alpine.BSF.2.20.1801061701200.40627@puchar.net>
 <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net>
 <CANCZdfqZnZhKXD3SKgyro+YLX7j5BYrmCZ7xEGwYY6AWkQpKzg@mail.gmail.com>
 <alpine.BSF.2.20.1801061752540.46832@puchar.net>
From: Warner Losh <imp@bsdimp.com>
Date: Sat, 6 Jan 2018 10:04:54 -0700
X-Google-Sender-Auth: 3xtImcXG0eoMSSyWTPVcuOIfNSU
Message-ID: <CANCZdfqsV1bUAmwVGHZZfBK2FQ_Y03WvHQuUtBOABHo6mbbYAA@mail.gmail.com>
Subject: Re: Fwd: A more general possible meltdown/spectre countermeasure
To: Wojciech Puchar <wojtek@puchar.net>
Cc: Eric McCorkle <eric@metricspace.net>, 
 "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, 
 "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>;
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jan 2018 17:04:56 -0000

On Sat, Jan 6, 2018 at 9:53 AM, Wojciech Puchar <wojtek@puchar.net> wrote:

>       While is doesn't defeat the attack, tt does still complicate
>> attacks, so
>>       I think it's worth considering.
>>
>>
>> The problem is that the attempts to access kernel space are speculative.
>> There's no way to get the 'speculative trap' that would
>> have been generated had the code actually executed. There literally is no
>> signal to the kernel this just happened.
>>
>> Warner
>>
>>
>> f..k. so there are no real workarounds. Anyway - if CPU companies would
> be honest they would replace at least all server CPUs that are on warranty


The only workaround that's completely effective is to unmap all of kernel
memory when running in userland. It's a bit tricky because there's small
parts that have to stay mapped for various architectural reasons. This
means KASLR on these CPUs likely can never be effective since meltdown will
let you find what the trap address is and from that find the kernel (though
there's some rumblings that the indirection Linux is doing will suffice).

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1801061752540.46832>