linux-kernel - Re: module: add debugging alias parsing support

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: <CAEiveUc3d=b3p5+c2Drdj0ZgJM18Kt6fy6cF6nfTU6kk1H5htg@mail.gmail.com>
Date:   Mon, 4 Dec 2017 10:01:02 +0100
From:   Djalal Harouni <tixxdz@...il.com>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Jessica Yu <jeyu@...nel.org>, Jessica Yu <jeyu@...hat.com>,
        Rusty Russell <rusty@...tcorp.com.au>,
        Kees Cook <keescook@...omium.org>, mbenes@...e.cz,
        atomlin@...hat.com, Petr Mladek <pmladek@...e.com>, hare@...e.com,
        James Morris <james.l.morris@...cle.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "David S . Miller" <davem@...emloft.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: module: add debugging alias parsing support

On Thu, Nov 30, 2017 at 7:39 PM, Luis R. Rodriguez <mcgrof@...nel.org> wrote:
> On Thu, Nov 30, 2017 at 02:17:11PM +0100, Jessica Yu wrote:
>> Just some quick questions - are there any plans to use these in-kernel
>> module aliases anywhere else? Or are you using them just for debugging?
>
> As-is for now just debugging, but this could also more easily enable folks to
> prototype further evaluation of its uses. IMHO just having this at least posted
> online should suffice the later aspect of enabling folks to prototype.

I confirm that, after the module auto-load discussion where it is
clear that we need to improve the infrastructure, this debug
information may save some time, maybe someone can automate a script go
through modules and then on filesystem, however these patches may show
which module lead to load another one, right ? on userspace if there
are multiple dependencies it can be difficult I think.


>
> You're right that one can find aliases in userspace. One of the benefits
> of having this dump things on the kernel log is just that you can easily
> get the aliases printed out for all modules actually loaded for your system
> without much effort. I did find this useful when debugging and found it much
> more convenient than scraping modules one by one by hand in userspace.
>
> I had this implemented since 2016, and I had some ideas to use them in a
> functional way, however I first had to knock out a series of of fixes for
> kernel/kmod.c and setting up a baseline test infrastructure for kmod
> (tools/testing/selftests/kmod/ and lib/test_kmod.c) as such I hadn't had time
> to yet come around and finish benchmarking the alias enhancement ideas I had
> started evaluating.
>
> As such having aliases in-kernel currently are only useful for debugging and
> prototyping.

I would say so, however no strong argument if it should be mainlined.
Luis in your commit log you say:

"Obviously userspace can be buggy though, and it can lie to us. We
currently have no easy way to determine this."

Could you please share some info here ? how userspace can be buggy ?

Thank you!

>   Luis



-- 
tixxdz