Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!tcp-ip From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: tftp for bootstrap Message-ID: <8879@ucbvax.ARPA> Date: Mon, 8-Jul-85 16:25:49 EDT Article-I.D.: ucbvax.8879 Posted: Mon Jul 8 16:25:49 1985 Date-Received: Tue, 9-Jul-85 06:49:49 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 121 From: imagen!geof@su-shasta.arpa I must confess that my comments should really be in conjunction with Noel Chiappa's, since we are referring to the same set of TFTP implementations. I worked on some of the TFTP implementations while I was at MIT. My last message should only be read in context -- I agree that TFTP is no better a protocol than most others for bootloading, except insofar as it is possible to use other server implementations of TFTP. It is not necessary to modify a TFTP server from its "vanilla" state to make it useable for bootloading. The modifications that were done at MIT mostly were because some machines had TFTP has their only file transfer protocol (specifically, the UPDATE mode). The MIT implementations of TFTP all met spec (I presume they all still do), and few had hidden features. All ran on port 69. Some efforts were occasionally made to make sure that the implementations at MIT and ISI were able to interconnect. File names which were received were handed by the server to the operating system, and interpreted in the security and naming contexts of the server. As additional security measures: - all servers refused to overwrite existing files - the servers on Tops-20 and Multics were sufficiently isolated from a security point of view that the server had (by default) very little access to most user's files and directories. On multics, the server had to be explicitly permitted to access a portion of the directory tree. - on berkeley Unix, the server explicitly tested protections to verify that global read (or write) access existed where it was needed. This was necessary because the server had to run as root to be able to access socket 69, so our initial attempts to just have the server attempt to open the file and let the OS apply some default set of protections wouldn't work (interesting how in this case a security feature turned out to be a security bug). On most of the machines, the server would also reject any file transfer for which no directory was specified (the exception was the alto implementation, because there were no directories to speak of). On Tops-20, a device or directory spec had to be specified, but it was not necessary to specify both. For purposes of bootloading, a special directory was set up on each machine. The name of the directory was configured into the gateways, as was each machine's internet address. For reasons of code size, the bootloader was typically only able to use one interface. However, the gateways were able to boot through each other, so bootloading was possible from a wide variety of machines. Since gateway code was different for each gateway, the boot files for each gateway were named by concatenating the address of the gateway together. As Noel pointed out, this is easy to keep track of if you assign three letters to each byte for decimal or octal number (alternately, use hex). When booting, the gateway sent a read request to each host for a file whose name was the concatenation of the prefix for that host and the internet address of the gateway, unparsed as an octal string with three digits for each byte. The transfer mode was mode "image." The intent of mode "image" is that a file which is transferred to a host using it and then transferred back ends up with the same bits in it (perhaps a few more tacked onto the end); it is perfect for bootloading. We simply distributed the boot-code using TFTP mode image (with a little telnet fudging to delete the original first, see below) from the source, and were confident that it would be read back correctly. This worked on Alto's, Unices, Tops-20, and Multics (the latter two used different ways of storing the Image files - Tops-20 used 8-bit bytes with 4 bits of each 36 bit word wasted, and multics stored the bits sequentially in 36-bit words, ignoring word boundaries). The obvious way to use TFTP for bootloading is to have the gateway send a read request to every host in the list at once, and to accept the first response (and eventually reject any other responses). This is analogous to a broadcast request for booting. I'm not sure if the gateway did this in practise, or just tried the hosts in sequence. So, in summary, TFTP is a good bootloading protocol, without modification: - It supports a pseudo-broadcast mode of booting request. - It has a transfer mode that works. - It is fast enough. - It is simple (the original TFTP bootloader fit into 2Kb of ROM). - It is an internet protocol (you can boot through gateways - for a while at MIT we had two gateways booting off a network which had no other hosts on it. Each booted through the other. Worked for weeks until the power flickered one day... then we had to get out the old serial-line downloader). Problems: - You have to derive an Internet address for the host to be able to use an internet protocol to boot it. On an ethernet this is more of a problem. - You have to store both the names of the boot directories on each boot-host and the internet addresses of the boot hosts (in practise, there was only one boot rom that had all the hosts and directories in it; each gateway could not access some of the hosts in its table). This problem is minimized in a homogeneous environment, since the name of the directory can be the same everywhere. - It is an Internet protocol, so that broadcast is not a "native" mode of using it. If your nodes implement internet broadcast (I guess sun's still use host number 0 for broadcast, like the vaxen do...) you could theoretically use it, although as Noel points out, there are advantages to being able to boot through a gateway when necessary. One compromise position might be to use a broadcast scheme to get the booting information into the host, then use TFTP to boot the host. This would have the effect of compartmentalizing the nonstandard code in the system, and would add a more minor restriction to booting a host. Or use a "breath of life" scheme. Have a host periodically broadcast the booting information on the network in question, and have the bootloader just wait for the promiscuous packet to arrive. The advantage of this scheme is that you don't have to have any broadcasting booters on the local net -- they can use directed broadcast to send the breath of life packets. - Geof