linux-kernel - Re: [PATCH 0/2] KVM: x86: Fix incorrect VM-exit profiling

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]

Date:   Wed, 18 May 2022 13:27:30 +0900
From:   Suleiman Souhlal <suleiman@...gle.com>
To:     Wei Zhang <zhanwei@...gle.com>
Cc:     Sean Christopherson <seanjc@...gle.com>,
        Sangwhan Moon <sxm@...gle.com>, Ingo Molnar <mingo@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Jing Zhang <jingzhangos@...gle.com>,
        David Matlack <dmatlack@...gle.com>
Subject: Re: [PATCH 0/2] KVM: x86: Fix incorrect VM-exit profiling

On Tue, May 17, 2022 at 4:30 AM Wei Zhang <zhanwei@...gle.com> wrote:
>
> > Please don't top-post.  From https://people.kernel.org/tglx/notes-about-netiquette:
>
> Ah, I didn't know this should be avoided. Thanks for the info!
>
> > My preference would be to find a more complete, KVM-specific solution.  The
> > profiling stuff seems like it's a dead end, i.e. will always be flawed in some
> > way.  If this cleanup didn't require a new hypercall then I wouldn't care, but
> > I don't love having to extend KVM's guest/host ABI for something that ideally
> > will become obsolete sooner than later.
>
> I also feel that adding a new hypercall is too much here. A
> KVM-specific solution is definitely better, and the eBPF based
> approach you mentioned sounds like the ultimate solution (at least for
> inspecting exit reasons).
>
> +Suleiman What do you think? The on-going work Sean described sounds
> promising, perhaps we should put this patch aside for the time being.

I'm ok with that.
That said, the advantage of the current solution is that it already
exists and is very easy to use, by anyone, without having to write any
code. The proposed solution doesn't sound like it will be as easy.

Regarding the earlier question about wanting to know which
instructions trigger exits, most times I've needed to get exit
profiles, I actually wanted to know where the guest was at the time of
the exit, regardless of who triggered the exit.

-- Suleiman