On Thu, Oct 7, 2021 at 11:13 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > On Thu, Oct 07, 2021 at 10:50:24AM -0700, Suren Baghdasaryan wrote: > > On Thu, Oct 7, 2021 at 10:31 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > > > On Thu 07-10-21 09:58:02, Suren Baghdasaryan wrote: > > > > On Thu, Oct 7, 2021 at 9:40 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > > > > > > > On Thu 07-10-21 09:04:09, Suren Baghdasaryan wrote: > > > > > > On Thu, Oct 7, 2021 at 3:15 AM Pavel Machek <pavel@xxxxxx> wrote: > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > >> Hmm, so the suggestion is to have some directory which contains files > > > > > > > > >> representing IDs, each containing the string name of the associated > > > > > > > > >> vma? Then let's say we are creating a new VMA and want to name it. We > > > > > > > > >> would have to scan that directory, check all files and see if any of > > > > > > > > >> them contain the name we want to reuse the same ID. > > > > > > > > > > > > > > > > > > I believe Pavel meant something as simple as > > > > > > > > > $ YOUR_FILE=$YOUR_IDS_DIR/my_string_name > > > > > > > > > $ touch $YOUR_FILE > > > > > > > > > $ stat -c %i $YOUR_FILE > > > > > > > > > > > > Ah, ok, now I understand the proposal. Thanks for the clarification! > > > > > > So, this would use filesystem as a directory for inode->name mappings. > > > > > > One rough edge for me is that the consumer would still need to parse > > > > > > /proc/$pid/maps and convert [anon:inode] into [anon:name] instead of > > > > > > just dumping the content for the user. Would it be acceptable if we > > > > > > require the ID provided by prctl() to always be a valid inode and > > > > > > show_map_vma() would do the inode-to-filename conversion when > > > > > > generating maps/smaps files? I know that inode->dentry is not > > > > > > one-to-one mapping but we can simply output the first dentry name. > > > > > > WDYT? > > > > > > > > > > No. You do not want to dictate any particular way of the mapping. The > > > > > above is just one way to do that without developing any actual mapping > > > > > yourself. You just use a filesystem for that. Kernel doesn't and > > > > > shouldn't understand the meaning of those numbers. It has no business in > > > > > that. > > > > > > > > > > In a way this would be pushing policy into the kernel. > > > > > > > > I can see your point. Any other ideas on how to prevent tools from > > > > doing this id-to-name conversion themselves? > > > > > > I really fail to understand why you really want to prevent them from that. > > > Really, the whole thing is just a cookie that kernel maintains for memory > > > mappings so that two parties can understand what the meaning of that > > > mapping is from a higher level. They both have to agree on the naming > > > but the kernel shouldn't dictate any specific convention because the > > > kernel _doesn't_ _care_. These things are not really anything actionable > > > for the kernel. It is just a metadata. > > > > The desire is for one of these two parties to be a human who can get > > the data and use it as is without additional conversions. > > /proc/$pid/maps could report FD numbers instead of pathnames, which > > could be converted to pathnames in userspace. However we do not do > > that because pathnames are more convenient for humans to identify a > > specific resource. Same logic applies here IMHO. > > Yes, please. It really seems like the folks that are interested in this > feature want strings. (I certainly do.) For those not interested in the > feature, it sounds like a CONFIG to keep it away would be sufficient. > Can we just move forward with that? Would love to if others are ok with this. > > -- > Kees Cook
