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:	Fri, 22 May 2015 20:42:31 -0400
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	Bandan Das <bsd@...hat.com>
CC:	Xiao Guangrong <guangrong.xiao@...ux.intel.com>,
	pbonzini@...hat.com, gleb@...nel.org, mtosatti@...hat.com,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] KVM: MMU: fix SMAP virtualization

On 05/22/2015 07:54 PM, Bandan Das wrote:
> Boris Ostrovsky <boris.ostrovsky@...cle.com> writes:
>
>> On 05/11/2015 10:55 AM, Xiao Guangrong wrote:
>>> KVM may turn a user page to a kernel page when kernel writes a readonly
>>> user page if CR0.WP = 1. This shadow page entry will be reused after
>>> SMAP is enabled so that kernel is allowed to access this user page
>>>
>>> Fix it by setting SMAP && !CR0.WP into shadow page's role and reset mmu
>>> once CR4.SMAP is updated
>>>
>>> Signed-off-by: Xiao Guangrong <guangrong.xiao@...ux.intel.com>
>>> ---
>>
>>
>>>
>>> @@ -4208,12 +4211,18 @@ void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
>>>    		       const u8 *new, int bytes)
>>>    {
>>>    	gfn_t gfn = gpa >> PAGE_SHIFT;
>>> -	union kvm_mmu_page_role mask = { .word = 0 };
>>>    	struct kvm_mmu_page *sp;
>>>    	LIST_HEAD(invalid_list);
>>>    	u64 entry, gentry, *spte;
>>>    	int npte;
>>>    	bool remote_flush, local_flush, zap_page;
>>> +	union kvm_mmu_page_role mask = (union kvm_mmu_page_role) {
>>> +		.cr0_wp = 1,
>>> +		.cr4_pae = 1,
>>> +		.nxe = 1,
>>> +		.smep_andnot_wp = 1,
>>> +		.smap_andnot_wp = 1,
>>> +	};
>>>
>>>
>>
>>
>> This breaks older compilers that can't initialize anon structures.
>
> How old ? Even gcc 3.1 says you can use unnamed struct/union fields and
> 3.2 is the minimum version required to compile the kernel as mentioned
> in the README.
>
> We could simply just name the structure, but I doubt this is the
> only place in the kernel code where it's being used this way :)


You can use them but you can't use initializers. Unfortunately my build 
system (F13) conveniently went down but this is an example from an old 
email:

FC-64 <build@...ld-mk2:~/xtt-x86_64/bootstrap> cat anon.c
struct bar {
struct {
int i;
};
};

main()
{
struct bar a = {.i = 0};
}

FC-64 <build@...ld-mk2:~/xtt-x86_64/bootstrap> gcc --version|head -1
gcc (GCC) 4.4.4 20100503 (Red Hat 4.4.4-2)
FC-64 <build@...ld-mk2:~/xtt-x86_64/bootstrap> gcc anon.c
anon.c: In function ‘main’:
anon.c:9: error: unknown field ‘i’ specified in initializer
FC-64 <build@...ld-mk2:~/xtt-x86_64/bootstrap>


but

build@...ld-mk2 bootstrap]$ gcc --version|head -1
gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)
[build@...ld-mk2 bootstrap]$ gcc anon.c
[build@...ld-mk2 bootstrap]$


-boris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ