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

[Johannes Schlatow]

Hi,

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

Cheers
Johannes

[Norman Feske]

Hi Johannes,

Post by Johannes Schlatow
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.

Post by Johannes Schlatow
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

[Johannes Schlatow]

On Wed, 11 Jan 2017 10:57:56 +0100

Post by Norman Feske
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?

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.

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

Cheers
Johannes

[Norman Feske]

Hi Johannes,

Post by Johannes Schlatow
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.

Post by Johannes Schlatow
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?

Post by Johannes Schlatow
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

[Johannes Schlatow]

Post by Norman Feske
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
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
if (_config.local_addr<char const>()[0]) ...
In short, it is already possible to distingish both cases, isn't it?

Thanks for the clarification, Norman. I wasn't aware that the 'Attached_rom_dataspace' automagically returns the '<empty/>' node. Works for me ;-)

Post by Norman Feske

Post by Johannes Schlatow
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!

Perfect.