- This is NetWatch, a system for remote system-management-mode-based
-control of a machine without support from or awareness by the OS. It works by
-taking over a second network card to provide a standard VNC server, such that
-a machine elsewhere on the network can see the text or graphics console of the
-machine and inject keystrokes as needed.
-
- System management mode, introduced with the 386SL, essentially allows
-system driver code to run outside of OS control, caused by a special interrupt
-pin on the CPU. This was originally intended for applications such as laptop
-fan control; it is also the mechansim by which USB legacy keyboard emulation
-occurs. When a system management interrupt occurs, the northbridge remaps
-portions of memory to expose previously-hidden code, and asserts an SMI# signal,
-causing the CPU to save all its state into system management RAM and vector to
-a magic entry point.
-
- This is somewhat slow, and so there is a moderate performance impact
-caused by running NetWatch, more significant when a VNC session is open.
-Because NetWatch is invisible to the OS, its CPU usage is difficult to monitor;
-we do so by comparing the MD5 throughput of the system with NetWatch
-running versus without. The only way that the OS could detect this performance
-drain is by spinning tightly and watching for a sudden jump in the CPU's time
-stamp counters.
-
- Although it would be possible to start up NetWatch after an OS kernel
-has already loaded, it is easier and more useful to load it from GRUB before
-the OS boots, such that even the bootloader itself can be controlled over the
-network. We do this by providing a stub loader (grubload/) which can be invoked
-from GRUB, and takes care of loading the main NetWatch ELF image. Once this is
-done and NetWatch is up and running, the loader returns to real mode and
-reinvokes GRUB via the BIOS.
-
- Our current development platform, the Intel ICH2, does not allow SMM
-traps on arbitrary PCI accesses. This makes stealing the network card from the
-OS somewhat difficult, since there is nothing SMM code can do to cleanly block
-access. NetWatch simply chooses its desired network card, and then repeatedly
-clobbers the PCI base address registers. Although Linux resets the BARs to sane
-values when it probes the PCI bus, by the time it attempts to actually load
-the network driver, the card will no longer be accessible; fortunately, the
-driver quickly gives up, and Linux no longer attempts to access the card.
-
- The northbridge can be configured to invoke a system management
-interrupt every 64 milliseconds, and so the bulk of NetWatch's work is done
-from this interrupt: checking the network card for incoming packets, invoking
-lwIP, and sending any response packets necessary. SMM entry also occurs when
-when the OS reads from the keyboard I/O ports, to inject scan codes as needed.
-
- Much of NetWatch is very hardware-dependent, and although we've tried
-to maintain clean interface separation to allow for easy porting, the current
+This is NetWatch, a system for remote system-management-mode-based control
+of a machine without support from or awareness by the OS. It works by
+taking over a second network card to provide a standard VNC server, such
+that a machine elsewhere on the network can see the text or graphics console
+of the machine and inject keystrokes as needed.
+
+System management mode, introduced with the 386SL, essentially allows system
+driver code to run outside of OS control, caused by a special interrupt pin
+on the CPU. This was originally intended for applications such as laptop
+fan control; it is also the mechanism by which USB legacy keyboard emulation
+occurs. When a system management interrupt occurs, the northbridge remaps
+portions of memory to expose previously-hidden code, and asserts an SMI#
+signal, causing the CPU to save all its state into system management RAM and
+vector to a magic entry point.
+
+This is somewhat slow, and so there is a moderate performance impact caused
+by running NetWatch, more significant when a VNC session is open. Because
+NetWatch is invisible to the OS, its CPU usage is difficult to monitor; we
+do so by comparing the MD5 throughput of the system with NetWatch running
+versus without. The only way that the OS could detect this performance
+drain is by spinning tightly and watching for a sudden jump in the CPU's
+time stamp counters.
+
+Although it would be possible to start up NetWatch after an OS kernel has
+already loaded, it is easier and more useful to load it from GRUB before the
+OS boots, such that even the bootloader itself can be controlled over the
+network. We do this by providing a stub loader (grubload/) which can be
+invoked from GRUB, and takes care of loading the main NetWatch ELF image.
+Once this is done and NetWatch is up and running, the loader returns to real
+mode and reinvokes GRUB via the BIOS.
+
+Our current development platform, the Intel ICH2, does not allow SMM traps
+on arbitrary PCI accesses. This makes stealing the network card from the OS
+somewhat difficult, since there is nothing SMM code can do to cleanly block
+access. NetWatch simply chooses its desired network card, and then
+repeatedly clobbers the PCI base address registers. Although Linux resets
+the BARs to sane values when it probes the PCI bus, by the time it attempts
+to actually load the network driver, the card will no longer be accessible;
+fortunately, the driver quickly gives up, and Linux no longer attempts to
+access the card.
+
+The northbridge can be configured to invoke a system management interrupt
+every 64 milliseconds, and so the bulk of NetWatch's work is done from this
+interrupt: checking the network card for incoming packets, invoking lwIP,
+and sending any response packets necessary. SMM entry also occurs when when
+the OS reads from the keyboard I/O ports, to inject scan codes as needed.
+
+Much of NetWatch is very hardware-dependent, and although we've tried to
+maintain clean interface separation to allow for easy porting, the current
git.joshuawise.com / netwatch.git / blobdiff