linux-kernel - 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-next>] [day] [month] [year] [list]

Date:   Thu, 4 Jan 2018 20:45:36 +0100
From:   Alexander Kleinsorge <aleks@...sik.tu-berlin.de>
To:     linux-kernel@...r.kernel.org
Subject: 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