linux-kernel - Re: [PATCH 4/4] firewire: fw-core: react on bus resets while the config ROM is being fetched

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: <4798E664.2040405@redhat.com>
Date:	Thu, 24 Jan 2008 14:26:28 -0500
From:	Jarod Wilson <jwilson@...hat.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
CC:	Kristian Høgsberg <krh@...hat.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] firewire: fw-core: react on bus resets while the
 config ROM is being fetched

Jarod Wilson wrote:
> Stefan Richter wrote:
>> read_rom() obtained a fresh new fw_device.generation for each read
>> transaction.  Hence it was able to continue reading in the middle of the
>> ROM even if a bus reset happened.  However the device may have modified
>> the ROM during the reset.  We would end up with a corrupt fetched ROM
>> image then.
>>
>> Although all of this is quite unlikely, it is not impossible.
>> Therefore we now restart reading the ROM if the bus generation changed.
>>
>> Side note:  The barrier in read_rom(), inserted by patch "firewire:
>> enforce access order between generation and node ID" is not necessary
>> anymore because the sequence of calls
>> 	fw_device_init() ->
>> 		read_bus_info_block() ->
>> 			read_rom()
>> 			read_rom()
>> 			read_rom()
>> 			...
>> will take care that generation is read before node_id, won't it?
>>
>> Signed-off-by: Stefan Richter <stefanr@...6.in-berlin.de>
> 
> Based on a quick read through the code path, coupled with empirical evidence,
> yes, it appears safe to remove the barrier in read_rom().

Crap. My earlier 'empirical evidence' seems to have been happy coincidence.
After a fresh boot, I'm consistently hitting 'failed to read config rom'
failures with this patch applied. Simply putting the barrier back in gets
things working again though. Interestingly, subsequent reloading of firewire-*
modules less the barrier also tend to work until the system is rebooted.


-- 
Jarod Wilson
jwilson@...hat.com

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