linux-kernel - Re: [PATCH v3 05/25] x86/sgx: Introduce virtual EPC for use by KVM guests

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <db27d34f-60f9-a8e8-270e-7152bce81a12@intel.com>
Date:   Fri, 26 Mar 2021 08:17:38 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Borislav Petkov <bp@...en8.de>, seanjc@...gle.com
Cc:     Kai Huang <kai.huang@...el.com>, kvm@...r.kernel.org,
        x86@...nel.org, linux-sgx@...r.kernel.org,
        linux-kernel@...r.kernel.org, jarkko@...nel.org, luto@...nel.org,
        rick.p.edgecombe@...el.com, haitao.huang@...el.com,
        pbonzini@...hat.com, tglx@...utronix.de, mingo@...hat.com,
        hpa@...or.com
Subject: Re: [PATCH v3 05/25] x86/sgx: Introduce virtual EPC for use by KVM
 guests

On 3/26/21 8:03 AM, Borislav Petkov wrote:
> Let's say all guests start using enclaves and baremetal cannot start any
> new ones anymore due to no more memory. Are we ok with that?

Yes, for now.

> What if baremetal creates a big fat enclave and starves guests all of a
> sudden. Are we ok with that either?

Actually, the baremetal enclave will get a large chunk of its resources
reclaimed and stolen from it.  The guests will probably start and the
baremetal will probably thrash until its allocations fail and it is
killed because it couldn't allocate enclave memory in a page fault.

> In general, having two disjoint things give out SGX resources separately
> sounds like trouble to me.

Yes, it's trouble as-is.

We're working on a cgroup controller just for enclave pages that will
apply to guest use and bare metal.  It would have been nice to have up
front, but we're trying to do things incrementally.  A cgroup controller
should solve he vast majority of these issues where users are quarreling
about who gets enclave memory.

BTW, we probably should have laid this out up front in the original
merge, but the plans in order were roughly:

1. Core SGX functionality (merged into 5.11)
2. NUMA and KVM work
3. cgroup controller for enclave pages
4. EDMM support (lets you add/remove pages and change permissions while
   enclave runs.  Current enclaves are stuck with the same memory they
   start with)

After that, things become less clear.  There's some debate whether we
need to rework the VA pages (enclave swapping metadata to prevent
replay) or improve ability to reclaim guest pages.