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:   Thu, 23 Sep 2021 18:34:08 -0700
From:   Vito Caputo <>
To:     Kees Cook <>
Cc:     Jann Horn <>, Thomas Gleixner <>,
        Josh Poimboeuf <>,
        Ingo Molnar <>, Borislav Petkov <>,
        "H. Peter Anvin" <>, Jens Axboe <>,
        Mark Rutland <>,
        Peter Zijlstra <>,
        Stefan Metzmacher <>,
        Andy Lutomirski <>,
        Lai Jiangshan <>,
        Christian Brauner <>,
        Andrew Morton <>,
        "" <>,
        Daniel Bristot de Oliveira <>,
        Michael WeiƟ <>,
        Anand K Mistry <>,
        Alexey Gladkov <>,
        Michal Hocko <>, Helge Deller <>,
        Dave Hansen <>,
        Andrea Righi <>,
        Ohhoon Kwon <>,
        Kalesh Singh <>,
        YiFei Zhu <>,
        "Eric W. Biederman" <>,,,,
Subject: Re: [PATCH] proc: Disable /proc/$pid/wchan

On Thu, Sep 23, 2021 at 06:16:16PM -0700, Kees Cook wrote:
> On Thu, Sep 23, 2021 at 05:22:30PM -0700, Vito Caputo wrote:
> > Instead of unwinding stacks maybe the kernel should be sticking an
> > entrypoint address in the current task struct for get_wchan() to
> > access, whenever userspace enters the kernel?
> wchan is supposed to show where the kernel is at the instant the
> get_wchan() happens. (i.e. recording it at syscall entry would just
> always show syscall entry.)

And you have the syscall # onhand when performing the syscall entry,

The point is, if the alternative is to always get 0 from
/proc/PID/wchan when a process is sitting in ioctl(), I'd be perfectly
happy to get back sys_ioctl.  I'm under the impression there's quite a
bit of vendor-specific flexibility here in terms of how precise WCHAN

If it's possible to preserve the old WCHAN precision I'm all for it.
But if we've become so paranoid about leaking anything about the
kernel to userspace that this is untenable, even if it just spits out
the syscall being performed that has value.

Vito Caputo

Powered by blists - more mailing lists