linux-kernel - Re: remote debugging via FireWire * __fast_

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4755D186.20204@s5r6.in-berlin.de>
Date:	Tue, 04 Dec 2007 23:15:34 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Bernhard Kaindl <bkaindl@...i.org>
CC:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Andi Kleen <ak@...e.de>, Bernhard Kaindl <bk@...e.de>,
	linux-kernel@...r.kernel.org
Subject: Re: remote debugging via FireWire * __fast__ firedump!

Bernhard Kaindl wrote:
> The biggest block size that worked here was 2048 bytes, which was
> enough to get nearly 10MB/s of data transfer rate from the remote
> memory to disk.

The maximum payload size of block requests depends on three things:
1. speed of the connection between the two nodes (debugged machine and
debugging machine), 2. link layer controllers of the two nodes, 3.
software on the debugging machine.

1.) S100: 512 bytes, S200: 1024 bytes, S400: 2048 bytes, S800 and more:
4096 bytes.

2.) Controllers on CardBus cards are limited to 1024 bytes payload of
asynchronous packets, for reasons I don't know.  The other available
controllers only have the above mentioned speed-dependent limit.

3.) The ohci1394 driver has an implementation limitation which requires
that all packets including headers don't exceed PAGE_SIZE.  This does
not affect the packets which go through the physical response unit
(which they do on the debugged machine) but it affects the debugging
machine.

A quick note to this text from
http://www.suse.de/~bk/firewire/ohci1394_dma_early.diff :
> +	  As all changes to the FireWire bus such as enabling and disabling
> +	  devices cause a bus reset and thereby disable remote DMA for all
> +	  devices, be sure to have FireWire enabled on the debug host (and
> +	  the cable plugged) before booting the debug target for debugging.

Bus resets are also caused by bus managing software, which Linux' old
and new FireWire stacks and the stacks of all other FireWire capable
desktop OSs are to varying degrees.  I wonder if the following could
happen:  The two PCs are directly connected, only the PHY of the
debugging PC is active, then the PHY of the debugged PC is activated,
becomes root node, debugging PC examines the bus, then resets the bus to
force its own PHY to become root node in order to get a working
isochronous resource manager.  This bus reset would switch remote DMA on
the debugged PC off.
-- 
Stefan Richter
-=====-=-=== ==-- --=--
http://arcgraph.de/sr/
--
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/