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 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
Re: proposal for meltdown-workaround with low overhead
On Thu, 4 Jan 2018 15:09:28 -0800 Tony Luck wrote: > On Thu, Jan 4, 2018 at 11:45 AM, Alexander Kleinsorge > 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. Actually for the 'spectre' attack you can sometimes see hints because many of the obvious attack points end up causing a syscall to return an errno value. One thing that might be interesting for the paranoid is indeed to react to some of those (notably EINVAL, EFAULT) by stirring up the mud before that process runs again. Alan
Re: proposal for meltdown-workaround with low overhead
On Thu, Jan 4, 2018 at 11:45 AM, Alexander Kleinsorge 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
proposal for meltdown-workaround with low overhead
Hi all, This is my first post here and I hope it is fine. I will subscribe tomorrow to this list, so please take me in CC for answers now. As Meltdown-Issue depends on allowing to cause many exceptions (usually : accessing an invalid address), we could restrict this misusage easy. My rough proposal that should give an idea and some of them in combination should fix the problem. Of course root and a special new group could be excluded from these restrictions. But especially for JIT-Engine, we should be strict here inside exception handling code. The normal performance should not be affected, only exception handling (kernel OS part, not user part) a little. If an attack is detected (via counter threshold), prevent start new processes by this user (including forks), or stop/suspend this (or all existing?) process(es) of this user. 1. Limit the number of this exception kind by a per user counter, as I don't see a use case for normal operation to cause high frequent memory probes. (e.g. 1/sec and/or 100 since boot, or similar - configurable parameters perhaps) And if someone needs this, he needs to get the right for it (e.g. via new memory_exception_group). 2. Limit the fork count (similar to step 1). Especially JIT-users should not need (e.g.) >10 forks per sec (again configurable). 3. Perhaps memory transaction (variant) can also be handled somehow via a sufficieant delay after such exception (e.g. pausing all processes of same user for some sleep-ms). Depending on details, this slows down the attack sigificantly and can even completely prevent it (by hard counter limits for guests or unpriviliged users). Let's fight is from the other side. kind regards, Alexander
