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] [day] [month] [year] [list]
Message-ID: <202110212033.D533BAF@keescook>
Date:   Thu, 21 Oct 2021 20:35:07 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Mark Rutland <mark.rutland@....com>,
        Shuah Khan <shuah@...nel.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        linux-kselftest@...r.kernel.org,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Alexey Gladkov <gladkov.alexey@...il.com>,
        Jann Horn <jannh@...gle.com>,
        Vito Caputo <vcaputo@...garu.com>,
        Ingo Molnar <mingo@...hat.com>, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, mgorman@...e.de,
        bristot@...hat.com,
        Christian Brauner <christian.brauner@...ntu.com>,
        amistry@...gle.com, Kenta.Tada@...y.com, legion@...nel.org,
        michael.weiss@...ec.fraunhofer.de, Michal Hocko <mhocko@...e.com>,
        deller@....de, Qi Zheng <zhengqi.arch@...edance.com>, me@...in.cc,
        tycho@...ho.pizza, Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, Jens Axboe <axboe@...nel.dk>,
        metze@...ba.org, Lai Jiangshan <laijs@...ux.alibaba.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        ohoono.kwon@...sung.com, kaleshsingh@...gle.com,
        yifeifz2@...inois.edu, linux-arch@...r.kernel.org,
        vgupta@...nel.org, "Russell King (Oracle)" <linux@...linux.org.uk>,
        Will Deacon <will@...nel.org>, guoren@...nel.org,
        bcain@...eaurora.org, monstr@...str.eu, tsbogend@...ha.franken.de,
        nickhu@...estech.com, jonas@...thpole.se,
        Michael Ellerman <mpe@...erman.id.au>,
        Paul Walmsley <paul.walmsley@...ive.com>, hca@...ux.ibm.com,
        ysato@...rs.sourceforge.jp, davem@...emloft.net, chris@...kel.net,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] selftests: proc: Make sure wchan works when it exists

On Thu, Oct 21, 2021 at 05:39:38PM -0700, Andy Lutomirski wrote:
> 
> 
> On Thu, Oct 21, 2021, at 1:12 PM, Kees Cook wrote:
> > On Thu, Oct 21, 2021 at 01:03:33PM -0700, Andy Lutomirski wrote:
> >> 
> >> 
> >> On Fri, Oct 8, 2021, at 4:55 PM, Kees Cook wrote:
> >> > This makes sure that wchan contains a sensible symbol when a process is
> >> > blocked. Specifically this calls the sleep() syscall, and expects the
> >> > architecture to have called schedule() from a function that has "sleep"
> >> > somewhere in its name. For example, on the architectures I tested
> >> > (x86_64, arm64, arm, mips, and powerpc) this is "hrtimer_nanosleep":
> >> 
> >> Is this really better than admitting that the whole mechanism is nonsense and disabling it?
> >> 
> >> We could have a fixed string for each task state and call it a day.
> >
> > I consider this to be "future work". In earlier discussions it came up,
> > but there wasn't an obvious clean cost-free way to do this, so instead
> > we're just fixing the broken corner and keeping the mostly working rest
> > of it while cleaning up the weird edges. :)
> 
> True, but we have the caveat that wchan is currently broken, so in some sense we have an easier time killing it now as compared to later.  But if we don't have a fully-fleshed-out idea for how to kill it, then I'm fine with waiting.

It's not actually that broken. Only ORC was fully broken, so all the
other architectures (and non-ORC x86) have been fine. But given the
method of fixing ORC vs wchan, it turns out we could further clean up
the other architectures. But yes, no real plan to remove it, but the
current series fixes things pretty well. :)

-Kees

> 
> >
> > -- 
> > Kees Cook

-- 
Kees Cook

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ