linux-kernel - Re: proposal for meltdown-workaround with low overhead

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e6abec223ca77903615456ab203bd12b@physik.tu-berlin.de>
Date:   Fri, 05 Jan 2018 11:24:01 +0100
From:   Alexander Kleinsorge <aleks@...sik.tu-berlin.de>
To:     Tony Luck <tony.luck@...il.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: proposal for meltdown-workaround with low overhead

Hi Tony,

at least in the original Paper ( meltdownattack.com/meltdown.pdf ) and 
in Wikipedia ( en.wikipedia.org/wiki/Meltdown_(security_vulnerability) ) 
indicate, that the exception variant is the preferred choice (even if it 
is also possible via branch prediction bending).
(I assume, that the exception variant is faster than the branch 
prediction one.)

> "Hence there are no exceptions at all. " // Tony
--> Actually there are 2 variants: with and without exception! , while 
the paper seems to tend to the exception one.
Perhaps splitting the 2 variants helps to find different (but more 
specific and therefore easier) solutions for each of both.
At least the exception variant could be handled without any significant 
performance loss (inside the OS exception handler only).

If Kernel would restrict high frequent forks or memory exceptions by 
same user again+again, at least one variant is not a problem any more.
And even if we only slowed down this or any future attack, this is 
already an improvement (at tiny implementation effort and no performance 
cost).

meltdown.pdf :
Listing 1 "1 raise_exception(); 2 // the line below is never reached; 3 
access(probe_array[data * 4096]);"
Figure 5: The Meltdown attack uses exception handling or suppression ..
Listing 2: The core instruction sequence of Meltdown.
An inaccessible kernel address is moved to a register,
raising an exception. The subsequent instructions are
already executed out of order before the exception is
raised, leaking the content of the kernel address through
the indirect memory access.

en.wikipedia.org :
"(this should be done with arithmetic instructions rather than branches 
to avoid the branch predictor complicating matters)"
"and only annul their effects when the memory protection fault gets 
detected some clock cycles later."
"So after the memory protection fault (which can be handled by a signal 
handler, or allowed to crash the process if the attacker has previously 
forked another process sharing the address space, or suppressed 
altogether if the read attempt in step 2 is itself only speculative)"

Thanks for further comments,
Alexander

Am 2018-01-05 00:09, schrieb Tony Luck:
> On Thu, Jan 4, 2018 at 11:45 AM, Alexander Kleinsorge
> <aleks@...sik.tu-berlin.de> wrote:
>> As Meltdown-Issue depends on allowing to cause many exceptions 
>> (usually :
>> accessing an invalid address), we could restrict this misusage easy.
> 
> The accesses to the invalid address are performed speculatively by the 
> CPU in
> a code branch that is later found to be not taken. Hence there are no 
> exceptions
> at all.
> 
> -Tony