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/14 16:43]
rwcr
soc:ideas [2011/03/26 13:34]
genec [What you will need] point to git-usage instead of info here.
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.
 +    * [[:​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)