cell memory can be used to leak information from one cell to another

[Henning Schild]

Hi,

yesterday i stumbled over something interesting. After rounds of

jailhouse enable, cell create, cell load, cell start, disable

i forgot the "cell load" in one run. But for my simple test that was
not a problem because the old binary was still in the assigned memory,
the only funny effect one will get is non NULL data (global variables).

I think that this behaviour breaks isolation. After a "cell destroy"
Linux is probably able to read back whatever the cell left in its
loadable memory, but i did not try doing that. And after a "disable"
all memory goes back to Linux.

Jan and me just talked about it off list. And the conclusion was to not
blindly initializing all memory before reassigning it. Cells that
handle secrets should use the reconfiguration lock and clear their
memory before exiting.

Henning

[Valentine Sinitsyn]

Hi Henning

On 05.11.2014 15:24, Henning Schild wrote:
> I think that this behaviour breaks isolation. After a "cell destroy"
> Linux is probably able to read back whatever the cell left in its

IIRC Linux can do this anytime, as inmates memory is mapped to root cell
(otherwise the root cell won't be able to load inmate binary). Could
probably be worked around with JAILHOUSE_MEM_WRITE-only permissions.

Otherwise I agree that looking after sensitive data is data owner (i.e.
inmate) job. It's a bit of problem that Linux can read inmate memory
anytime though.

Valentine

[Henning Schild]

On Wed, 5 Nov 2014 15:45:14 +0500
Valentine Sinitsyn <valentine...@gmail.com> wrote:

> Hi Henning
>
> On 05.11.2014 15:24, Henning Schild wrote:
> > I think that this behaviour breaks isolation. After a "cell destroy"
> > Linux is probably able to read back whatever the cell left in its
> IIRC Linux can do this anytime, as inmates memory is mapped to root
> cell (otherwise the root cell won't be able to load inmate binary).
> Could probably be worked around with JAILHOUSE_MEM_WRITE-only
> permissions.

I also thought about write-only for solving parts of the problem. But
not every architecture allows you to model that.

> Otherwise I agree that looking after sensitive data is data owner
> (i.e. inmate) job. It's a bit of problem that Linux can read inmate
> memory anytime though.

While the cell is running Linux does not have access to the loadable
area anymore (see cell_start() in control.c). All the other memory
regions you assign to non-root cells should not be assigned to Linux in
the first place.

Henning

[Valentine Sinitsyn]

On 05.11.2014 16:34, Henning Schild wrote:
> While the cell is running Linux does not have access to the loadable
> area anymore (see cell_start() in control.c). All the other memory
> regions you assign to non-root cells should not be assigned to Linux in
> the first place.

Yup, thanks for the hint. Should be no problems then, at least as long
as the inmate cleans up sensitive data after itself.

Valentine

[Henning Schild]

That was exactly our conclusion, i just thought it was an important
point/discussion and something to keep in mind. Hence the email.

Henning

[Valentine Sinitsyn]

On 05.11.2014 17:52, Henning Schild wrote:
> That was exactly our conclusion, i just thought it was an important
> point/discussion and something to keep in mind. Hence the email.

Sure, thank you for sharing this.

Valentine

[Jan Kiszka]

That is my model for this as well right now - at least until someone
comes with an argumentation around that it is required to clear the RAM
also in case of unexpected cell termination (what if the cell crashes?).
However, I would like to address this only with this need on the table,
not proactively.

I proposed already offlist to keep this aspect documented, e.g. in the
TODO list.

Jan

--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

[Henning Schild]

as discussed on the list
http://article.gmane.org/gmane.linux.jailhouse/1922

Signed-off-by: Henning Schild <henning...@siemens.com>
---
TODO | 1 +
1 file changed, 1 insertion(+)

diff --git a/TODO b/TODO
index cc665a7..476fde0 100644
--- a/TODO
+++ b/TODO
@@ -36,6 +36,7 @@ o setup validation
- Intel TXT support?
- secure boot?
- check for execution inside hypervisor, allow only when enabled in config
+ - clear memory regions before reassignment to prevent information leaks?
o inter-cell communication channel
- shared memory + doorbell IRQs
- queues + doorbell?
--
2.0.4

[Jan Kiszka]

Thanks, applied.

[Gustavo Lima Chaves]

I gave this issue a quick look and can anyone tell me why page_free(), at hypervisor/paging.c, does not garantee this cleaning via that memset() call?

[Jan Kiszka]

page_free() is for hypervisor-owned memory. This to-do is about guest
memory that is "allocated" by removing its mapping from one cell and
adding a mapping to another. It's not pooled like the hypervisor heap pages.

Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE