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

[Norman Feske]

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

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