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, 17 Dec 2019 10:03:15 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Andy Lutomirski' <luto@...nel.org>
CC:     Peter Zijlstra <peterz@...radead.org>,
        "Luck, Tony" <tony.luck@...el.com>,
        "Yu, Fenghua" <fenghua.yu@...el.com>,
        Ingo Molnar <mingo@...nel.org>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "Borislav Petkov" <bp@...en8.de>, H Peter Anvin <hpa@...or.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        x86 <x86@...nel.org>, "Will Deacon" <will@...nel.org>
Subject: RE: [PATCH v10 6/6] x86/split_lock: Enable split lock detection by
 kernel parameter

From: Andy Lutomirski
> Sent: 16 December 2019 18:06
..
> This whole discussion is about the fact that PeterZ is sceptical that
> actual x86 CPUs have as strong a memory model as the SDM suggests, and
> I'm trying to understand the exact concern.  This may or may not be
> directly relevant to the kernel. :)

The x86 memory model is pretty strong.
It has to be to support historic code - including self modifying code.
I think DOS from 1982 should still boot.

Even for SMP they probably can't relax anything from the original implementations.
(Except cpu specific kernel bits - since that has all changed since some dual 486 boxes.)

Actually the weakest x86 memory model was that defined in some P-pro
era Intel docs that said that IOR/IOW weren't sequenced with memory accesses.
Fortunately no cpu ever did that reordering, and now it isn't allowed.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ