* Jan Kiszka <jan.kis...@web.de> [2017-08-11 18:22:05 +0000]: > On 2017-08-09 15:47, Gustavo Lima Chaves wrote: > > * Jan Kiszka <jan.kis...@web.de> [2017-08-08 20:17:50 -0400]: > > > >> On 2017-08-07 19:24, Gustavo Lima Chaves wrote: > >>> With the new JAILHOUSE_CELL_CLEAR_MEM (struct jailhouse_cell_desc's) > >>> flag, Jailhouse will cleanup all of the cell's *loadable* memory, on its > >>> destruction, before handing that memory region back to the root cell. > >>> This prevents the latter from accessing data that the former wanted to > >>> keep private. > >>> > >>> One could argue that cells without passive communication > >>> region (no JAILHOUSE_CELL_PASSIVE_COMMREG flag) could use a first > >>> attempt to kill them to do any desired cleanup. This does not cover the > >>> cases in which the cell developer still wants passive communication > >>> region (they don't want to bother adding code to read/write to the comms > >>> region address to their logic) but no data leaks whatsoever. This also > >>> covers the case in which a cell goes to parked state and never has the > >>> chance to do such cleanup: with the new flag, when destroyed the root > >>> cell will still be clueless of what happened there memory-wise. > >> > >> I would buy the case of leaking data on crash - if you have a concrete > >> use case (I heard a couple of times about potential security use cases, > >> but I'm lacking a confirmation of an implementation). Can you elaborate? > > > > Well, at least on ADAS world, there might be ECU software (that in > > Jailhouse world would translate to an inmate) that is kind of > > self-contained (senses and actuates on its behalf only, with access to > > its I/O) and would only interface with the world outside it with some > > sort of watchdog mechanism. The vendor of such software would have the > > choice to protect its IP better if noone would have access to the > > resulting runtime memory, with the help of the hypervisor. > > > > The feature is indeed for "extreme" cases, but for sure they exist. > > OK, I'm open to consider the feature at the point your can replace that > "there might be" in the first sentence with some "there is". One "there > is" that case, please make sure to reduce code duplication (paging_map > and paging_map_device are widely identical) and split up that > refactoring from the feature introduction. > > I would even lean towards making the wipe feature unconditional then, > just to reduce the variation. If that turns out to be too costly for > other cases, a per mem-region control would be better than a per cell > switch.
Very fair, thanks. Bookmarking this to revisit soonish :) > > Jan -- Gustavo Lima Chaves Intel - Open Source Technology Center -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
