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]

Message-Id: <20161220.133334.158286071772728328.davem@davemloft.net>
Date:   Tue, 20 Dec 2016 13:33:34 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     mike.kravetz@...cle.com
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

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.