Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
soc:ideas [2010/02/13 10:12]
stefanha
soc:ideas [2011/03/26 13:34]
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 servicescan be very difficult ​to debug. We have a GDB stub to allow remote debugging ​over a serial cable or UDPbut for architectural reasons it'​s ​impossible to detect invalid memory accesses ​or interrupt infinite loops with itThere are a couple ​of ways of making this work:+:-/ :-/ :-/ gPXE includes support for the Transmission Control Protocol underlying most of the Internet'​s trafficenabling network boot files to be loaded ​over reliable protocols like HTTP and iSCSI. To keep the code smallthough, 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 controlImplementing 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 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 operationsA Linux kernel module could be used to enable DMA for testing network card driversThe prospective implementor ​would need fair amount ​of low-level Linux kernel experience.+==== Security improvements ==== 
 + 
 +:-/ :-/ :-/ (:-/) gPXE currently supports loading boot files over 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 Authoritysuch that it would only allow secured connections ​to servers bearing certificates signed by that authorityThis 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 ​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 81: 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 romsthere 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 enabledidentity-mapping only those parts of the address space that are validThis 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 includeinline, 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 & configurationability ​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 environmentbut 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 105: 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:

QR Code
QR Code soc:ideas (generated for current page)