[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210406212424.86d6d4533b144d4621ecb385@intel.com>
Date: Tue, 6 Apr 2021 21:24:24 +1200
From: Kai Huang <kai.huang@...el.com>
To: Borislav Petkov <bp@...en8.de>
Cc: kvm@...r.kernel.org, linux-sgx@...r.kernel.org, x86@...nel.org,
linux-kernel@...r.kernel.org, seanjc@...gle.com, jarkko@...nel.org,
luto@...nel.org, dave.hansen@...el.com, 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 13/25] x86/sgx: Add helpers to expose ECREATE and
EINIT to KVM
On Tue, 6 Apr 2021 11:09:01 +0200 Borislav Petkov wrote:
> On Tue, Apr 06, 2021 at 08:59:58PM +1200, Kai Huang wrote:
> > OK. My thinking was that, returning negative error value basically means guest
> > will be killed.
>
> You need to define how you're going to handle invalid input from the
> guest. If that guest is considered malicious, then sure, killing it
> makes sense.
Such invalid input has already been handled in handle_encls_xx() before calling
the two helpers in this patch. KVM returns to Qemu and let it decide whether to
kill or not. The access_ok()s here are trying to catch KVM bug.
>
> > For the case access_ok() fails for @secs or other user pointers, it
> > seems killing guest is a little it overkill,
>
> So don't kill it then - just don't allow it to create an enclave because
> it is doing stupid crap.
If so we'd better inject an exception to guest (and return 1) in KVM so guest
can continue to run. Otherwise basically KVM will return to Qemu and let it
decide (and basically it will kill guest).
I think killing guest is also OK. KVM part patches needs to be updated, though,
anyway.
Powered by blists - more mailing lists