linux-kernel - Re: [PATCH v3 03/25] x86/sgx: Wipe out EREMOVE from sgx_free_epc

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]

Message-ID: <YFsGJfYA9H69hwKd@kernel.org>
Date:   Wed, 24 Mar 2021 11:28:05 +0200
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Borislav Petkov <bp@...en8.de>, Kai Huang <kai.huang@...el.com>,
        kvm@...r.kernel.org, x86@...nel.org, linux-sgx@...r.kernel.org,
        linux-kernel@...r.kernel.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 03/25] x86/sgx: Wipe out EREMOVE from
 sgx_free_epc_page()

On Tue, Mar 23, 2021 at 04:21:47PM +0000, Sean Christopherson wrote:
> On Tue, Mar 23, 2021, Borislav Petkov wrote:
> > On Tue, Mar 23, 2021 at 03:45:14PM +0000, Sean Christopherson wrote:
> > > Practically speaking, "basic" deployments of SGX VMs will be insulated from
> > > this bug.  KVM doesn't support EPC oversubscription, so even if all EPC is
> > > exhausted, new VMs will fail to launch, but existing VMs will continue to chug
> > > along with no ill effects....
> > 
> > Ok, so it sounds to me like *at* *least* there should be some writeup in
> > Documentation/ explaining to the user what to do when she sees such an
> > EREMOVE failure, perhaps the gist of this thread and then possibly the
> > error message should point to that doc.
> > 
> > We will of course have to revisit when this hits the wild and people
> > start (or not) hitting this. But judging by past experience, if it is
> > there, we will hit it. Murphy says so.
> 
> I like the idea of pointing at the documentation.  The documentation should
> probably emphasize that something is very, very wrong.  E.g. if a kernel bug
> triggers EREMOVE failure and isn't detected until the kernel is widely deployed
> in a fleet, then the folks deploying the kernel probably _should_ be in all out
> panic.  For this variety of bug to escape that far, it means there are huge
> holes in test coverage, in both the kernel itself and in the infrasturcture of
> whoever is rolling out their new kernel.

My own experience with WARN()'s has been so far, that the stack trace does
the job fairly well. It's commonly misintepreted same as oops.

/Jarkko