Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / hiomapd / 5b97044893ca34737110c25258af858ec0b0fc30
commit5b97044893ca34737110c25258af858ec0b0fc30[log] [tgz]
authorAndrew Jeffery <andrew@aj.id.au>Fri Jan 31 16:49:22 2020 +1030
committerAndrew Jeffery <andrew@aj.id.au>Fri Jan 31 17:17:56 2020 +1030
treeea755d1a4120304601ed851b07e49516820f6e74
parente2744c0e203a24dfd00add7475596c6d765effa9 [diff]
vpnor: partition: Only attempt read() for in-bounds accesses

Attempting to read after an lseek() past the end of the file leads to an
error and we bail out. The error propagates up the callstack and causes
errors on the host side, where really we should just be returning an
erased window.

Change-Id: I06cdda4f7f6aa4d66e133de95cd642e04418bbe0
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
1 file changed
tree: ea755d1a4120304601ed851b07e49516820f6e74
  1. Documentation/
  2. file/
  3. m4/
  4. mtd/
  5. test/
  6. vpnor/
  7. .clang-format-c
  8. .clang-format-c++
  9. .gitignore
  10. backend.h
  11. bootstrap.sh
  12. common.c
  13. common.h
  14. configure.ac
  15. control.c
  16. control_dbus.c
  17. control_dbus.h
  18. control_legacy.c
  19. dbus.h
  20. format-code.sh
  21. LICENSE
  22. lpc.c
  23. lpc.h
  24. MAINTAINERS
  25. Makefile.am
  26. mboxctl.c
  27. mboxd.c
  28. mboxd.h
  29. mtd.c
  30. protocol.c
  31. protocol.h
  32. README.md
  33. transport.h
  34. transport_dbus.c
  35. transport_dbus.h
  36. transport_mbox.c
  37. transport_mbox.h
  38. windows.c
  39. windows.h
README.md

HIOMAP: The Host I/O Mapping Protocol for Power-based Systems

This repository contains the specification for the Power systems Host I/O mapping protocol (HIOMAP) along with a reference implementation of the daemon and associated utilities.

For historical reasons, source and generated binaries may refer to 'mbox' or 'the mailbox interface' in contexts that aren't completely sensible. It's unfortunate, but it's our current reality.

Building

The build system is a standard autotools setup. bootstrap.sh runs all the jobs necessary to initialise autotools.

By default the build is configured and built with the 'virtual PNOR' feature discussed below. The virtual PNOR functionality is written in C++, and due to some autotools clunkiness even if it is disabled mboxd will still be linked with CXX.

If you are hacking on the reference implementation it's recommended to run bootstrap.sh with the dev argument:

$ ./bootstrap.sh dev
$ ./configure
$ make
$ make check

This will turn on several of the compiler's sanitizers to help find bad memory management and undefined behaviour in the code via the test suites.

Otherwise, build with:

$ ./bootstrap.sh
$ ./configure
$ make
$ make check

Through the virtual PNOR feature the daemon's role as a flash abstraction can be augmented to support partition/filesystem abstraction. This is complex and unnecessary for a number of platforms, and so the feature can be disabled at configure time. If you do not have a C++ compiler for your target, set CXX=cc.

$ ./bootstrap.sh
$ ./configure CXX=cc --disable-virtual-pnor
$ make
$ make check

Coding Style Guide

Preamble

For not particularly good reasons the codebase is a mix of C and C++. This is an ugly split: message logging and error handling can be vastly different inside the same codebase. The aim is to remove the split one way or the other over time and have consistent approaches to solving problems.

However, the current reality is the codebase is developed as part of OpenBMC's support for Power platforms, which leads to integration of frameworks such as phosphor-logging. It's noted that with phosphor-logging we can achieve absurd duplication or irritating splits in where errors are reported, as the C code is not capable of making use of the interfaces provided.

So:

Rules

  1. Message logging MUST be done to stdout or stderr, and MUST NOT be done directly via journal APIs or wrappers of the journal APIs.

    Rationale:

    We have two scenarios where we care about output, with the important restriction that the method must be consistent between C and C++:

    1. Running in-context on an OpenBMC-based system
    2. Running the test suite

    In the first case it is desirable that the messages appear in the system journal. To this end, systemd will by default capture stdout and stderr of the launched binary and redirect it to the journal.

    In the second case it is desirable that messages be captured by the test runner (make check) for test failure analysis, and it is undesirable for messages to appear in the system journal (as these are tests, not issues affecting the health of the system they are being executed on).

    Therefore direct calls to the journal MUST be avoided for the purpose of message logging.

    Note: This section specifically targets the use of phosphor-logging's log<T>(). It does not prevent the use of elog<T>().

License and Copyright

Copyright 2017 IBM

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.