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
| ||
|
Date: Fri, 1 Jan 2021 18:33:28 +0000 From: David Laight <David.Laight@...LAB.COM> To: 'Andy Lutomirski' <luto@...nel.org>, Nicholas Piggin <npiggin@...il.com> CC: Arnd Bergmann <arnd@...db.de>, X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>, stable <stable@...r.kernel.org>, Will Deacon <will@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Catalin Marinas <catalin.marinas@....com>, Paul Mackerras <paulus@...ba.org>, linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>, linux-arm-kernel <linux-arm-kernel@...ts.infradead.org> Subject: RE: [RFC please help] membarrier: Rewrite sync_core_before_usermode() From: Andy Lutomirski > Sent: 29 December 2020 00:36 ... > I mean that the mapping from the name "sync_core" to its semantics is > x86 only. The string "sync_core" appears in the kernel only in > arch/x86, membarrier code, membarrier docs, and a single SGI driver > that is x86-only. Sure, the idea of serializing things is fairly > generic, but exactly what operations serialize what, when things need > serialization, etc is quite architecture specific. > > Heck, on 486 you serialize the instruction stream with JMP. Did the 486 even have a memory cache? Never mind separate I&D caches. Without branch prediction or an I$ a jmp is enough. No idea how the dual 486 box we had actually behaved. For non-SMP the x86 cpus tend to still be compatible with the original 8086 - so are pretty much fully coherent. ISTR the memory writes will invalidate I$ lines. But there was some hardware compatibility that meant a load of Pentium-75 systems were 'scavenged' from development for a customer - we got faster P-266 boxes as replacements. OTOH we never did work out how to do the required 'barrier' when switching a Via C3 to and from 16-bit mode. Sometimes it worked, other times the cpu went AWOL. Best guess was that it sometimes executed pre-decoded instructions for the wrong mode when returning from the function call that flipped modes. Then there is the P-Pro era Intel doc that says that IOR/IOW aren't sequenced wrt memory accesses. Fortunately all x86 processors have sequenced them. Which is what the current docs say. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Powered by blists - more mailing lists