* Jan Kiszka <[email protected]> [2017-08-22 23:31:24 +0000]: > 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).
I like that :) > > 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. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
