linux-kernel - RE: CONFIG_ORC_UNWINDER=y breaks get

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 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:   Sat, 25 Sep 2021 19:07:02 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Jann Horn' <jannh@...gle.com>, Kees Cook <keescook@...omium.org>
CC:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Vito Caputo <vcaputo@...garu.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        Qi Zheng <zhengqi.arch@...edance.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "luto@...nel.org" <luto@...nel.org>
Subject: RE: CONFIG_ORC_UNWINDER=y breaks get_wchan()?

From: Jann Horn
> Sent: 24 September 2021 01:00
...
> > Normally wchan is protected by:
> >
> >         ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS)
> >
> > I might argue that this check isn't right -- it needs to be using
> > f_cred, but I'll let Jann answer more there.
> >
> > > ... since presumably proc_pid_wchan()'s use of '%ps' can result in an
> > > actual address getting printed if the unwind gets confused, thanks to
> > > __sprint_symbol()'s backup option if kallsyms_lookup_buildid() doesn't
> > > find a name.
> >
> > Ew, yeah, __sprint_symbol() falls back to exposing addresses. :(
> >
> >         name = kallsyms_lookup_buildid(address, &size, &offset, &modname, &buildid,
> >                                        buffer);
> >         if (!name)
> >                 return sprintf(buffer, "0x%lx", address - symbol_offset);
> 
> Whaaaat? That's not how wchan worked when I looked at this the last
> time a few years ago...

Hmmmm....
Historically (and I mean SYSV and probably BSD) the 'wchan'
was the 'token' passed to the kernel sleep() function and
value that needed to be passed to wakeup() to get the process
rescheduled.
It was usually the address of something associated with the
sleep - but didn't have to be.
Linux doesn't do process sleep/wakeup the same way.

The nearest thing would be 'struct wait_queue_head'.
But the address of that isn't a useful value.
Plausibly the address of the function that initialises
the wait_queue_head could be put into it and that
value saved by schedule() to that it can be returned
as the 'wchan'.

	David

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