On 2017-08-22 19:02, Jan Kiszka wrote: > 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!
Looking closer, I think we should simply configure the comm region of passive cells read-only. That would solve the issue AND even make sense (passive means, well, not actively communicating). 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.
