linux-kernel - Re: file offset corruption on 32-bit machines?

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:	Sat, 12 Apr 2008 10:48:08 +0200
From:	Pavel Machek <pavel@....cz>
To:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
Cc:	Bryan Henderson <hbryan@...ibm.com>, Bodo Eggert <7eggert@....de>,
	Diego Calleja <diegocg@...il.com>, Jan Kara <jack@...e.cz>,
	Jiri Kosina <jkosina@...e.cz>, linux-fsdevel@...r.kernel.org,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Michal Hocko <mhocko@...e.cz>, Meelis Roos <mroos@...ux.ee>
Subject: Re: file offset corruption on 32-bit machines?

Hi!

> > >So if you write multithreaded code and don't understand what locking
> > >around shared resources is for, then your application might break.
> > 
> > I think I know what locking around shared resources is for, which is why 
> > I'm surprised the kernel doesn't do it.
> > 
> > Is it normal for a kernel resource not to be thread-safe (i.e. you don't 
> > get advertised/sensible results if two threads access it at the same 
> > time)?
> 
> If two threads are changing one filehandle at the same time, then the
> program is broken.  I can't see how the kernel making updates to 64bit
> filehandles "atomic" helps.  You could still seek in one thread, then
> seek in another and then start the write in the first and get a wrong
> result.  Changes to a shared filehandle of any kind requires locking to
> work reliably, so additional slow downs and locking in the kernel won't
> fix anything.

Well, app may be broken, or it may be trying to confuse you.

If you were stracing app, it seeked at 1GB and at 7GB, then did
read(), you'd be certainly very surprised if it did read secret data
at 3GB, right?

And ptrace monitors do exist.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/