linux-kernel - Re: [PATCH 1/3] thunderbolt: Make the driver less verbose

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180905095451.GI2283@lahna.fi.intel.com>
Date:   Wed, 5 Sep 2018 12:54:51 +0300
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     linux-kernel@...r.kernel.org,
        Andreas Noever <andreas.noever@...il.com>,
        Michael Jamet <michael.jamet@...el.com>,
        Yehezkel Bernat <YehezkelShB@...il.com>
Subject: Re: [PATCH 1/3] thunderbolt: Make the driver less verbose

On Wed, Sep 05, 2018 at 11:05:10AM +0200, Lukas Wunner wrote:
> On Mon, Sep 03, 2018 at 04:33:02PM +0300, Mika Westerberg wrote:
> > Currently the driver logs quite a lot to the system message buffer even
> > when doing normal operations. This information is not useful for
> > ordinary users and might even annoy some.
> 
> No, the verbose logging is done on purpose to aid us in reverse-engineering
> the protocol.  For example ...
> 
> > -	tb_port_info(port, "  Unknown1: %#x Unknown2: %#x Unknown3: %#x\n",
> > -		     hop->unknown1, hop->unknown2, hop->unknown3);
> 
> ... why do you think we're logging these seemingly stupid unknown
> bitfields?  Because whenever someone posts dmesg output they
> inadvertantly post the contents of those unknown fields and we can
> then google the value of those fields on various controllers and
> machines and deduce their possible meaning.

And the majority of people get tons of completely useless messages
filling their dmesgs? No, I don't think that's a good thing.

> By muting those messages, you're taking away our reverse enginering aids
> without having released the spec, which would indeed obviate the need
> for them.  Please don't do that.  Release the spec, *then* you can
> mute the messages.  Not the other way round.

All the possible messages are most likely logged already and available
by Googling so even if we mute the driver now, you still can find those
messages in the wild. Anything running on Alpine Ridge and higher does
not require reverse-engineering (even on Apple systems) because those
are already supported in the driver.