linux-kernel - Re: [PATCH RESEND] eventfd: prepare id to userspace via fdinfo

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: <20190320120525.3ed8d21648ea8a573bbd4acf@linux-foundation.org>
Date:   Wed, 20 Mar 2019 12:05:25 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Masatake YAMATO <yamato@...hat.com>
Cc:     linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
        linux-fsdevel@...r.kernel.org, Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH RESEND] eventfd: prepare id to userspace via fdinfo

On Wed, 20 Mar 2019 18:29:29 +0900 Masatake YAMATO <yamato@...hat.com> wrote:

> Finding endpoints of an IPC channel is one of essential task to
> understand how a user program works. Procfs and netlink socket provide
> enough hints to find endpoints for IPC channels like pipes, unix
> sockets, and pseudo terminals. However, there is no simple way to find
> endpoints for an eventfd file from userland. An inode number doesn't
> hint. Unlike pipe, all eventfd files share the same inode object.
> 
> To provide the way to find endpoints of an eventfd file, this patch
> adds "eventfd-id" field to /proc/PID/fdinfo of eventfd as identifier.
> Address for eventfd context is used as id.
> 
> A tool like lsof can utilize the information to print endpoints.
> 
> ...
>
> --- a/fs/eventfd.c
> +++ b/fs/eventfd.c
> @@ -297,6 +297,7 @@ static void eventfd_show_fdinfo(struct seq_file *m, struct file *f)
>  	seq_printf(m, "eventfd-count: %16llx\n",
>  		   (unsigned long long)ctx->count);
>  	spin_unlock_irq(&ctx->wqh.lock);
> +	seq_printf(m, "eventfd-id: %p\n", ctx);
>  }
>  #endif

Is it a good idea to use a bare kernel address for this?  How does this
interact with printk pointer randomization and hashing?