[v7,0/2] Adds starting the idle domain privileged

Message

Daniel P. Smith May 11, 2022, 11:30 a.m. UTC

This series makes it so that the idle domain is started privileged under the
default policy, which the SILO policy inherits, and under the flask policy. It
then introduces a new one-way XSM hook, xsm_transition_running, that is hooked
by an XSM policy to transition the idle domain to its running privilege level.

Changes in v7:
- adjusted error message in default and flask xsm_set_system_active hooks
- merged panic messages in arm and x86 setup.c to a single line

Changes in v6:
- readded the setting of is_privileged in flask_set_system_active()
- clarified comment on is_privileged in flask_set_system_active()
- added ASSERT on is_privileged and self_sid in flask_set_system_active()
- fixed err code returned on Arm for xsm_set_system_active() panic message

Changes in v5:
- dropped setting is_privileged in flask_set_system_active()
- added err code returned by xsm_set_system_active() to panic message

Changes in v4:
- reworded patch 1 commit messaged
- fixed whitespace to coding style
- fixed comment to coding style

Changes in v3:
- renamed *_transition_running() to *_set_system_active()
- changed the XSM hook set_system_active() from void to int return
- added ASSERT check for the expected privilege level each XSM policy expected
- replaced a check against is_privileged in each arch with checking the return
  value from the call to xsm_set_system_active()

Changes in v2:
- renamed flask_domain_runtime_security() to flask_transition_running()
- added the missed assignment of self_sid

Daniel P. Smith (2):
  xsm: create idle domain privileged and demote after setup
  flask: implement xsm_set_system_active

 tools/flask/policy/modules/xen.if      |  6 +++++
 tools/flask/policy/modules/xen.te      |  1 +
 tools/flask/policy/policy/initial_sids |  1 +
 xen/arch/arm/setup.c                   |  3 +++
 xen/arch/x86/setup.c                   |  4 ++++
 xen/common/sched/core.c                |  7 +++++-
 xen/include/xsm/dummy.h                | 17 ++++++++++++++
 xen/include/xsm/xsm.h                  |  6 +++++
 xen/xsm/dummy.c                        |  1 +
 xen/xsm/flask/hooks.c                  | 32 +++++++++++++++++++++++++-
 xen/xsm/flask/policy/initial_sids      |  1 +
 11 files changed, 77 insertions(+), 2 deletions(-)

Comments

Daniel P. Smith May 30, 2022, 5:15 p.m. UTC | #1

On 5/11/22 07:30, Daniel P. Smith wrote:
> This series makes it so that the idle domain is started privileged under the
> default policy, which the SILO policy inherits, and under the flask policy. It
> then introduces a new one-way XSM hook, xsm_transition_running, that is hooked
> by an XSM policy to transition the idle domain to its running privilege level.
> 
> Changes in v7:
> - adjusted error message in default and flask xsm_set_system_active hooks
> - merged panic messages in arm and x86 setup.c to a single line
> 

Pinging to see if there are open issues I need to address or is the
series acceptable? IIU I am missing an ACK on patch 1 of the series from
x86 and sched maintainers. If it is already in your queues, apologies
for the nag.

V/r,
Daniel P. Smith

Jan Beulich May 31, 2022, 8:22 a.m. UTC | #2

On 30.05.2022 19:15, Daniel P. Smith wrote:
> 
> On 5/11/22 07:30, Daniel P. Smith wrote:
>> This series makes it so that the idle domain is started privileged under the
>> default policy, which the SILO policy inherits, and under the flask policy. It
>> then introduces a new one-way XSM hook, xsm_transition_running, that is hooked
>> by an XSM policy to transition the idle domain to its running privilege level.
>>
>> Changes in v7:
>> - adjusted error message in default and flask xsm_set_system_active hooks
>> - merged panic messages in arm and x86 setup.c to a single line
>>
> 
> Pinging to see if there are open issues I need to address or is the
> series acceptable? IIU I am missing an ACK on patch 1 of the series from
> x86 and sched maintainers.

And a REST maintainer ack (to stand in for the designated maintainer continuing
to play dead).

Also I notice your ping did include neither x86 nor sched maintainers as (at
least) Cc.

Jan