Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
soc:ideas [2010/02/14 16:43] rwcr |
soc:ideas [2011/03/26 05:58] mdc [What you will need] |
||
|---|---|---|---|
| Line 45: | Line 45: | ||
| ==== Security improvements ==== | ==== 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 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. | * 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. | * 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. | ||
| Line 94: | Line 94: | ||
| * 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. | * 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. | ||
| - | |||
| - | |||
| - | ==== R.O.M. - Rom-O-Matic ==== | ||
| - | |||
| - | :-/ 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 | ||
| - | |||
| - | * Updating and merging of the new configuration file reading code originally done by John 'Warthog9' Hawley | ||
| - | * 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. | ||
| ===== What you will need ===== | ===== What you will need ===== | ||
| Line 120: | 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. | ||
| + | * http://github.com/ is a free hosting service for git | ||
| + | * http://help.github.com/ has information and tutorials for git to get you started | ||
| + | * You will need to clone the main gPXE repository to your own repository | ||
| + | * http://help.github.com/fork-a-repo/ has an example of doing this | ||
| Depending on the project idea that you choose, you may also need: | Depending on the project idea that you choose, you may also need: | ||
