linux-kernel - RE: [PATCH 0/8][RFC] IO latency/throughput fixes

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, 6 Apr 2009 15:52:50 -0700
From:	"Hua Zhong" <hzhong@...il.com>
To:	"'Ray Lee'" <ray-lk@...rabbit.org>
Cc:	"'Theodore Tso'" <tytso@....edu>,
	"'Linus Torvalds'" <torvalds@...ux-foundation.org>,
	"'Jens Axboe'" <jens.axboe@...cle.com>,
	"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 0/8][RFC] IO latency/throughput fixes

> Security on an embedded device starts with controlling physical
> access. If they have access to the storage media all bets are off,
> whether it's data=ordered or not. (Access to the storage media is
> really what we're talking about here -- medical data, for example,
> hitting the platter before the metadata updates that then make that
> data unaccessible to other userspace processes.)
> 
> Because *if* they have access to the media, they can replace any
> running code on that box, and your security is worthless.
> 
> So no, I don't see how that's a valid argument.

The problem with security has nothing to do with embedded. It's 
that when you commit metadata first and crash before you write 
the data, then you get to see random blocks which might contain 
sensitive information from other users.

Hua


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