linux-kernel - Re: [PATCH] Make efi-pstore return a unique id

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

Message-ID: <87txf5n9oc.fsf@gmail.com>
Date:	Thu, 21 Nov 2013 21:53:07 +0800
From:	Madper Xie <bbboson@...il.com>
To:	Seiji Aguchi <seiji.aguchi@....com>
Cc:	Madper Xie <cxie@...hat.com>, Richard Weinberger <richard@....at>,
	Tony Luck <tony.luck@...il.com>,
	"matt.fleming\@intel.com" <matt.fleming@...el.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Linux EFI <linux-efi@...r.kernel.org>,
	谢成骏 <bbboson@...il.com>
Subject: Re: [PATCH] Make efi-pstore return a unique id


seiji.aguchi@....com writes:

>> Then will lost the sequence of our log. We will get lots of entries like
>> "dmesg-efi-`unique but meaningless number here`" in pstore fs. Who will
>> know which file is the latest record?
>
> Ah, that's good point.
>
>> And another side, the combin of timestamp, count and part is unique. Why
>> we generate a unique number from a unique number?
>> if you think "making a string from three ints and then a parse it to a
>> int again" is odd, i'd like to use ((timestamp * 100 + part) * 100 +
>> count.
>
> How about calculating the number of digit of part /count, instead of using fixed "100"?
> We can ensure the uniqueness of each id by doing it.
>
> digit_num = log2(part)/log2(10) + 1
> timestamp * 10^(digit_num + 1)
>
Then we must implement a log10 and a pow func...
And reverting id to timestamp, part and count will hard if we using
unfixed length of count and id.

So i'd like to using fixed length. My dell xps has 128kb nvram
space. and it at most store 126 pstore entries. So I think 1000 will be
a safe value for count. For part, 100 should be okay. I don't think
there will be a large kmsg and we must split it into more than 100 parts.

> Seiji

--
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/