smartmeter demo (CHERIoT device bits)

[nwf]

No description provided.

[vmurali]

Looks like I cannot push to this branch. Here's a slightly different design to highlight the security guarantees of CHERIoT against a system that has no compartmentalization:

1. The grid controller

   1. Receives scheduled outages (array of <start time, duration>)
   2. Recieves request for corrective actions i.e. load shedding, load increase (array of <start time, duration, maximum load value, minimum load value>)

2. The provider

   1. Receives hourly rate information for the next day (<date, array of 24 prices>); the old rates are used till a new rate is received for a day
   2. Sends accumulated consumption information hourly
   3. Optional: receives a directive to turn off the energy for various reasons (payment not made, hourly consumption information isa not received for a long time)

3. The sensor: provides a passive interface for reading the following values

   1. Instantaneous total load consumption in the house
   2. Optional: Instantaneous energy stored in each battery in the house (array of <battery index, energy>)

4. The house

   1. Updates/accumulates the hourly comsumption information based on energy consumption sensor data (reads sensor data frequently)
   2. Provides a passive interface to specify the load to be consumed for an array of load consumers (array of <consumer index, load> updated frequently)
   3. Optional: Provides a passive interface to specify the status of charge/discharge for an array of batteries (array of <battery index, CHARGE/DISCHARGE> updated frequently)

5. The user

   1. Provides a passive interface to specify the policy (using a Javascript bytecode) to drive the load consumers (and optionally battery) based on grid request, provider rate (and optionally battery energy)
   2. Calls the house interface to specify load consumer values and battery charge/discharge status based on the current policy

The grid controller and provider each run a thread for receiving data in the form of MQTT messages, and the provider runs a thread for sending accumulated consumption information.
The provider has web interface to show the current accumulated (monthly) charges.
The sensor can optionally have a web interface to show the current load consumption and batteries' levels. The house runs a thread the updates the hourly consumption information.
The user provides a web interface to input the javascript program to specify policy.
The user runs a thread to update the loads to be consumed by various consumers and optionally the charge/discharge status for the batteries.
Optional: The grid and provider has a web interface to submit new rates, requests, outages etc.

The javascript VM has FFI functions to access

1. the outage information, () -> (Start Time, Duration)
2. grid load requests, () -> (Start Time, Duration, Max Load Value, Min Load Value)
3. provider rate information for the current day, Hour -> Rate
4. sensor load consumption, () -> Current load
5. battery level, Battery Index -> Current Energy Stored
6. set load consumptions, Consumer Index -> Load -> ()
7. set battery charge/discharge, Battery Index -> CHARGE/DISCHARGE -> ()

On a system with no security features, a user can write a javascript program that abuses the set load consumptions or set battery charge/discharge functions to specify an arbitrary 32-bit index to update any value in the memory.
In particular, the hourly consumption information can be overwritten to 0 to make the provider think that the total energy consumption is 0 throughout.

With CHERIoT, each of the above components can be specified as a separate compartment and as a result, the user compartment that has the javascript VM cannot access/update arbitrary memory using the index value in the set load consumptions/set battery charge/discharge functions.

Note that the grid controller is optional for this security feature demonstration and can potentially be removed to simplify the design.