On 2017-08-22 12:34, Gustavo Lima Chaves wrote: > * Henning Schild <[email protected]> [2017-08-22 13:08:47 +0000]: > >> Am Mon, 21 Aug 2017 17:20:56 -0700 >> schrieb Gustavo Lima Chaves <[email protected]>: >> >>> Hi, >>> >>> what's the intention with the current design where inmates have access >>> to cell_state (COMM_REGION_GENERIC_HEADER)? Is this safe? I was able >>> to replicate what apic-demo.c does WRT that in a Zephyr binary as >>> well, just to be sure. >> >> I am afraid i do not get the question. With "have access" you mean they >> can read and write the value and the change becomes visible to others >> i.e. hypervisor and root-cell? > > Yeah, I'm mainly concerned with cells being parked scenario (and > somehow faking another state different than JAILHOUSE_CELL_FAILED), > but I guess we're fine at panic_park(), since the cell won't be able > to run any instruction from that point on, right?
Right, once we panic'ed all cell CPUs, there is no more possibility for that cell to change the state. > >> >> There are three values that actually have a meaning and change the >> behavior of the hypervisor (_FAILED, _SHUT_DOWN and RUNNING_LOCKED). >> Setting itself to FAILED or SHUT_DOWN the cell would not receive >> messages anymore, does not seem too bad for others. And we already >> discussed what RUNNING_LOCKED is for. >> >> Could you describe a scenario where the control of this variable is >> unsafe/problematic? >> >>> Isn't ./tools/jailhouse cell list or, better yet, >>> /sys/devices/jailhouse/cells/XXX/state a means for the root cell to >>> watch cell states in order to act on them (assuming "open" model from >>> https://events.linuxfoundation.org/sites/events/files/slides/ELCE2016-Jailhouse-Tutorial.pdf)? >>> If so, how can we trust the cells setting their states and not the >>> hypervisor only? >> >> I think the only case in which a cell would want to / have to set the >> state itself is RUNNING_LOCKED. You can probably invent a few custom >> states that only your cell and your rootcell sysfs watchdog know about, >> if you want to have such a thing. >> >> Maybe you have an example for the problematic case where a cell fails >> to update its state causing trouble in the rest of the system? > > I think I get the workings now, thanks! > Well, your concerns made me look at the code again. And if you haven't done that for a while, I see things that you missed before: It seems like even cells that have JAILHOUSE_CELL_PASSIVE_COMMREG set can cause some effect when setting themselves to RUNNING_LOCKED. That would be a bug, because passive cells shall not be able to lock the system. Requires a second check, though, maybe also for other cases. Any concrete findings or patches always welcome! 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.
