Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:ideas [2010/02/13 09:49] rwcr + improved debugging support |
soc:ideas [2011/03/26 13:34] (current) genec [What you will need] point to git-usage instead of info here. |
||
|---|---|---|---|
| Line 29: | Line 29: | ||
| ==== Automated regression testing ==== | ==== Automated regression testing ==== | ||
| - | :-/ :-/ :-/ :-/ :-/ gPXE has a relatively large feature set given the code size. Many features are rarely used, and there has been a tendency for parts of the code to suffer from bit-rot. The measures we have taken so far will ensure that we never end up with unbuildable code; we now avoid the use of #ifdef wherever possible, and have automated tests in place to identify missing or redundant symbols. However, we do not have any systematic method for functional testing. | + | :-/ :-/ :-/ :-/ gPXE has a relatively large feature set given the code size. Many features are rarely used, and there has been a tendency for parts of the code to suffer from bit-rot. The measures we have taken so far will ensure that we never end up with unbuildable code; we now avoid the use of #ifdef wherever possible, and have automated tests in place to identify missing or redundant symbols. However, we do not have any systematic method for functional testing. |
| We would ideally like to be able to run a series of tests to verify different functional units (e.g. http download, Linux kernel booting, PXE booting, serial console support, etc.). Most of these tests can be carried out inside a virtual machine such as bochs or qemu. Some tests (e.g. specific device driver tests) will need to be carried out on real hardware. The tests should be fully automated, and should produce a clear pass/fail status indicator. It should be possible for a developer to simply run “make test” and, some time later, receive an overall pass/fail status, together with a list of any failed tests. | We would ideally like to be able to run a series of tests to verify different functional units (e.g. http download, Linux kernel booting, PXE booting, serial console support, etc.). Most of these tests can be carried out inside a virtual machine such as bochs or qemu. Some tests (e.g. specific device driver tests) will need to be carried out on real hardware. The tests should be fully automated, and should produce a clear pass/fail status indicator. It should be possible for a developer to simply run “make test” and, some time later, receive an overall pass/fail status, together with a list of any failed tests. | ||
| Line 37: | Line 37: | ||
| Having such an automated test suite would enable us to offer quality control guarantees; we could then be confident that upgrades would not break existing functionality. | Having such an automated test suite would enable us to offer quality control guarantees; we could then be confident that upgrades would not break existing functionality. | ||
| - | ==== Improved debugging support ==== | + | ==== Improved TCP performance ==== |
| - | :-/ :-/ :-/ :-/ gPXE, running as it does in an environment with nothing by way of memory protection or operating system services, can be very difficult to debug. We have a GDB stub to allow remote debugging over a serial cable or UDP, but for architectural reasons it's impossible to detect invalid memory accesses or interrupt infinite loops with it. There are a couple of ways of making this work: | + | :-/ :-/ :-/ gPXE includes support for the Transmission Control Protocol underlying most of the Internet's traffic, enabling network boot files to be loaded over reliable protocols like HTTP and iSCSI. To keep the code small, though, gPXE's TCP stack is very simple, and does not support many TCP features such as out-of-order packet recovery, selective ACK, window scaling, or congestion control. Implementing some of these features would allow much better performance in downloads of large network boot images. |
| - | * Allow gPXE to run with paging enabled, identity-mapping only those parts of the address space that are valid. This would require significant expertise in low-level x86 internals; gPXE interacts with them even more than a typical operating system, because it has to regularly switch between real and protected mode to perform BIOS calls. | + | You would analyze the performance benefits and code size costs of several TCP features, and choose a few to implement in gPXE's TCP stack to best improve performance without compromising gPXE's ability to fit into ROM. |
| - | * Allow gPXE to run as a user-mode application under Linux. Obviously network card drivers would be difficult to test in this environment, but most other parts of gPXE could be run in an environment with built-in memory protection and useful tools like ''valgrind'' easily available. The cleanest way to do this would be to create another x86 "platform", alongside the existing PC-BIOS and EFI, that performs low-level Linux system calls to perform platform-specific operations. A Linux kernel module could be used to enable DMA for testing network card drivers. The prospective implementor would need a fair amount of low-level Linux kernel experience. | + | ==== Security improvements ==== |
| + | |||
| + | :-/ :-/ :-/ (:-/) gPXE currently supports loading boot files over a TLS-secured HTTP connection (''%%https://%%'' URI), but the implementation is sufficiently skeletal that its security is much less than that of a typical Web browser: | ||
| + | * gPXE has no boot-time source of entropy, so its random numbers are not really random and could be guessed fairly easily by an attacker. You would implement a cryptographically strong random number generator (algorithms for several are publicly available), using entropy from timing jitter in the system clock or the timing of packet arrivals on the network. | ||
| + | * We do not verify the server's certificate, so there is no way to be sure traffic to the secure server is not being hijacked by a third party. You would implement support for compiling gPXE with a root Certificate Authority, such that it would only allow secured connections to servers bearing certificates signed by that authority. This would require parsing the x509 certificate's ASN1 representation to extract the cryptographic data necessary for verification, and performing the appropriate signature verification to ensure the certificate really was signed by the CA. | ||
| + | |||
| + | Either of these projects would require either a preexisting familiarity with cryptography or a week or two of research into the necessary methods and data formats. Familiarity with C is required, and a moderate mathematical background probably helpful. The results would enable sites with stringent data security requirements to begin using gPXE to boot their systems over the network. | ||
| ==== Linux Distribution network installation ==== | ==== Linux Distribution network installation ==== | ||
| Line 60: | Line 66: | ||
| gPXE is structured to allow easy addition of IPv6: the IPv4 layer is cleanly separated from both the transport layers (TCP and UDP) and the link layers (Ethernet and others). Adding IPv6 support would require implementation of the basic IPv6 network layer protocol plus any ancillary protocols required for IPv6 operation such as NDP. The existing DNS protocol support should be extended to cover IPv6 AAAA records, and it would also potentially be useful to support DHCPv6. | gPXE is structured to allow easy addition of IPv6: the IPv4 layer is cleanly separated from both the transport layers (TCP and UDP) and the link layers (Ethernet and others). Adding IPv6 support would require implementation of the basic IPv6 network layer protocol plus any ancillary protocols required for IPv6 operation such as NDP. The existing DNS protocol support should be extended to cover IPv6 AAAA records, and it would also potentially be useful to support DHCPv6. | ||
| - | |||
| - | ==== Protocols ==== | ||
| - | |||
| - | gPXE already supports several common (and less common) protocols, including TFTP, FTP, HTTP, HTTPS, DNS, iSCSI and AoE. There are several more (mostly fairly esoteric) protocols that people may find useful. You could add support for: | ||
| - | |||
| - | * :-/ :-/ Fibre Channel over Ethernet (FCoE) | ||
| - | |||
| - | * :-/ :-/ Novell's Remote Program Load (RPL) | ||
| - | |||
| - | * :-/ :-/ iSCSI extensions for RDMA (iSER) | ||
| ==== ProxyDHCP server for Linux ==== | ==== ProxyDHCP server for Linux ==== | ||
| Line 91: | Line 87: | ||
| Having a powerful scripting language would make it possible to customize network boot behavior without being an expert in low-level C programming and gPXE internals. | Having a powerful scripting language would make it possible to customize network boot behavior without being an expert in low-level C programming and gPXE internals. | ||
| - | ==== R.O.M. - Rom-O-Matic ==== | + | ==== Improved debugging support ==== |
| - | :-/ Rom-O-Matic is the web / graphical fronted to creating Etherboot & gPXE roms, there are several things that need to be worked on within the code base to make it better & more user friendly | + | :-/ :-/ :-/ :-/ :-/ gPXE, running as it does in an environment with nothing by way of memory protection or operating system services, can be very difficult to debug. We have a GDB stub to allow remote debugging over a serial cable or UDP, but for architectural reasons it's impossible to detect invalid memory accesses or interrupt infinite loops with it. There are a couple of ways of making this work: |
| - | * Updating and merging of the new configuration file reading code originally done by John 'Warthog9' Hawley | + | * Allow gPXE to run with paging enabled, identity-mapping only those parts of the address space that are valid. This would require significant expertise in low-level x86 internals; gPXE interacts with them even more than a typical operating system, because it has to regularly switch between real and protected mode to perform BIOS calls. |
| - | * Updating configuration files to include, inline, syntax information hints for things like R.O.M. | + | |
| - | * Trivial ROM creation based on relative place in gPXE source tree | + | |
| - | * User Interface clean-ups | + | |
| - | Knowledge of gPXE building & configuration, ability to read and understand C and programing in PHP are required. | + | * Allow gPXE to run as a user-mode application under Linux. Obviously network card drivers would be difficult to test in this environment, but most other parts of gPXE could be run in an environment with built-in memory protection and useful tools like ''valgrind'' easily available. The cleanest way to do this would be to create another x86 "platform", alongside the existing PC-BIOS and EFI, that performs low-level Linux system calls to perform platform-specific operations. A Linux kernel module could be used to enable DMA for testing network card drivers. The prospective implementor would need a fair amount of low-level Linux kernel experience. |
| ===== What you will need ===== | ===== What you will need ===== | ||
| Line 115: | Line 108: | ||
| * Access to IRC (Internet Relay Chat), so that you can talk to us. | * Access to IRC (Internet Relay Chat), so that you can talk to us. | ||
| + | |||
| + | * We use git for source code management, so you will need to learn to create and manipulate your own git repository. | ||
| + | * [[:git-usage|Using git for gPXE development]] | ||
| Depending on the project idea that you choose, you may also need: | Depending on the project idea that you choose, you may also need: | ||
