linux-kernel - Re: Avoid speculative indirect calls in kernel

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

Date:   Thu, 4 Jan 2018 01:59:20 +0000
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andi Kleen <andi@...stfloor.org>, tglx@...uxtronix.de,
        Greg Kroah-Hartman <gregkh@...ux-foundation.org>,
        dwmw@...zon.co.uk, Tim Chen <tim.c.chen@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Dave Hansen <dave.hansen@...el.com>
Subject: Re: Avoid speculative indirect calls in kernel

> But then, exactly because the retpoline approach adds quite some cruft
> and leaves something to be desired, why even bother?  Intel has also

Performance

> Also, according to Google the KVM PoC can be broken simply by clearing
> the registers on every exit to the hypervisor.  Of course it's just
> mitigation, but perhaps _that_ is where we should start fixing the
> user/kernel boundary too.

The syscall boundary isn't quite that simple and clearing registers make
things harder but not impossible. It's a good hardening exercise as are
things like anding the top bit off userspace addresses on x86 64bit so
that even if someone speculates through a user copy they get to steal
their own data.

Other hardening possibilities include moving processes between cores,
yielding to another task for a bit or clearing L1 data if a syscall
returns an error, running only processes for the same uid on hyperthreaded
pairs/quads (more easy to do with VMs and something some cloud folk kind
of do anyway so that you more clearly get what you pay for in CPU time)
etc

Buffer overruns went from fly swatting, through organized analysis,
hardening, tools, better interfaces and language changes. History usually
repeats itself.

But absolutely - yes we should be looking at effective hardening
mechanisms in the kernel just as people will be in the hardware.

Alan