linux-kernel - RE: [PATCH 0/2] make all stored entries accessible.

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

Message-ID: <A5ED84D3BB3A384992CBB9C77DEDA4D47F9DBBA3@USINDEM103.corp.hds.com>
Date:	Thu, 31 Oct 2013 23:22:55 +0000
From:	Seiji Aguchi <seiji.aguchi@....com>
To:	"Luck, Tony" <tony.luck@...el.com>, Madper Xie <bbboson@...il.com>
CC:	Madper Xie <cxie@...hat.com>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"ccross@...roid.com" <ccross@...roid.com>,
	"anton@...msg.org" <anton@...msg.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 0/2] make all stored entries accessible.

> I also like option 1 ... but I think the "id" should be a persistent value for
> a given saved record.  So some func(timestamp, part, count) would be a
> good idea.  If we try using "sequential" numbers - and don't manage to
> clear out /sys/fs/pstore each time - then we may have the same "dmesg"
> file show up with different names on each boot.
> 
> Right now I have a simple script to save & clear ... not much more
> complex than:
> 
> 	cd /sys/fs/pstore
> 	cp * /var/log/save-pstore
> 	rm *
> 
> This depends on not re-using filenames (otherwise new files in pstore
> might overwrite older saved files in my /var/log/save-pstore area).

I see.. It is a persuasive use case.

(1) I agree that some func(timestamp, part, count) would be  good idea.
      This might work, although an overflow will happen some time...
      sprintf(id_str, "%lld%d%d", timestamp, part, count)
      simple_str_to_ull(id_str, &id, base)
 
(2) There is a GetNextHighMonotonicCount() runtime service in EFI specification
       to get a persistent number across the reboot, but I'm not sure if it is safe to use it..
      Also,  it would be good if we can create the id by ourselves, rather than using firmware.

 (3) Also, (it might not be good idea),  if a pstore filesystem expects all backend drivers
       to use the persistent id, the pstore should provide it by itself.
       (by using time stamp counter or something like that.)

       As I looked into the ramoops's code. It seems to use a non-persistent sequential counter,by initializing
       read_cnt to "0" in ramoops_pstore_open(), and incrementing it in ramoops_pstore_read().
       It doesn't seem to be the pstore's expectation. 
       And when someone introduces a new driver, they may misunderstand how to create the id as well..

As above, there are mutiple ideas, but (1) is reasonable to me.    
 
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/