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] [day] [month] [year] [list]
Message-ID: <YW6f1OxgsY4y16/N@google.com>
Date:   Tue, 19 Oct 2021 11:37:08 +0100
From:   Quentin Perret <qperret@...gle.com>
To:     Andrew Walbran <qwandor@...gle.com>
Cc:     Marc Zyngier <maz@...nel.org>, James Morse <james.morse@....com>,
        Alexandru Elisei <alexandru.elisei@....com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Fuad Tabba <tabba@...gle.com>,
        David Brazdil <dbrazdil@...gle.com>,
        linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu,
        linux-kernel@...r.kernel.org,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH 01/16] KVM: arm64: Introduce do_share() helper for memory
 sharing between components

Hi Andrew,

On Friday 15 Oct 2021 at 16:11:49 (+0100), Andrew Walbran wrote:
> On Wed, 13 Oct 2021 at 16:58, 'Quentin Perret' via kernel-team
> > +struct pkvm_mem_transition {
> > +       u64                             nr_pages;
> > +
> > +       struct {
> > +               enum pkvm_component_id  id;
> > +               u64                     addr;
> Is this the physical address or the IPA of the initiator? It would be
> good to have a comment explaining.

That's the address in the initiator's address space. For the host and
guests that'll be an IPA (which also happens to be the same as the PA
for the host) and for the hypervisor that'll be an EL2 VA.

But yes, a comment won't hurt, so I'll add something.

<snip>
> > +static int check_share(struct pkvm_page_req *req,
> > +                      struct pkvm_page_share_ack *ack,
> > +                      struct pkvm_mem_share *share)
> > +{
> > +       if (!addr_is_memory(req->phys))
> > +               return -EINVAL;
> > +
> > +       if (req->initiator.state == PKVM_PAGE_OWNED &&
> > +           ack->completer.state == PKVM_NOPAGE) {
> > +               return 0;
> > +       }
> > +
> > +       if (req->initiator.state != PKVM_PAGE_SHARED_OWNED)
> > +               return -EPERM;
> > +
> > +       if (ack->completer.state != PKVM_PAGE_SHARED_BORROWED)
> > +               return -EPERM;
> > +
> > +       if (ack->completer.phys != req->phys)
> > +               return -EPERM;
> > +
> > +       if (ack->completer.prot != share->prot)
> > +               return -EPERM;
> I guess this is the workaround you mentioned for the fact that the
> host can share the same page twice? It might be worth adding a comment
> to explain that that's what's going on.

Yep, that's what is going on here. But FWIW I'm currently reworking the
way we refcount pages in v2, which will now become the host's
responsibility. So, that should simplify things quite a bit at EL2, and
make all of the above go away :-)

Cheers,
Quentin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ