linux-kernel - Re: Linux 3.18 released

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: <20141209110614.GA24745@gmail.com>
Date:	Tue, 9 Dec 2014 12:06:14 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Vince Weaver <vince@...ter.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: Linux 3.18 released


* Ingo Molnar <mingo@...nel.org> wrote:

> 
> * Vince Weaver <vince@...ter.net> wrote:
> 
> > On Sun, 7 Dec 2014, Linus Torvalds wrote:
> > 
> > > I'd love to say that we've figured out the problem that 
> > > plagues 3.17 for a couple of people, but we haven't. At the 
> > > same time, there's absolutely no point in having everybody 
> > > else twiddling their thumbs when a couple of people are 
> > > actively trying to bisect an older issue, so holding up the 
> > > release just didn't make sense. Especially since that would 
> > > just have then held things up entirely over the holiday 
> > > break.
> > > 
> > > So the merge window for 3.19 is open, and DaveJ will 
> > > hopefully get his bisection done (or at least narrow things 
> > > down sufficiently that we have that "Ahaa" moment) over the 
> > > next week. But in solidarity with Dave (and to make my life 
> > > easier too ;) let's try to avoid introducing any _new_ 
> > > nasty issues, ok?
> > 
> > It's probably unrelated to DaveJ's issue, but my perf_event 
> > fuzzer still quickly locks the kernel pretty solid on 3.18.
> 
> I'm really tempted to restrict most of the weirder perf ABI 
> details (such as event groups, raw events, etc.) to root only 
> (with a perf_event_paranoid level to make it available for 
> power users and distros so inclined) - most of the past 
> lockups/races you have triggered were in such weird, seldom 
> used corners of the perf ABI that doesn't get much testing 
> outside Trinity fuzzing.
> 
> The bits used by tools/perf and used by the majority of users 
> are generally rock solid.

Note that it's entirely possible that I'm wrong about that 
suspicion, that the leftover bug(s?) are still in the core 
portion of perf.

Maybe fuzzing could help there: initially only fuzz core portions 
of perf ABI (bits that things like tools/perf uses on an everyday 
basis), then the rarer bits? If we knew it that it's say the 
cgroups bits or tracepoint integration of perf that is causing 
the trouble, that would already narrow down the inquiry quite a 
bit.

> Doing that is not a fix obviously and we'd like to fix all 
> pending bugs for real as well, but would at least isolate the 
> impact to root-only until it's fixed.

Thanks,

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