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: <bbe02e79355c42139d3b7fcc15344474@AcuMS.aculab.com>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ