linux-kernel - Re: [PATCH v2 3/7] virt: geniezone: Introduce GenieZone hypervisor support

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: <70acccee-22d7-0d35-b943-346a435b9eab@quicinc.com>
Date:   Fri, 28 Apr 2023 15:48:33 -0700
From:   Trilok Soni <quic_tsoni@...cinc.com>
To:     Marc Zyngier <maz@...nel.org>, Yi-De Wu <yi-de.wu@...iatek.com>
CC:     Yingshiuan Pan <yingshiuan.pan@...iatek.com>,
        Ze-Yu Wang <ze-yu.wang@...iatek.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Jonathan Corbet <corbet@....net>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-doc@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-arch@...r.kernel.org>, <linux-mediatek@...ts.infradead.org>,
        David Bradil <dbrazdil@...gle.com>,
        Jade Shih <jades.shih@...iatek.com>,
        Miles Chen <miles.chen@...iatek.com>,
        Ivan Tseng <ivan.tseng@...iatek.com>,
        My Chuang <my.chuang@...iatek.com>,
        Shawn Hsiao <shawn.hsiao@...iatek.com>,
        PeiLun Suei <peilun.suei@...iatek.com>,
        Liju Chen <liju-clr.chen@...iatek.com>
Subject: Re: [PATCH v2 3/7] virt: geniezone: Introduce GenieZone hypervisor
 support

Hi Marc,

> 
> [...]
> 
>> +/**
>> + * gzvm_gfn_to_pfn_memslot() - Translate gfn (guest ipa) to pfn (host 
>> pa),
>> + *                   result is in @pfn
>> + *
>> + * Leverage KVM's gfn_to_pfn_memslot(). Because gfn_to_pfn_memslot() 
>> needs
>> + * kvm_memory_slot as parameter, this function populates necessary 
>> fileds
>> + * for calling gfn_to_pfn_memslot().
>> + *
>> + * Return:
>> + * * 0            - Succeed
>> + * * -EFAULT        - Failed to convert
>> + */
>> +static int gzvm_gfn_to_pfn_memslot(struct gzvm_memslot *memslot, u64
>> gfn, u64 *pfn)
>> +{
>> +    hfn_t __pfn;
>> +    struct kvm_memory_slot kvm_slot = {0};
>> +
>> +    kvm_slot.base_gfn = memslot->base_gfn;
>> +    kvm_slot.npages = memslot->npages;
>> +    kvm_slot.dirty_bitmap = NULL;
>> +    kvm_slot.userspace_addr = memslot->userspace_addr;
>> +    kvm_slot.flags = memslot->flags;
>> +    kvm_slot.id = memslot->slot_id;
>> +    kvm_slot.as_id = 0;
>> +
>> +    __pfn = gfn_to_pfn_memslot(&kvm_slot, gfn);
> 
> Again, I absolutely oppose this horror. This is internal to KVM,
> and we want to be able to change this without having to mess
> with your own code that we cannot test anyway.
> 
> What if we start using the extra fields that you don't populate
> as they mean nothing to you? Or add a backpointer to the kvm
> structure to do fancy accounting?
> 
> You have your own hypervisor, that's well and good. Since your
> main argument is that it is supposed to be standalone, make it
> *really* standalone and don't use KVM as a prop.


Agreed, same comments were made earlier too. I would prefer that 
GenieZone have its own identify rather than sharing the 
APIs/data-structures here.

---Trilok Soni