Power Sandbox: App Power Awareness Made Simple and Secure

   The quest for power-awareness has lasted for more than a decade: software
   wants know of their power consumption during execution, for identifying
   power hotspots in the code, fairly sharing the energy resource, or
   dynamically adapting software behaviors for better efficiency.

   App power awareness is achieved by a combo of i) system-wide power
   metering and ii) per-app accounting, both done at runtime. For metering,
   most recent work uses power modeling: the OS collects software events that
   may reflect hardware activities (e.g. CPU performance counters, syscall
   trace, kernel activities, etc.) and infer the system-level power
   consumption using power models (often linear models, trained offline or
   online); for accounting, the inferred system-level power consumption is
   divided among software identities following certain policies chosen by the
   OS.

   Although seemingly convenient to users, the above popular approaches
   suffer from multiple inadequacies. Metering the system power through
   modeling often requires non-trivial training effort per platform, which is
   worsen by today's diverse hardware platforms populated with novel
   accelerators, ranging from GPU to FPGA; furthermore, the inferred power
   may depart from exact values depending on varying runtime conditions, such
   as chip process variation (cite XXX) or ambient temperature (XXX), to a
   non-trivial extent.

   For power accounting, regardless of the chosen policy, power shares
   attributed to individual apps are inevitably coupled due to aggressive
   sharing of the hardware. The coupling has two implications: i)
   interpretation difficulty: an app developer not only has to understand the
   OS accounting policy (which is often implicit), but must also take into
   account other apps' activities that she can hardly foresee beforehand; the
   attributed power is unlikely reproducible across different runs because it
   depends on the concurrently executed apps. ii) security threat: app, based
   on the power share it receives, is able to learn other app's power
   activities; the resulted power side channels (cite XXX) may severely
   compromise the isolation among apps, as identified in prior work and
   further confirmed us (Section XXX). The threat is amplified as the power
   metering resolution goes up.

   Seeing these inadequacies, we set to make power awareness a first-class OS
   service that provides well-defined semantics (easy to interpret),
   isolation (for security), and a cost accounting model (for fairness).

   To meter the system power, we advocate obtaining the ground truth through
   direct measurement, an approach often dismissed as inaccurate (due to low
   sampling rate) or prohibitively expensive. Opposite to conventional
   wisdom, we show that emerging hardware platforms are already equipped with
   inexpensive power sensing circuits for their major power domains, as well
   as inexpensive (¡$1), low-power microcontrollers that pre-process the
   power samples efficiently. the software stack is able to meter the major
   hardware components (e.g. CPU, GPU, or NIC) at fine temporal granularity
   at 10 us and does so at low processing overhead.

   Towards power accounting, our key insight is that the current difficulties
   root in OS's unconstrained resource sharing: commodity OSes aggressively
   multiplexes apps on hardware, being concurrent use (spatial multiplexing)
   and time-slicing (temporal multiplexing). At the lowest level, this makes
   the entailed power consumption indivisible among apps.

   To this end, we present a new OS abstraction called power sandbox.
   Encompassing one or a group of user processes, a power sandbox allows
   these process(es) to meter their entailed power as if they are the only
   processes executed on the metered hardware. The abstraction works in two
   ways: i) a power sandbox learns its directly measured, reproducible power
   consumption that is independent of other apps; ii) the power activities of
   the remaining system is hidden from the power sandbox, which prevents the
   power side channels.

   figure: show power domains on juno

   We realize power sandboxing as an overlay on the existing OS resource
   scheduling and accounting. First, the OS principally constrains sharing so
   that concurrent use of hardware respects the power sandbox boundary.
   Second, the OS virtualizes hardware power state for each power sandboxes.
   Third, the OS charges the lost opportunities in hardware sharing to
   individual power sandboxes. Beyond this overlay, the OS still enjoys full
   freedom in scheduling: it is at liberty to decide when to schedule
   processes on hardware, and freely multiplex non-sandboxed processes
   without constraints.

   We have made the following contributions:
     * We demonstrate that on emerging hardware platforms fine-grained power
       metering through direct measurement is both practical and desirable.
     * We present power sandbox, a novel OS abstraction, that enables simple
       and secure power awareness at the process level. By cleanly isolating
       the power activities for individual power sandboxes, power sandbox
       provides easy-to-interpret, reproducible power metering to apps, and
       eliminates the security risks poses by power side channel.
     * We experimentally demonstrate that by leveraging the existing hardware
       knowledge that an OS possesses, power sandbox can be added as a thin
       layer. In our Linux-based prototype, we implemented power sandbox for
       major power consuming hardware including CPU, GPU, DSP, flash storage,
       and wireless network interface. We are able to realize power
       sandboxing at low runtime overhead (XX % slow down) and slight
       modification to a commodity OS kernel (XX sloc).