Difference between revisions of "GSoC"

From SerialICE
Jump to: navigation, search
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
The SerialICE project will hopefully participate in GSoC 2015 under the patronage of [http://coreboot.org/GSoC coreboot's GSoC administration]. Depending on the number and quality of applications, and available mentors, there might be room for a separate SerialICE project. If you're interested, please send your thoughts and ideas on the [http://www.serialice.com/mailman/listinfo/serialice mailing list] and come discuss them on IRC irc://irc.freenode.net/#coreboot.
+
The SerialICE project will hopefully participate in GSoC 2016 under the patronage of [http://coreboot.org/GSoC coreboot's GSoC administration]. Depending on the number and quality of applications, and available mentors, there might be room for a separate SerialICE project. If you're interested, please send your thoughts and ideas on the [http://www.serialice.com/mailman/listinfo/serialice mailing list] and come discuss them on IRC irc://irc.freenode.net/#coreboot.
  
 
It is not likely that the project organisation would supply any hardware required to complete or even start a project on SerialICE. So if you want to apply, you should first try building and running SerialICE yourself to understand its current capabilities and weaknesses. You really don't need a high-end mainboard or CPUs on these projects. While it's a powerful tool for low-level debugging and understanding even part of it requires a fair amount of knowledge on x86 architecture, there are also challenges in the user interface development.
 
It is not likely that the project organisation would supply any hardware required to complete or even start a project on SerialICE. So if you want to apply, you should first try building and running SerialICE yourself to understand its current capabilities and weaknesses. You really don't need a high-end mainboard or CPUs on these projects. While it's a powerful tool for low-level debugging and understanding even part of it requires a fair amount of knowledge on x86 architecture, there are also challenges in the user interface development.
Line 22: Line 22:
  
 
* Well, provide one. Now it is just a logfile and a script.
 
* Well, provide one. Now it is just a logfile and a script.
* Display SerialICE log in parallel with disassembly. Applications to consider are [http://rada.re/y/?p=features radare2] and [https://www.hex-rays.com/products/ida/index.shtml IDA]
+
* Display SerialICE log in parallel with disassembly. Could be integrated with [http://rada.re/y/?p=features radare2]
 
* Visualize PCI devicetree configuration sequence and allocations.
 
* Visualize PCI devicetree configuration sequence and allocations.
 +
* An editor that knows the log format and supports user-assisted folding of loops that wait for bit flips, naming of registers, ...
 
* Integration with GDB and DDD.
 
* Integration with GDB and DDD.
  
== Coreboot ==
+
== coreboot ==
  
 
* Collect IO and PCI transactions on boot and store them in cbmem. Replay them to see what devicetree really did during ramstage.
 
* Collect IO and PCI transactions on boot and store them in cbmem. Replay them to see what devicetree really did during ramstage.
Line 33: Line 34:
 
== QEMU ==
 
== QEMU ==
  
* Create hybrid platform, where some devices are emulated and some run on real hardware.
 
 
* Update to a more current QEMU.
 
* Update to a more current QEMU.
 
* Support other architectures.
 
* Support other architectures.
 +
* Create hybrid platform, where some devices are emulated and some run on real hardware.
 +
 +
== Port to Unicorn ==
 +
 +
[http://www.unicorn-engine.org/ Unicorn] may be a more suitable (and maybe even stable) base for our purposes than QEmu because it shares some of SerialICE's goals. Needs investigation if that's actually a good idea _before_ GSoC starts (although such an investigation is already a great way to show that you're capable of finishing this project)

Latest revision as of 11:36, 21 February 2016

The SerialICE project will hopefully participate in GSoC 2016 under the patronage of coreboot's GSoC administration. Depending on the number and quality of applications, and available mentors, there might be room for a separate SerialICE project. If you're interested, please send your thoughts and ideas on the mailing list and come discuss them on IRC irc://irc.freenode.net/#coreboot.

It is not likely that the project organisation would supply any hardware required to complete or even start a project on SerialICE. So if you want to apply, you should first try building and running SerialICE yourself to understand its current capabilities and weaknesses. You really don't need a high-end mainboard or CPUs on these projects. While it's a powerful tool for low-level debugging and understanding even part of it requires a fair amount of knowledge on x86 architecture, there are also challenges in the user interface development.

The list below is a collection of improvement ideas and capabilities that would be nice to have. Some of these could be merged with coreboot GSoC projects or support flashrom GSoC projects.

SerialICE on target

  • Build target ROM image with super-IO and PnP from coreboot tree.
  • Support EHCI debug port, extend the protocol for memory block moves.
  • Investigate possibilities to catch SMI and run System Management Mode.

SIMBA, the filtering subsystem

  • Query PCI IDs to detect chipsets and load filters automatically.
  • Enable modifying SMBus traffic on-the-fly to forge SPD data for testing purposes.
  • Create log output conditionally of CS:EIP or accessed PCI device.
  • Decode PCI/PCI-e standard configuration registers.
  • Enable injection of IO and memory transactions.

User interface

  • Well, provide one. Now it is just a logfile and a script.
  • Display SerialICE log in parallel with disassembly. Could be integrated with radare2
  • Visualize PCI devicetree configuration sequence and allocations.
  • An editor that knows the log format and supports user-assisted folding of loops that wait for bit flips, naming of registers, ...
  • Integration with GDB and DDD.

coreboot

  • Collect IO and PCI transactions on boot and store them in cbmem. Replay them to see what devicetree really did during ramstage.
  • Complete and merge coreboot panic room results upstream.

QEMU

  • Update to a more current QEMU.
  • Support other architectures.
  • Create hybrid platform, where some devices are emulated and some run on real hardware.

Port to Unicorn

Unicorn may be a more suitable (and maybe even stable) base for our purposes than QEmu because it shares some of SerialICE's goals. Needs investigation if that's actually a good idea _before_ GSoC starts (although such an investigation is already a great way to show that you're capable of finishing this project)