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]

Message-ID: <20080411135544.GG2160@csclub.uwaterloo.ca>
Date:	Fri, 11 Apr 2008 09:55:44 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Bodo Eggert <7eggert@....de>
Cc:	Diego Calleja <diegocg@...il.com>, Jiri Kosina <jkosina@...e.cz>,
	Jan Kara <jack@...e.cz>, Michal Hocko <mhocko@...e.cz>,
	Meelis Roos <mroos@...ux.ee>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org
Subject: Re: file offset corruption on 32-bit machines?

On Fri, Apr 11, 2008 at 02:24:34PM +0200, Bodo Eggert wrote:
> AS far as I understand, the race is e.g.:
> 
> fpos := A:a, we want to make process/thread a read A:b or B:a without it
> being a correct value in fpos. a!=b!=c, A!=B, A!=C.
> 
> a: read fpos.high (A:?)
> b: write fpos (B:b)
> a: read fpos.low (A:b)
> 
> 
> If you change this to 
> 
> a: read fpos.high
> a: read fpos.low
> a: read fpos.high
> a: read fpos.low
> 
> and compare the results, you need to
> 
> a: read fpos.high (A:?)
> b: write fpos (B:b)
> a: read fpos.low (A:b)
> b: write fpos (A:c)
> a: read fpos.high (A:b),(A:?)
> b: write fpos (C:b)
> a: read fpos.low (A:b),(A:b)
> 
> That would be winning three races in order to hit the bug. 
> 
> 
> OTOH, writers MUST NOT be interrupted, because:
> 
> b: write fpos.high (B:a)
> a: read fpos.high (B:?)
> a: read fpos.low (B:a)
> a: read fpos.high (B:a),(B:?)
> a: read fpos.low (B:a),(B:a)
> b: write fpos.low (B:b)

So if you write multithreaded code and don't understand what locking
around shared resources is for, then your application might break.  Can
you give an example where locking is being used correctly where this can
possibly fail?  The kernel can't prevent idiots from writing bad code
that breaks.

I just don't get this "problem".

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