linux-kernel - RE: [PATCH 1/1 module-next] kallsyms: enhance %pS/s/b printing when KALLSYSMS is disabled

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>] [day] [month] [year] [list]

Message-ID: <20220322062219epcms5p1bc1cc758470ebf175aa4eee20b7837ae@epcms5p1>
Date:   Tue, 22 Mar 2022 11:52:19 +0530
From:   Maninder Singh <maninder1.s@...sung.com>
To:     Sergey Senozhatsky <senozhatsky@...omium.org>
CC:     "mcgrof@...nel.org" <mcgrof@...nel.org>,
        "pmladek@...e.com" <pmladek@...e.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "linux@...musvillemoes.dk" <linux@...musvillemoes.dk>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "wangkefeng.wang@...wei.com" <wangkefeng.wang@...wei.com>,
        Vaneet Narang <v.narang@...sung.com>,
        "swboyd@...omium.org" <swboyd@...omium.org>,
        "ojeda@...nel.org" <ojeda@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-modules@...r.kernel.org" <linux-modules@...r.kernel.org>,
        "avimalin@...il.com" <avimalin@...il.com>,
        "atomlin@...hat.com" <atomlin@...hat.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "ndesaulniers@...gle.com" <ndesaulniers@...gle.com>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "void@...ifault.com" <void@...ifault.com>
Subject: RE: [PATCH 1/1 module-next] kallsyms: enhance %pS/s/b printing when
 KALLSYSMS is disabled

Hi Sergey,

> > +                if (add_offset) {
> > +                        base = mod->core_layout.base;
> > +                        offset = value - (unsigned long)base;
> > +                }
> 
> What if address is in module init? Shouldn't this be something like
> 
>         if (within_module_init(value, mod))
>                 offset = value - (unsigned long)mod->init_layout.base;
>         else
>                 offset = value - (unsigned long)mod->core_layout.base;

Yes, this can be done, but I think then we need to handle it with some more info.

In module allocation first we load core_layout and then init_layout w.r.t address range
as below (ARM64):

ffff800000eb0000 -> core_layout
ffff800000eb4000 -> init_layout

So if we write only offset(w.r.t core_layout), then user can get a hint if it going beyond normal text
then it means it is init text.

But if we take offset from init and core separately, and we only print the offset (not function name),
we need to write alongwith offset that it is init or core area.
Otherwise user will get confused which offset it is, whether to check init or core text area.

And also while printing modules, kernel also uses core_layout as base address only:

static int m_show(struct seq_file *m, void *p)
{
..
        /* Used by oprofile and other similar tools. */
        value = m->private ? NULL : mod->core_layout.base;
        seq_printf(m, " 0x%px", value);
..
}

and also normal %ps prints like below:

ps 0xffff800000eb4004
load address of module is 0xffff800000eb0000
so normal offset is 4004 for init text section.

and same thing is printed with current patch:
pS 0xffff800000eb0000+0x4004 [crash]

Still if we need to handle separately, then please suggest only offset is ok or we need to
add string for init or core also like below:

   init_text start + offset
pS 0xffff800000eb4000+0x4 [crash init_text]

And also then there will be discrepancy for rodata or other sections, which offset to take.
If we are taking it from core_layout then init section can also be taken with same.
As of now it is unique offset calculation for all sections.

Thanks,
Maninder Singh