linux-kernel - Re: [PATCH v10 6/6] x86/split_lock: Enable split lock detection by kernel parameter

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: <20191121173501.GT4097@hirez.programming.kicks-ass.net>
Date:   Thu, 21 Nov 2019 18:35:01 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Fenghua Yu <fenghua.yu@...el.com>
Cc:     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>,
        Tony Luck <tony.luck@...el.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH v10 6/6] x86/split_lock: Enable split lock detection by
 kernel parameter

On Thu, Nov 21, 2019 at 08:14:10AM -0800, Fenghua Yu wrote:

> The usage scope of this patch set is largely reduced to only real time.
> The long split lock processing time (>1000 cycles) cannot be tolerated
> by real time.

I'm thinking you're clueless on realtime. There's plenty of things that
can cause many cycles to go out the window. And just a single
instruction soaking up cycles like that really isn't the problem.

The problem is that split lock defeats isolation. An otherwise contained
task can have pretty horrific side effects on other tasks.

> Real time customers do want to use this feature to detect the fatal
> split lock error. They don't want any split lock issue from BIOS/EFI/
> firmware/kerne/drivers/user apps.

Cloud vendors also don't want them. Nobody wants them, they stink. They
have a system wide impact.

I don't want them on my system.

> > Imagine the BIOS/EFI/firmware containing an #AC exception. At that point
> > the feature becomes useless, because you cannot enable it without your
> > machine dying.
> 
> I believe Intel real time team guarantees to deliever a split lock FREE
> BIOS/EFI/firmware to their real time users.

Not good enough. Any system shipping with this capability needs to have
a split lock free firmware blob. And the only way to make that happen is
to force enable it by default.

> From kernel point of view, we are working on a split lock free kernel.
> Some blocking split lock issues have been fixed in TIP tree.

Haven't we fixed them all by now?

> Only limited user apps can run on real time and should be split lock
> free before they are allowed to run on the real time system.

I'm thinking most of the normal Linux userspace will run just fine.
Seeing how other architectures have rejected such nonsense forever.

> In summary, the patch set only wants to enable the feature for real time
> and disable it by default.

We told you that wasn't good enough many times. Lot's of people run the
preemp-rt kernel on lots of different hardware. And like I said, even
cloudy folks would want this.

Features that require special firmware that nobody has are useless.

For giggles, run the below. You can notice your desktop getting slower.

---
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>

void main(void)
{
	void *addr = mmap(NULL, 4096*2, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
	unsigned int *var;
	if (addr == (void*)-1) {
		printf("fail\n");
		return;
	}

	var = addr + 4096 - 2;

	for (;;)
		asm volatile ("lock incl %0" : : "m" (*var));
}