linux-kernel - Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1

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:   Tue, 20 Dec 2016 12:27:28 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     David Miller <davem@...emloft.net>
Cc:     sparclinux@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, bob.picco@...cle.com,
        nitin.m.gupta@...cle.com, vijay.ac.kumar@...cle.com,
        julian.calaby@...il.com, adam.buchbinder@...il.com,
        kirill.shutemov@...ux.intel.com, mhocko@...e.com,
        akpm@...ux-foundation.org
Subject: Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1

On 12/20/2016 10:33 AM, David Miller wrote:
> From: Mike Kravetz <mike.kravetz@...cle.com>
> Date: Sun, 18 Dec 2016 16:06:01 -0800
> 
>> Ok, let me try to find a way to eliminate these loads unless the application
>> is using shared context.
>>
>> Part of the issue is a 'backwards compatibility' feature of the processor
>> which loads/overwrites register 1 every time register 0 is loaded.  Somewhere
>> in the evolution of the processor, a feature was added so that register 0
>> could be loaded without overwriting register 1.  That could be used to
>> eliminate the extra load in some/many cases.  But, that would likely lead
>> to more runtime kernel patching based on processor level.  And, I don't
>> really want to add more of that if possible.  Or, perhaps we only enable
>> the shared context ID feature on processors which have the ability to work
>> around the backwards compatibility feature.
> 
> Until the first process uses shared mappings, you should not touch the
> context 1 register in any way for any reason at all.
> 
> And even once a process _does_ use shared mappings, you only need to
> access the context 1 register in 2 cases:
> 
> 1) TLB processing for the processes using shared mappings.
> 
> 2) Context switch MMU state handling, where either the previous or
>    next process is using shared mappings.

I agree.

But, we still need to address the issue of existing code that is
overwriting context register 1 today.  Due to that backwards
compatibility feature, code like:

	mov	SECONDARY_CONTEXT, %g3
	stxa	%g2, [%g3] ASI_DMMU

will store not only to register 0, but register 1 as well.

In this RFC, I used an ugly brute force method of always restoring
register 1 after storing register 0 to make sure any unique value
in register 1 was preserved.  I agree this is not acceptable and needs
to be fixed.  We could check if register 1 is in use and only do the
save/restore in that case.  But, that is still an additional check.

The Sparc M7 processor has new ASIs to handle this better:
ASI	ASI Name	R/W	VA 	Per Strand	Description
0x21	ASI_MMU 	RW	0x28 	Y 		I/DMMUPrimary Context
							register 0 (no Primary
							Context register 1
							update)
0x21	ASI_MMU		RW	0x30	Y 		DMMUSecondary Context
							register 0 (no Secondary
							Context register 1
							update)
More details at,
http://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/sparc-architecture-supplement-3093429.pdf

Of course, this could only be used on processors where the new ASIs are
available.

Still need to think about the best way to handle this.
-- 
Mike Kravetz