linux-kernel - Re: [RFC] persistent store (version 2) (part 1 of 2)

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:	Thu, 2 Dec 2010 08:19:18 -0800
From:	Tony Luck <tony.luck@...el.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...e.hu" <mingo@...e.hu>, "greg@...ah.com" <greg@...ah.com>,
	"Huang, Ying" <ying.huang@...el.com>,
	Borislav Petkov <bp@...en8.de>,
	David Miller <davem@...emloft.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Kyungmin Park <kmpark@...radead.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [RFC] persistent store (version 2) (part 1 of 2)

On Thu, Dec 2, 2010 at 2:12 AM, Andrew Morton <akpm@...ux-foundation.org> wrote:
> One thing which does leap out of the v2 implementation is the hardwired
> assumption that there is one store kernel-wide.  I suppose that's OK as
> a version-1 implementation detail thing, but we should avoid hardwiring
> that assumption into the presentation of v1's userspace interfaces.

I think that user space should be able to survive the change to
multiple storage devices.  We can just read all the records from
all the devices and present each one as a file. We just need to
remember where they came from so we cal call the right erase
function when the user unlinks the file.  Unless there is some
reason why we'd want to make it visible to the user which storage
was being used? But even then, the user interface wouldn't change
we could just have each device register a string to be included in
the filename. Users could look at it if they cared, or ignore it if
they don't care. The "type" of the data should stay at the front
of the name so userspace can do "for f in dmesg*" to look at
al the saved console logs, and it wouldn't matter if the files were
"dmesg-0", "dmesg-1" or "dmesg-erst-0", "dmesg-erst-1". I
can't quite see why anyone would care which device was used,
but the option to provide it would be there without breaking
apps that used the v1 interface.

The tricky part of multiple devices is the write side ... how to
decide which records should be stored in which device. I can
imagine lots of possibilities (store by type, round-robin, use
one until full then move on, look at the size of the data to be
stored and save in the device with the smallest record size
that could hold the data, ...) but I'm just making stuff up - I
don't know how someone with two or more devices would
actually want to assign them ... hence I'm leaving this as
an exercise to someone with more than one device :-)

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