linux-kernel - Re: [RFC][PATCH v2 00/21] x86/pti: Defer CR3 switch to C code

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:   Tue, 17 Nov 2020 17:55:39 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Alexandre Chartre <alexandre.chartre@...cle.com>
Cc:     tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
        x86@...nel.org, dave.hansen@...ux.intel.com, luto@...nel.org,
        peterz@...radead.org, linux-kernel@...r.kernel.org,
        thomas.lendacky@....com, jroedel@...e.de, konrad.wilk@...cle.com,
        jan.setjeeilers@...cle.com, junaids@...gle.com, oweisse@...gle.com,
        rppt@...ux.vnet.ibm.com, graf@...zon.de, mgross@...ux.intel.com,
        kuzuno@...il.com
Subject: Re: [RFC][PATCH v2 00/21] x86/pti: Defer CR3 switch to C code

On Tue, Nov 17, 2020 at 08:56:23AM +0100, Alexandre Chartre wrote:
> The main goal of ASI is to provide KVM address space isolation to
> mitigate guest-to-host speculative attacks like L1TF or MDS.

Because the current L1TF and MDS mitigations are lacking or why?

> Current proposal of ASI is plugged into the CR3 switch assembly macro
> which make the code brittle and complex. (see [1])
>
> I am also expected this might help with some other ideas like having
> syscall (or interrupt handler) which can run without switching the
> page-table.

I still fail to see why we need all that. I read, "this does this and
that" but I don't read "the current problem is this" and "this is our
suggested solution for it".

So what is the issue which needs addressing in the current kernel which
is going to justify adding all that code?

> PTI has a measured overhead of roughly 5% for most workloads, but it can
> be much higher in some cases.

"it can be"? Where? Actual use case?

> The latest ASI RFC (RFC v4) is here [1]. This RFC has ASI plugged
> directly into the CR3 switch assembly macro. We are working on a new
> implementation, based on these changes which avoid having to deal with
> assembly code and makes the implementation more robust.

This still doesn't answer my questions. I read a lot of "could be used
for" formulations but I still don't know why we need that. So what is
the problem that the kernel currently has which you're trying to address
with this?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette