tree: b3d8bff2eaa730bf79916e1f3fdb384e4ad0f310 [path history] [tgz]
  1. BUILD.gn
  2. OWNERS
  3. README.md
  4. component_category.cc
  5. component_category.h
  6. daemon.cc
  7. daemon.h
  8. dbus/
  9. function_templates/
  10. functions/
  11. init/
  12. probe_config.cc
  13. probe_config.h
  14. probe_config_test.cc
  15. probe_function.cc
  16. probe_function.h
  17. probe_function_argument.cc
  18. probe_function_argument.h
  19. probe_result_checker.cc
  20. probe_result_checker.h
  21. probe_result_checker_test.cc
  22. probe_statement.cc
  23. probe_statement.h
  24. probe_statement_test.cc
  25. runtime_probe.cc
  26. runtime_probe_helper.cc
  27. sandbox/
  28. seccomp/
  29. statement/
  30. testdata/
  31. udev/
  32. utils/
runtime_probe/README.md

Overview

Runtime Probe is essentially a command line tool that consumes the probe syntax and outputs the probe result.

This command line tool will gradually replace fields in HWID (i.e. less fields will be encoded into HWID) as it reflects the status of a device in a more timely approach. We are not aiming to be a daemon service, instead, we pose ourselves as a one-shot call tool, just like the ping command, the D-Bus method introduced later is also on-demand and expected to exit immediately after one call.

Currently, the reported data is purely hardware information. For example, the model of storage, the remaining capacity of battery, the screen resolution..etc.

To serve clients that are not able to call the command line directly, we offer a simple, restricted D-Bus interface with only one method org.chromium.RuntimeProbe.ProbeCategories. This D-Bus method follows the Chrome OS D-Bus Best Practices, proper minijail0, secomp policy are applied inside dbus/org.chromium.RuntimeProbe.conf.

Motivation

To better reflect hardware configuration on users’ system, we need a tool in release image that is able to reflect the truth of the moment in the field. Traditionally, this need has been satisfied by factory's probe framework, because we assume rare components replacement after mass production. However, we have seen more and more requests from partners to switch components after devices left the factory process.

This work is also related to the evolution of HWID. Instead of going into details on the complicated plan, we would like to use an example to let the reader get a high level concept on how this work helps cases in HWID.

Let‘s look into a typical scenario here: After years’ love into the Chromebook, a user has one of the DRAM broken in slots, and would like to replace it. However, the original part is already EOL (End Of Life), ODM has no choice but to pick another part from the AVL (Approved Vendor List), while this new DRAM is installed, the original probe result (HWID) in factory is violated. Hence, even after the factory process, we would like to get the probe result to reflect the truth of the moment under release image. Runtime is used to convey the concept of dynamic.

Usage

The code is still underdevelopment, will update when it is ready for use.