From owner-freebsd-arch@freebsd.org  Sat Jan  6 16:12:11 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 E6188EBFEEF;
 Sat,  6 Jan 2018 16:12:11 +0000 (UTC)
 (envelope-from eric@metricspace.net)
Received: from mail.metricspace.net (mail.metricspace.net
 [IPv6:2001:470:1f11:617::107])
 by mx1.freebsd.org (Postfix) with ESMTP id C075D74AE8;
 Sat,  6 Jan 2018 16:12:11 +0000 (UTC)
 (envelope-from eric@metricspace.net)
Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown
 [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client did not present a certificate) (Authenticated sender: eric)
 by mail.metricspace.net (Postfix) with ESMTPSA id 202868C54;
 Sat,  6 Jan 2018 16:12:11 +0000 (UTC)
Subject: Re: Fwd: A more general possible meltdown/spectre countermeasure
To: Wojciech Puchar <wojtek@puchar.net>
Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org>,
 "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
References: <c98b7ac3-26f0-81ee-2769-432697f876e5@metricspace.net>
 <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net>
 <alpine.BSF.2.20.1801061701200.40627@puchar.net>
From: Eric McCorkle <eric@metricspace.net>
Message-ID: <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net>
Date: Sat, 6 Jan 2018 11:12:10 -0500
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <alpine.BSF.2.20.1801061701200.40627@puchar.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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 16:12:12 -0000

On 01/06/2018 11:07, Wojciech Puchar wrote:
> sorry for stupid question but for my understanding these attacks works
> as below:
> 
> 1) perform access to byte not allowed virtual address and use next
> instruction to store relative to private space so cache is filled
> depending on value that one shouldn't be able to access.
> 
> 2) as kernel get trap on access violation it will generate SIGSEGV or
> SIGBUS which is directed by application using signal(2) so it can be
> ignored.
> 
> 3) other part of code perform some timing magic and detects this way
> where cache is filled - so byte  value can be guessed properly.
> 
> 
> My question is - why simply any access attempts to kernel space cannot
> generate SIGKILL? Of course it would harm program development, but as
> today developers doesn't usually use timesharing machine but have
> private computers, simple sysctl variable would suffice.

I'd thought of this myself.  The problem is that the cache effects could
still be observed by another process.

While is doesn't defeat the attack, tt does still complicate attacks, so
I think it's worth considering.