|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: More on iSCSI bootJulian, I think you are simply confused on terminology. I think when David says "boot image" he is using in generally to mean transfering enough data to provide a self supporting operating system. In the case of SCSI the "image" is set of sectors necessary to start the kernel, similarily in NFS it is typically the "vmunix" file(s). It is not the full LUN representing the root filesystem. As Bernard has shown, a flexible and scaleable mechanism to bootstrap a security system without a disk is just very hard. We need to do a reality check on the environment that iSCSI boot will use. I don't think there will be a large market for booting over the Internet, but boot disks will be physically co-located in constrained environments where DHCP will be "good enough". While the IESG may not like the weak security, I would be surprised if it insisted that the ips WG take on the task of building a better DHCP. -David julian_satran@il.ibm.com wrote: > > David, > > The trouble with our boot is two-fold: > > -the SCSI boot - unlike the network boot is unbounded (there is no such > thing as an image). > -even if we would like to standardize a "primary" or "minimal" boot we have > no good understanding (experience) > of how this will interact with the iSCSI security mechanisms. > > Julo > > Black_David@emc.com on 31-05-2001 05:49:57 > > Please respond to Black_David@emc.com > > To: ips@ece.cmu.edu > cc: > Subject: More on iSCSI boot > > Let's start with a simple boot from a disk - the system > BIOS reads the boot sector(s) off of the disk drive, > loads and runs it/them. That primary bootloader then > handles whatever else is necessary based on the ability > to do disk reads (a secondary bootloader and/or other > things may be involved). On Intel systems, it's generally > a combination of the system BIOS and card BIOS that > make the disk reads work. Simplifying assumptions > are common (e.g., boot from LUN 0 on the first SCSI > target found). The goal of the iSCSI boot draft is > to explain how to make this "simple boot from a disk" > mechanism work when the boot disk is attached via iSCSI. > > An iSCSI adapter has some things to do in order to make > this work, e.g., it has to log into the target before disk > reads can be issued. I tend to believe that "Don't do this > (i.e., try to boot over iSCSI)" is not an acceptable answer. > > In the message that started this whole boot discussion, I > suggested that > > Using DHCP to find SLP to find the boot device seems > both clumsy and an invitation to problems (one more > thing that can break and prevent booting), > > I think that's doubly true if LDAP is used instead of SLP. > David Robinson's messages support my inclination to reuse > DHCP option 17 (Root Path) by defining iSCSI syntax > for it. Between that, any TCP parameters that one wants to > set through DHCP, and iSCSI parameters that can be defaulted, > it should be possible to get the first disk reads done > through iSCSI. > > As has been pointed out, booting is often poorly secured in > general. While it'd be nice to change this, iSCSI will face > the same pressures that other boot mechanisms face - keep > it simple, get the boot image loaded, and let it do something > fancier. Any signature/validation of the boot image will be > above the level of iSCSI. Somehow, I don't expect to find > implementations of ESP in card BIOSes anytime soon. > > If implementers want to use DHCP and TFTP to boot, I don't > see any point in stopping them, but I don't think either should > be mandated. DHCP has centralized administration advantages, > and TFTP is a simple way to download code, but both are "one > more thing that can break and prevent booting" and hence may > not be used all the time. > > Comments? > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------
Home Last updated: Tue Sep 04 01:04:35 2001 6315 messages in chronological order |