linux-kernel - Re: [PATCH v1 23/24] kvm: arm64: Trap host SMCs in protected mode.

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: <20201110130049.pwc4ilqy2ue2ydvu@google.com>
Date:   Tue, 10 Nov 2020 13:00:49 +0000
From:   David Brazdil <dbrazdil@...gle.com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     kvmarm@...ts.cs.columbia.edu, kernel-team@...roid.com,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Andrew Walbran <qwandor@...gle.com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Catalin Marinas <catalin.marinas@....com>,
        Tejun Heo <tj@...nel.org>, Dennis Zhou <dennis@...nel.org>,
        Christoph Lameter <cl@...ux.com>, Will Deacon <will@...nel.org>
Subject: Re: [PATCH v1 23/24] kvm: arm64: Trap host SMCs in protected mode.

> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> > @@ -88,6 +88,12 @@ SYM_CODE_END(__kvm_hyp_init)
> >   * x0: struct kvm_nvhe_init_params PA
> >   */
> >  SYM_CODE_START(___kvm_hyp_init)
> > +alternative_cb kvm_patch_hcr_flags
> > +	mov_q	x1, HCR_HOST_NVHE_FLAGS
> 
> You really want to be careful here: the mov_q macro expands to 2, 3 or 4
> instructions, depending on the input data...
> 
> It is also odd that you have both a static key and a patching alternative.
> Why isn't "protected KVM" a capability that can be evaluated as a a non
> patching alternative? In general, I'd like to reserve patching alternatives
> to values that cannot be evaluated at compile time (VM offsets, for
> example).

Capability was my initial idea as well but it looked tied to CPU features.
Looking at it again, you're right that there is precedent for setting them
from kernel params. Alright, I'll change it and that will get rid of the
custom patching.