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: <Ya/XoYTsEvkPqRuh@google.com>
Date:   Tue, 7 Dec 2021 21:52:33 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Lai Jiangshan <jiangshanlai@...il.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        Lai Jiangshan <laijs@...ux.alibaba.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 3/4] KVM: X86: Handle implicit supervisor access with SMAP

On Tue, Dec 07, 2021, Lai Jiangshan wrote:
> diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
> index b70b36734bc0..0cb2c52377c8 100644
> --- a/arch/x86/kvm/mmu.h
> +++ b/arch/x86/kvm/mmu.h
> @@ -252,23 +252,26 @@ static inline u8 permission_fault(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu,
>  				  unsigned pte_access, unsigned pte_pkey,
>  				  unsigned pfec)
>  {
> -	int cpl = static_call(kvm_x86_get_cpl)(vcpu);
>  	unsigned long rflags = static_call(kvm_x86_get_rflags)(vcpu);
>  
>  	/*
> -	 * If CPL < 3, SMAP prevention are disabled if EFLAGS.AC = 1.
> +	 * If explicit supervisor accesses, SMAP is disabled

Slight reword, and each clause can fit on one line.

	 * For explicit supervisor accesses, SMAP is disabled if EFLAGS.AC = 1.
	 *
	 * For implicit supervisor accesses, SMAP cannot be overridden.

> +	 * if EFLAGS.AC = 1.
>  	 *
> -	 * If CPL = 3, SMAP applies to all supervisor-mode data accesses
> -	 * (these are implicit supervisor accesses) regardless of the value
> -	 * of EFLAGS.AC.
> +	 * If implicit supervisor accesses, SMAP can not be disabled
> +	 * regardless of the value EFLAGS.AC.
>  	 *
> -	 * This computes (cpl < 3) && (rflags & X86_EFLAGS_AC), leaving
> +	 * SMAP works on supervisor accesses only, and not_smap can
> +	 * be set or not set when user access with neither has any bearing
> +	 * on the result.

This is quite jumbled, I'd just drop it entirely, the interesting bits are
the rules for implicit vs. explicit and the blurb below that describes the magic.

> +	 *
> +	 * This computes explicit_access && (rflags & X86_EFLAGS_AC), leaving

Too many &&, the logic below is a bitwise &, not a logical &&.

>  	 * the result in X86_EFLAGS_AC. We then insert it in place of
>  	 * the PFERR_RSVD_MASK bit; this bit will always be zero in pfec,
>  	 * but it will be one in index if SMAP checks are being overridden.
>  	 * It is important to keep this branchless.

Heh, so important that it incurs multiple branches and possible VMREADs in
vmx_get_cpl() and vmx_get_rflags().  And before static_call, multiple retpolines
to boot.  Probably a net win now as only the first permission_fault() check for
a given VM-Exit be penalized, but the comment is amusing nonetheless.

>  	 */
> -	unsigned long not_smap = (cpl - 3) & (rflags & X86_EFLAGS_AC);
> +	u32 not_smap = (rflags & X86_EFLAGS_AC) & vcpu->arch.explicit_access;

I really, really dislike shoving this into vcpu->arch.  I'd much prefer to make
this a property of the access, even if that means adding another param or doing
something gross with @access (@pfec here).

>  	int index = (pfec >> 1) +
>  		    (not_smap >> (X86_EFLAGS_AC_BIT - PFERR_RSVD_BIT + 1));
>  	bool fault = (mmu->permissions[index] >> pte_access) & 1;

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ