Re: file offset corruption on 32-bit machines?

[Jan Kara]

On Fri 11-04-08 09:55:44, Lennart Sorensen wrote:
> 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".
  Well, as Jiri Kosina wrote, this isn't a problem unless someone finds
a way how to use this race for some attack (and for example making f_pos
negative compromises security so it is not so far-fetched as it would
seem). So proactively fixing this makes some sence.

								Honza
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/