linux-kernel - Re: Aerospace and linux

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, 10 Jun 2010 13:42:55 -0600
From:	Brian Gordon <legerde@...il.com>
To:	Massimiliano Galanti <massiblue@...ero.it>
Cc:	Chris Friesen <cfriesen@...tel.com>, linux-kernel@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: Aerospace and linux

Sorry, I take it back.   This wont work for me because I wont have
NOR.   Also, I only want the "in-place" to apply to read-only pages.
This looks like all reads and writes get passed to the underlying
storage and I can't suffer flash page erase/writes to update a
variable. :)  The device will wear out and meaningful work would be
starved.

On Thu, Jun 10, 2010 at 1:37 PM, Brian Gordon <legerde@...il.com> wrote:
> Yes.  Thats exactly what I am looking for.   Even if there is a speed
> penalty, I wouldn't mind so much.  However wikipedia says that XIP is
> filesystem dependent and im stuck with FAT32 or NTFS.   Wikipedia
> claims NTFS can do XIP.   Is this true under linux?
>
> On Thu, Jun 10, 2010 at 1:23 PM, Massimiliano Galanti
> <massiblue@...ero.it> wrote:
>>
>>> What about .ro and .text sections of an executable?   I would think
>>> kernel support for that would be required.   If its application data,
>>> then all sorts of things are possible like you described.   Ive also
>>> seen critical ram variables be stored in triplicate and then
>>> compared/voted just to ensure no silent SEU corruption.
>>
>> Maybe slightly off topic but... if flash is safer than ram, what about using
>> XIP (where possible, e.g. on NORs)? That would not put .data sections into
>> ram, at least.
>>
>> --
>> Massimiliano
>>
>
--
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/