genode

History

Norman Feske eba9c15746 Follow practices suggested by "Effective C++" The patch adjust the code of the base, base-<kernel>, and os repository. To adapt existing components to fix violations of the best practices suggested by "Effective C++" as reported by the -Weffc++ compiler argument. The changes follow the patterns outlined below: * A class with virtual functions can no longer publicly inherit base classed without a vtable. The inherited object may either be moved to a member variable, or inherited privately. The latter would be used for classes that inherit 'List::Element' or 'Avl_node'. In order to enable the 'List' and 'Avl_tree' to access the meta data, the 'List' must become a friend. * Instead of adding a virtual destructor to abstract base classes, we inherit the new 'Interface' class, which contains a virtual destructor. This way, single-line abstract base classes can stay as compact as they are now. The 'Interface' utility resides in base/include/util/interface.h. * With the new warnings enabled, all member variables must be explicitly initialized. Basic types may be initialized with '='. All other types are initialized with braces '{ ... }' or as class initializers. If basic types and non-basic types appear in a row, it is nice to only use the brace syntax (also for basic types) and align the braces. * If a class contains pointers as members, it must now also provide a copy constructor and assignment operator. In the most cases, one would make them private, effectively disallowing the objects to be copied. Unfortunately, this warning cannot be fixed be inheriting our existing 'Noncopyable' class (the compiler fails to detect that the inheriting class cannot be copied and still gives the error). For now, we have to manually add declarations for both the copy constructor and assignment operator as private class members. Those declarations should be prepended with a comment like this: /* * Noncopyable */ Thread(Thread const &); Thread &operator = (Thread const &); In the future, we should revisit these places and try to replace the pointers with references. In the presence of at least one reference member, the compiler would no longer implicitly generate a copy constructor. So we could remove the manual declaration. Issue #465		2018-01-17 12:14:35 +01:00
..
main.cc	Follow practices suggested by "Effective C++"	2018-01-17 12:14:35 +01:00
README	os: add component for filtering USB devices report	2016-01-27 16:15:34 +01:00
target.mk	update Reporter constructors	2017-02-07 19:20:29 +01:00

README

This directory contains a USB device report filter component. It filters the
device report coming from the USB driver by checking each device reported
against the given list of devices. Only approved devices are reported to a
consumer of the report coming from the filter component.


Configuration
~~~~~~~~~~~~~

A typical example configuration looks as follows:

!<config>
!  <client label="component_xyz"/>
!  <device vendor_id="0x13fe" product_id="0x5200"/>
!  <device vendor_id="0x148f" product_id="0x2573"/>
!  <device vendor_id="0x04f9" product_id="0x0051"/>
!  <device vendor_id="0x1b1c" product_id="0x1a09"/>
</config>

The component that may use the devices is identified by the 'client' node.
In addition to the 'vendor_id' and 'product_id' attribute a 'device' node
can contain a 'bus' and 'dev' attribute. If these attributes are present they
have a stronger significance than the 'vendor_id' and the 'product_id'.

Whenever the 'usb_report_filter' component receives a new USB device report
from the driver it will generate a new driver configuration that contains
a policy entry for each matching device. After the driver's configuration has
been updated, the filter component will generate a new USB device report that
only contains the devices the component is allowed to access.


Example
~~~~~~~

In the following example we will give a VirtualBox instance access to a
Corsair Voyager USB stick:

!<start name="usb_report_filter">
![...]
!  <config>
!    <client label="vbox"
!    <device vendor_id="0x1b1c" product_id="0x1a09"/>
!  </config>
!</start>

!<start name="report_rom">
!  <resource name="RAM" quantum="1M"/>
!  <provides> <service name="Report"/> <service name="ROM"/> </provides>
!  <config>
!    <policy label="usb_report_filter -> devices"        report="usb_drv -> devices"/>
!    <policy label="usb_report_filter -> usb_drv_config" report="usb_drv -> config"/>
!    <policy label="vbox -> usb_devices"                 report="usb_report_filter -> usb_devices"/>
!  </config>
!</start>

After the USB stick has been plugged in, the filter will generate the
following USB driver configuration:

!<start name="usb_drv">
![...]
!  <config uhci="yes" ehci="yes" xhci="yes">
!    <hid/>
!    <raw>
!      <report devices="yes"/>
!      <policy label="vbox -> usb-1-3" vendor_id="0x1b1c" product_id="0x1a09" bus="0x0001" device="0x0003"/>
!    </raw>
!  </config>
!</start>

After the driver has reloaded its configuration it will send a config report
that provokes the filter component to send the following USB device report to
VirtualBox:

!<devices>
!  <device label="usb-1-3" vendor_id="0x1b1c" product_id="0x1a09" bus="0x0001" device="0x0003"/>
!</device>

In return, VirtualBox will try to access the USB device. Since the configuration
of the USB driver contains a matching policy entry the access attempt will
succeed.