| 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
| ||
|
Message-ID: <ZUKMsOdg3N9wmEzy@google.com>
Date: Wed, 1 Nov 2023 10:36:48 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Kai Huang <kai.huang@...el.com>
Cc: "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
"brauner@...nel.org" <brauner@...nel.org>,
"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
"chenhuacai@...nel.org" <chenhuacai@...nel.org>,
"paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
"palmer@...belt.com" <palmer@...belt.com>,
"maz@...nel.org" <maz@...nel.org>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"mpe@...erman.id.au" <mpe@...erman.id.au>,
"willy@...radead.org" <willy@...radead.org>,
"anup@...infault.org" <anup@...infault.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
Xiaoyao Li <xiaoyao.li@...el.com>,
"kvm-riscv@...ts.infradead.org" <kvm-riscv@...ts.infradead.org>,
"mic@...ikod.net" <mic@...ikod.net>,
"liam.merwick@...cle.com" <liam.merwick@...cle.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
Isaku Yamahata <isaku.yamahata@...el.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"david@...hat.com" <david@...hat.com>,
"tabba@...gle.com" <tabba@...gle.com>,
"amoorthy@...gle.com" <amoorthy@...gle.com>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"michael.roth@....com" <michael.roth@....com>,
"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
"chao.p.peng@...ux.intel.com" <chao.p.peng@...ux.intel.com>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
Vishal Annapurve <vannapurve@...gle.com>,
"vbabka@...e.cz" <vbabka@...e.cz>,
"mail@...iej.szmigiero.name" <mail@...iej.szmigiero.name>,
"yu.c.zhang@...ux.intel.com" <yu.c.zhang@...ux.intel.com>,
"qperret@...gle.com" <qperret@...gle.com>,
"dmatlack@...gle.com" <dmatlack@...gle.com>,
Yilun Xu <yilun.xu@...el.com>,
"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
"ackerleytng@...gle.com" <ackerleytng@...gle.com>,
"jarkko@...nel.org" <jarkko@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Wei W Wang <wei.w.wang@...el.com>
Subject: Re: [PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report
faults to userspace
On Wed, Nov 01, 2023, Kai Huang wrote:
>
> > +7.34 KVM_CAP_MEMORY_FAULT_INFO
> > +------------------------------
> > +
> > +:Architectures: x86
> > +:Returns: Informational only, -EINVAL on direct KVM_ENABLE_CAP.
> > +
> > +The presence of this capability indicates that KVM_RUN will fill
> > +kvm_run.memory_fault if KVM cannot resolve a guest page fault VM-Exit, e.g. if
> > +there is a valid memslot but no backing VMA for the corresponding host virtual
> > +address.
> > +
> > +The information in kvm_run.memory_fault is valid if and only if KVM_RUN returns
> > +an error with errno=EFAULT or errno=EHWPOISON *and* kvm_run.exit_reason is set
> > +to KVM_EXIT_MEMORY_FAULT.
>
> IIUC returning -EFAULT or whatever -errno is sort of KVM internal
> implementation.
The errno that is returned to userspace is ABI. In KVM, it's a _very_ poorly
defined ABI for the vast majority of ioctls(), but it's still technically ABI.
KVM gets away with being cavalier with errno because the vast majority of errors
are considered fatal by userespace, i.e. in most cases, userspace simply doesn't
care about the exact errno.
A good example is KVM_RUN with -EINTR; if KVM were to return something other than
-EINTR on a pending signal or vcpu->run->immediate_exit, userspace would fall over.
> Is it better to relax the validity of kvm_run.memory_fault when
> KVM_RUN returns any -errno?
Not unless there's a need to do so, and if there is then we can update the
documentation accordingly. If KVM's ABI is that kvm_run.memory_fault is valid
for any errno, then KVM would need to purge kvm_run.exit_reason super early in
KVM_RUN, e.g. to prevent an -EINTR return due to immediate_exit from being
misinterpreted as KVM_EXIT_MEMORY_FAULT. And purging exit_reason super early is
subtly tricky because KVM's (again, poorly documented) ABI is that *some* exit
reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a
pending signal).
https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com
> [...]
>
>
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -2327,4 +2327,15 @@ static inline void kvm_account_pgtable_pages(void *virt, int nr)
> > /* Max number of entries allowed for each kvm dirty ring */
> > #define KVM_DIRTY_RING_MAX_ENTRIES 65536
> >
> > +static inline void kvm_prepare_memory_fault_exit(struct kvm_vcpu *vcpu,
> > + gpa_t gpa, gpa_t size)
> > +{
> > + vcpu->run->exit_reason = KVM_EXIT_MEMORY_FAULT;
> > + vcpu->run->memory_fault.gpa = gpa;
> > + vcpu->run->memory_fault.size = size;
> > +
> > + /* Flags are not (yet) defined or communicated to userspace. */
> > + vcpu->run->memory_fault.flags = 0;
> > +}
> > +
>
> KVM_CAP_MEMORY_FAULT_INFO is x86 only, is it better to put this function to
> <asm/kvm_host.h>?
I'd prefer to keep it in generic code, as it's highly likely to end up there
sooner than later. There's a known use case for ARM (exit to userspace on missing
userspace mapping[*]), and I'm guessing pKVM (also ARM) will also utilize this API.
[*] https://lore.kernel.org/all/20230908222905.1321305-8-amoorthy@google.com
Powered by blists - more mailing lists