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  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]
Date:   Fri, 22 May 2020 08:12:59 +0300
From:   Emmanuel Grumbach <>
To:     Brian Norris <>
Cc:     Luis Chamberlain <>,
        Johannes Berg <>,
        linux-wireless <>,,,
        Daniel Vetter <>,,,,, Takashi Iwai <>,,,,
        Kees Cook <>,
        Arnd Bergmann <>,,
        Steven Rostedt <>,,,
        Andy Shevchenko <>,
        Kalle Valo <>,
        "<>" <>,, Linux Kernel <>,, Andrew Morton <>,
        "David S. Miller" <>
Subject: Re: [PATCH v2 12/15] ath10k: use new module_firmware_crashed()

> On Tue, May 19, 2020 at 10:37 PM Emmanuel Grumbach <> wrote:
> > So I believe we already have this uevent, it is the devcoredump. All
> > we need is to add the unique id.
> I think there are a few reasons that devcoredump doesn't satisfy what
> either Luis or I want.
> 1) it can be disabled entirely [1], for good reasons (e.g., think of
> non-${CHIP_VENDOR} folks, who can't (and don't want to) do anything
> with the opaque dumps provided by closed-source firmware)

Ok, if all you're interested into is the information that this event
happen (as opposed to report a bug and providing the data), then I
agree. True, not everybody want or can enable devcoredump. I am just a
bit concerned that we may end up with two interface that notify the
same event basically. The ideal maybe would be to be able to
optionally reduce the content of the devoredump to nothing more that
is already in the dmesg output. But then, it is not what it is meant
to be: namely, a core dump..

> 2) not all drivers necessarily have a useful dump to provide when
> there's a crash; look at the rest of Luis's series to see the kinds of
> drivers-with-firmware that are crashing, some of which aren't dumping
> anything

Fair enouh.

> 3) for those that do support devcoredump, it may be used for purposes
> that are not "crashes" -- e.g., some provide debugfs or other knobs to
> initiate dumps, for diagnostic or debugging purposes

Not sure I really think we need to care about those cases, but you
already have 2 good arguments :)

> Brian
> [1] devcd_disabled

Powered by blists - more mailing lists