| 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
| ||
|
Date: Tue, 03 Aug 2010 11:25:57 -0500 From: Eric Sandeen <sandeen@...hat.com> To: Dmitry Monakhov <dmonakhov@...nvz.org> CC: Bo Brantén <bosse@....umu.se>, linux-ext4@...r.kernel.org Subject: Re: persistent preallocation On 08/03/2010 06:18 AM, Dmitry Monakhov wrote: > Bo Brantén <bosse@....umu.se> writes: > >> Hello, >> >> I have a question on the implementation of persistent preallocation, >> the reason to not return the disk block is because it can contain old >> data but I wonder if an implementation has to return zeros instead or > Please look at fallocate(2) syscall. >> if it could return any garbage as long as it is not _that_ garbage? > Off course it is not a garbage, it is old user's data which may be > very very useful (old passwords, cookies, and etc)for person who has > time to analyze it :) I think the question was, could the implementation return 0xFF rather than what is actually on disk (and rather than 0's) when reading a preallocated block. You could certainly write it that way, but I don't know why you would want to... IOW it wouldn't be posix_fallocate() or fallocate(), it'd be junk_preallocate() or something. -Eric >> >> Bo Branten >> -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists