linux-kernel - Re: Re: [RFC PATCH 0/5] Add a hash value for each line in /dev/kmsg

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]

Date:	Mon, 29 Jul 2013 14:46:06 +0200
From:	Kay Sievers <kay@...y.org>
To:	Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>
Cc:	linux-kernel@...r.kernel.org, yrl.pp-manager.tt@...achi.com,
	akpm@...ux-foundation.org, gregkh@...uxfoundation.org,
	davem@...emloft.net, itoukzo@...data.co.jp
Subject: Re: Re: [RFC PATCH 0/5] Add a hash value for each line in /dev/kmsg

On Mon, Jul 29, 2013 at 1:54 PM, Hidehiro Kawai
<hidehiro.kawai.ez@...achi.com> wrote:

> Also, I heard about the discussion
> at the kernel summit 2 years ago.  According to the article of LWN,
> it seems that Linus objected your approach (i.e. adding random bit as
> message ID).  Were there some agreements on this issue at the kernel summit?

No, there are no further discussions about this.

Pre-allocated, static, randomly created 128-bit IDs are just the
simplest and most robust option to identify messages. It's an
unmanaged namespace that needs no coordination, the IDs are always
stable, never change and are guaranteed to be unique. None of the
hashing-of-the strings solutions can provide that by default.

I would expect that over time, the automatic hashes would end up
becoming static numbers explicitly add to the messages anyway, because
changing the message text will change the hash, which is nothing we
really want to deal with. For that reason, I think that we can add the
ID right away, without any of the hashing; and do that only for a very
tiny fraction of the messages where such IDs make sense and add value.

Message IDs is how userspace logging works today; so from the
userspace side this would fit into the already existing
infrastructure, while possibly changing hashes which require another
type of translation catalog would not.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/