linux-kernel - [PATCHv2 00/10] ACCESS_ONCE and non-scalar accesses

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-next>] [day] [month] [year] [list]

Message-Id: <1416919117-50652-1-git-send-email-borntraeger@de.ibm.com>
Date:	Tue, 25 Nov 2014 13:38:27 +0100
From:	Christian Borntraeger <borntraeger@...ibm.com>
To:	linux-kernel@...r.kernel.org
Cc:	"linux-arch@...r.kernel.org, linux-mips@...ux-mips.org, linux-x86_64@...r.kernel.org, linux-s390"@vger.kernel.org,
	Paolo Bonzini <pbonzini@...hat.com>,
	paulmck@...ux.vnet.ibm.com, mingo@...nel.org,
	torvalds@...ux-foundation.org,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	David Howells <dhowells@...hat.com>,
	Russell King <linux@....linux.org.uk>,
	Christian Borntraeger <borntraeger@...ibm.com>
Subject: [PATCHv2 00/10] ACCESS_ONCE and non-scalar accesses

As discussed on LKML http://marc.info/?i=54611D86.4040306%40de.ibm.com
ACCESS_ONCE might fail with specific compiler for non-scalar accesses.

Here is a set of patches to tackle that problem.

The first patch is already in kvm/next and this series is against rc3 (as
kvm/next so that we can avoid a merge conflict as soon as this series
has stabilized).
The 2nd patch introduces READ_ONCE/ASSIGN_ONCE as suggested by Linus.
The 2nd to last patch will force ACCESS_ONCE to error-out if it is used
on non-scalar accesses.

I have cross-compiled the resulting kernel with defconfig for
microblaze, m68k, alpha, s390,x86_64, i686, sparc, sparc64, mips,
ia64, arm and arm64.
Will Deacon pointed me to the right defconfig for arm32 to also trigger
a finding here.
Runtime testing was only done on s390x.

There is a small problem left with sparc (32bit) and m68k:

mm/rmap.c: In function 'mm_find_pmd':
include/linux/compiler.h:220:72: warning: '__val' may be used uninitialized in this function [-Wmaybe-uninitialized]
       ({ typeof(p) __val; __read_once_size(&p, &__val, sizeof(__val)); __val; })
                                                                        ^
include/linux/compiler.h:220:20: note: '__val' was declared here
       ({ typeof(p) __val; __read_once_size(&p, &__val, sizeof(__val)); __val; })
                    ^
mm/rmap.c:584:9: note: in expansion of macro 'READ_ONCE'
  pmde = READ_ONCE(*pmd);

Reason is that for both architectures pmd_t is long[16]. WTF?

So the next spin will either fix m68k/sparc or use a barrier + ACCESS_ONCE.

Comments?

Christian Borntraeger (10):
  KVM: s390: Fix ipte locking
  kernel: Provide READ_ONCE and ASSIGN_ONCE
  mm: replace ACCESS_ONCE with READ_ONCE
  x86/spinlock: Replace ACCESS_ONCE with READ_ONCE/ASSIGN_ONCE
  x86: Replace ACCESS_ONCE in gup with READ_ONCE
  mips: Replace ACCESS_ONCE in gup with READ_ONCE
  arm64: Replace ACCESS_ONCE for spinlock code with READ_ONCE
  arm: Replace ACCESS_ONCE for spinlock code with READ_ONCE
  tighten rules for ACCESS ONCE
  KVM: s390: change ipte lock from barrier to READ_ONCE

 arch/arm/include/asm/spinlock.h   |  4 ++--
 arch/arm64/include/asm/spinlock.h |  4 ++--
 arch/mips/mm/gup.c                |  2 +-
 arch/s390/kvm/gaccess.c           | 14 +++++++------
 arch/x86/include/asm/spinlock.h   |  8 +++----
 arch/x86/mm/gup.c                 |  2 +-
 include/linux/compiler.h          | 44 ++++++++++++++++++++++++++++++++++++++-
 mm/gup.c                          |  2 +-
 mm/memory.c                       |  2 +-
 mm/rmap.c                         |  2 +-
 10 files changed, 64 insertions(+), 20 deletions(-)


--
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/