linux-kernel - Re: [PATCH 2/2] x86/tdx: Do not allow #VE due to EPT violation on the private memory

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:   Fri, 4 Nov 2022 15:36:09 -0700
From:   Erdem Aktas <erdemaktas@...gle.com>
To:     Dave Hansen <dave.hansen@...el.com>,
        "Nakajima, Jun" <jun.nakajima@...el.com>
Cc:     Guorui Yu <GuoRui.Yu@...ux.alibaba.com>,
        kirill.shutemov@...ux.intel.com, ak@...ux.intel.com, bp@...en8.de,
        dan.j.williams@...el.com, david@...hat.com,
        elena.reshetova@...el.com, hpa@...or.com,
        linux-kernel@...r.kernel.org, luto@...nel.org, mingo@...hat.com,
        peterz@...radead.org, sathyanarayanan.kuppuswamy@...ux.intel.com,
        seanjc@...gle.com, tglx@...utronix.de, thomas.lendacky@....com,
        x86@...nel.org
Subject: Re: [PATCH 2/2] x86/tdx: Do not allow #VE due to EPT violation on the
 private memory

On Fri, Oct 28, 2022 at 7:12 AM Kirill A. Shutemov
<kirill.shutemov@...ux.intel.com> wrote:

> +        *
> +        * Kernel has no legitimate use-cases for #VE on private memory. It is
> +        * either a guest kernel bug (like access of unaccepted memory) or
> +        * malicious/buggy VMM that removes guest page that is still in use.
> +        *

I think this statement is too strong and I have few concerns on this approach.
I understand that there is an issue of handling #VEs on private pages
but it seems like we are just hiding the problem with this approach
instead of fixing it - I do not have any fix in my mind- .
First there is a feature of injecting #VE to handle unaccepted pages
at runtime and accept them on-demand, now the statement is saying this
was an unnecessary feature (why is it there at all then?) at all as
there is no legitimate use case.

I wonder if this will limit how we can implement the lazy TDACCEPT.
There are multiple ideas floating now.
https://github.com/intel/tdx/commit/9b3ef9655b695d3c67a557ec016487fded8b0e2b
has 3 implementation choices where "Accept a block of memory on the
first use." option is implemented.  Actually it says "Accept a block
of memory on the first use." but it is implemented as "Accept a block
of memory on the first allocation".  The comments in this code also
raises concerns on the performance.

As of now, we do not know which one of those ideas will provide an
acceptable performance for booting large size VMs. If the performance
overhead is high, we can always implement the lazy TDACCEPT as when
the first time a guest accesses an unaccepted memory, #VE can do the TDACCEPT.

I am not trying to solve the lazy TDACCEPT problem here but all I am
trying to say is that, there might be legitimate use cases for #VE on
private memory and this patch limits any future improvement we might
need to do on lazy TDACCEPT implementation.

> +        * In both cases terminating TD is the right thing to do.
> +        */
> +       if (!(td_attr & ATTR_SEPT_VE_DISABLE))
> +               panic("TD misconfiguration: SEPT_VE_DISABLE attibute must be set.\n");
> +
>         setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
>
>         cc_set_vendor(CC_VENDOR_INTEL);
> --
> 2.38.0
>