report_rom clarification about the validity of ROMs in case the report session was closed

Norman Feske norman.feske at ...1...
Wed Jan 11 10:57:56 CET 2017

Hi Johannes,

> I (more precisely: a student of mine) noticed that a ROM provided by
> the report_rom is cleared once the corresponding Report session is
> closed. I looked at the implementation, which intentionally clears
> the dataspace when the writer (i.e. the report session) is
> unregistered from the Rom_module.

the dataspace as seen by the ROM client is a different one than the
dataspace written-to by the report client. In fact, each ROM client has
a session-local copy of the report that is captured from the actual
report at the time when the ROM client requested or updated the ROM
dataspace. (The session-local copy has the form of the '_ds' member in
'include/report_rom/rom_service.h'). Note that the content of the
ROM-client's dataspace does not change without an explicit update
request by the ROM client - regardless of the behavior of any report client.

The backing store for the actual report is provided by the session quota
of the report client. If the report client posts a new report, the
dataspaces of the ROM clients remain unaffected. The report-ROM server
merely delivers an update signal to each ROM client that is associated
with the report. It is up to each ROM client to respond to the signal
(by requesting a ROM update) or not. Unless it explicitly requests the
dataspace to be updated, the dataspace content remains the same.

This also holds true in the event when the report session is closed. The
actual report will be immediately destroyed (as it is bound to the
report-client's session quota). At this time, the report-ROM server
clears the memory just to wipe the information from physical memory
(anticipating that the report may have contained credentials that may
otherwise leak by a potential use-after-free bug somewhere in the Genode
base system). But the per-ROM-client dataspaces will retain their
information until the respective client requests a ROM update. If that
happens, report-ROM will try to obtain a copy of the actual report,
which is gone at this point. Hence, the ROM client will get an empty

> I'm curious about the reason for
> this. More specifically, I am wondering why the report_rom does not
> invalidate and notify the registered ROM sessions after the content
> was cleared. Currently, the ROM clients will just see that the
> content disappeared without getting any signal, which seems a bit
> counterintuitive/inconsistent to me.

There is no specific reason not to deliver a signal for a vanishing
report. We just have not encountered a use case for such a signal. In my
opinion, from the ROM-client's perspective, it does not make much of a
difference whether to see a stale report or no report. Or another way to
put it: From the client's perspective, the situation is not
distinguishable from a long-delayed delivery of an update signal.

That said, if you have a tangible use case to propagate update signals
for disappearing reports, I have no principle objection against it. But
I would like to understand the use case. Can you describe the scenario
where the current behavior caused you trouble?


Dr.-Ing. Norman Feske
Genode Labs ·

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list