On 2017-08-09 15:47, Gustavo Lima Chaves wrote: > * Jan Kiszka <[email protected]> [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. Jan -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
