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 dataspace.

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?

Cheers Norman

Hi Johannes,

Sure. The scenario consists of two report_rom components. Let's call these config_rom and report_rom. The report_rom gets its config from the config_rom so that it can be changed dynamically by a management component that reports this config to the config_rom. On session request, the report_rom implementation calls an update() on its ROM session to the config_rom before looking for a matching policy. The problem was triggered by the fact that the management component (unintentionally) released the report session after some time. Hence, the update() in the report_rom refreshed the dataspace of the ROM session to the zeroed-out/empty version.

thanks for the explanation.

I don't have a problem with this behaviour in this particular scenario as the report session must be kept alive for the lifetime of the management component anyway. However, it raised the question (to me) whether the config_rom should deliver an invalid dataspace instead of a valid but empty dataspace. I think, depending on the report/application, an empty dataspace can for sure be considered valid.

Nevertheless, I have the feeling, that there should be a difference whether an empty report has intentionally been reported or whether the report_rom emptied the dataspace after the report session has been closed.

Usually, reports have the form of XML with the report name as top-level node type. So in this common case, the report consumer may check for this condition, e.g., to see if a pointer report as issued by nitpicker is valid, one may do:

if (_config.xml().type() == "pointer") ...

If nitpicker closes the report session, report_rom will clear the dataspace. So the dataspace will start with a 0 instead of the top-level XML node. In this case, the 'Attached_rom_dataspace` returns the '<empty/>' node. In the hypothetical case that a valid report is called "empty", one could still check whether the dataspace contains a null-termination at the beginning:

if (_config.local_addr<char const>()[0]) ...

In short, it is already possible to distingish both cases, isn't it?

Or to put it another way: Initially, i.e. if no report session was created (yet), the report_rom delivers an invalid dataspace to the ROM clients. Shouldn't the report_rom restore this state after the report session was closed?

You raise a good point. But instead of confronting the ROM client with an invalid dataspace (which most ROM clients do not anticipate and therefore don't handle), I would rather deliver a zeroed dataspace initially to achieve the desired consistency. Thanks for pointing out this current deficiency!

Cheers Norman