Mac firmware has a special boot mode that allows you to offer its internal hdd to another computer as an external disk (you just connect the two machines via an IEEE 1394 cable). Only the second machine needs a functioning OS installed.

Any good suggestions for something similar on the PC side of things? Block level access isn't important to me, I'd just like to be able to copy files off it. It doesn't matter to me if it uses Ethernet, IEEE 1394, or wifi - I just like having a quick way to access files on a client PC.

Is there any single-purpose Linux distro specially designed to do this? It'd be nice to have something super simple, quickbooting, and small that I could install on a USB drive. I used to use Knoppix, but it's overkill as a Target Mode replacement.


Sadly, no. There's no longer any excuse for the lack, given the availability of USB OTG and EFI firmwares, but nobody is implementing it.

Your best bet is booting a mini Linux distro off CD or USB key that loads entirely into RAM, enumerates storage devices, and exposes them over iSCSI or NBD over Ethernet, and/or via FireWire SDB2 host mode if you have a FireWire port. I'm not aware of any canned distro to do this, but it should be pretty easy to rig up on top of SysRescCD with a custom init script.

I just wrote a big rant about this topic, which boils down to "FFS, with EFI firmwares and USB OTG there's no excuse not to offer target disk anymore; even without OTG Micro-AB ports offering Target Disk over Ethernet with iSCSI or ATAoE wouldn't be unreasonable."

Seriously, look at what Intel AMT (vPro) can do. In comparison to that level of firmware capability (which is made possible by EFI, by the way) target disk mode is nothing.

  • Why no love for PXE booting? – jscott Jun 6 '12 at 4:16
  • @jscott PXE boot is great if you have a handy non-braindead DHCP server and a TFTP server on the network. I use it heavily myself - in fact, my poor-man's "target disk mode" solution is to PXE-boot the Linux Terminal Server Project (LTSP) system we use for thin clients on the work LAN, switch to a local shell, and fire up nbd-server. However, PXE boot is difficult to impossible on a typical home network with some brain-dead Belkin garbage doing DHCP. In any case, it doesn't matter how you boot the OS, you still need the same thing. – Craig Ringer Jun 6 '12 at 4:58
  • @jscott BTW, I'm currently investigating how hard it'd be to write a UEFI EBC (EFI Byte Code) or native-compiled EFI driver to provide something like target disk mode. It looks like it'd be practical on machines with EFI Shell support, but friggin' Intel don't include EFI Shell on their desktop boards, only their server boards. Without EFI shell I'm not sure it can be done truly diskless, it'll probably need a USB key for the target disk EFI driver. – Craig Ringer Jun 6 '12 at 5:01
  • @Craig, nice blog post. I've been primarily using Apple gear so long now I'd never heard of USB OTG. Interesting. – username Jun 7 '12 at 20:16
  • @username I was incorrect in my post as originally written btw; I thought OTG could support the standard USB A-type connector, but it can't, it needs a USB Micro-AB connector. Still no excuse for not including it at least on things like ultraportable laptops where space is at a premium. For some totally batshit insane reason the USB3 spec doesn't provide for a full-size USB OTG socket that's compatible with A-type USB plugs, so we missed a real chance with the USB port change for USB3. – Craig Ringer Jun 8 '12 at 3:37

Target disk mode is a feature of the Mac firmware. I've never heard of this being implemented in a PC manufacturers BIOS.

  • Good answer. Nitpicky clarification: Current Mac's don't use "BIOS" (as the name for the software rather than type of software). PPC Macs used Open Firmware, whereas the Intel Macs use EFI but both are technically types of BIOSes. – Chealion May 14 '09 at 22:14
  • true, there isn't an exact equivalent. i don't mind plugging in a bootable thumbdrive though. actually come to think of it, some of the instant-on OSes (shipping with netbooks) would fit the bill. hmm – username May 14 '09 at 22:14
  • Good catch @Chealion, i've updated my answer – Dave Cheney May 14 '09 at 23:17

A long time ago you could use a special parallel cable or null modem cable to connect two computers. That is completely worthless though given the speed and ammount of data you probably need to transfer.

You can use a special usb cable to connect to computers. Several vendors sell a cable that allow you to connect two computers via usb.

If both computers have ethernet then of course you can setup a network between the two. You may need a cross-over cable. I don't know of any off the top of my head, but it sure seems like it would be really easy to build a live cd/usb that simply boots, mounts every possible device and shares it all out via smb, nfs, ssh and starts a dhcp server.


I don't think there is anything on the market to do it.

If you're really devoted to making it happen and have time & programming skill, you could probably take a look at one of the Firewire DMA exploits and figure out how they work. There was one written in Python last year whose code was very readable.

Firewire gives you direct memory access, so you can bootstrap a minimalist kernel and do whatever you want via the connection. If you're worried about full-disk encryption, it's a major risk that you need to account for, as someone could plug a Firewire device into a laptop that's asleep (vs. hibernated or powered down) and compromise the encryption key.

  • Firewire isn't inherently insecure, it's just that most firmwares and drives don't (didn't? a lot may've changed in 4 years) configure the controller properly. Firewire requires DMA but a properly configured controller will have a small-ish DMA window restricted by an IOMMU or controller on-board features to a DMA buffer allocated for its use. It won't have access to all of memory when set up this way. Firewire doesn't inherently require access to all of RAM, it's just lazy implementation that creates this security hole. – Craig Ringer Mar 14 '13 at 23:07

This is handled by the sbp-target module of linux kernel versions 3.5 and newer, enabled with SBP_TARGET.

  • Yeah, that's a nice development. There's the caveat that you have to boot a Linux kernel from something first, though. Unless you're using coreboot with a custom flashed firmware, this means booting off a USB key (which is unreliable on many firmwares) or CD (if there's a drive). It's still useful, but in the end I could always do the same thing with network block device (nbd) or iSCSI before. – Craig Ringer Mar 14 '13 at 23:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.