linux-kernel - Re: [PATCH v6 3/6] fs/procfs: add build ID fetching to PROCMAP

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: <CAEf4Bzbj7zCUzh2thV-Wkk-YjX71tDLPjb=wc6ZF4HbG5nqPRw@mail.gmail.com>
Date: Mon, 8 Jul 2024 20:14:48 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Andrii Nakryiko <andrii@...nel.org>, linux-fsdevel@...r.kernel.org, brauner@...nel.org, 
	viro@...iv.linux.org.uk, akpm@...ux-foundation.org, 
	linux-kernel@...r.kernel.org, bpf@...r.kernel.org, gregkh@...uxfoundation.org, 
	linux-mm@...ck.org, liam.howlett@...cle.com, surenb@...gle.com, 
	rppt@...nel.org, adobriyan@...il.com
Subject: Re: [PATCH v6 3/6] fs/procfs: add build ID fetching to PROCMAP_QUERY API

On Mon, Jul 8, 2024 at 6:27 PM Andi Kleen <ak@...ux.intel.com> wrote:
>
> > So what exactly did you have in mind when you were proposing that
> > check? Did you mean to do a pass over all VMAs within the process to
> > check if there is at least one executable VMA belonging to
> > address_space? If yes, then that would certainly be way too expensive
> > to be usable.
>
> I was thinking to only report the build ID when the VMA queried
> is executable. If software wanted to look up a data symbol
> and needs that buildid it would need to check a x vma too.

I think that's way too restrictive and for no good reason, tbh. If
there is some .rodata ELF section mapped as r/o VMA, I don't see any
reason why user shouldn't be able to request build ID for it.

>
> Normally tools iterate over all the mappings anyways so this
> shouldn't be a big burden for them.
>

This API aims to make this unnecessary. So that tools can request only
relevant VMAs based on whatever captured data or code addresses it got
from, say, profiling of perf events. And if there are some locks or
other global data structures that fall into mapped portions of ELF
data sections, the ability to get build ID for those is just as
important as getting build ID for executable sections.

> Did I miss something?
>
> I guess an alternative would be a new VMA flag, but iirc we're low on
> bits there already.

I think we should just keep things as is. I don't think there is any
real added security in restricting this just to executable VMAs.

>
> -Andi