linux-kernel - RE: Linux guest kernel threat model for Confidential Computing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN0PR11MB5758C701F81E701851ECA729E7D89@BN0PR11MB5758.namprd11.prod.outlook.com>
Date:   Wed, 8 Feb 2023 10:16:14 +0000
From:   "Reshetova, Elena" <elena.reshetova@...el.com>
To:     Carlos Bilbao <carlos.bilbao@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     "Shishkin, Alexander" <alexander.shishkin@...el.com>,
        "Shutemov, Kirill" <kirill.shutemov@...el.com>,
        "Kuppuswamy, Sathyanarayanan" <sathyanarayanan.kuppuswamy@...el.com>,
        "Kleen, Andi" <andi.kleen@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        "Wunner, Lukas" <lukas.wunner@...el.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        "Poimboe, Josh" <jpoimboe@...hat.com>,
        "aarcange@...hat.com" <aarcange@...hat.com>,
        Cfir Cohen <cfir@...gle.com>, Marc Orr <marcorr@...gle.com>,
        "jbachmann@...gle.com" <jbachmann@...gle.com>,
        "pgonda@...gle.com" <pgonda@...gle.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        James Morris <jmorris@...ei.org>,
        Michael Kelley <mikelley@...rosoft.com>,
        "Lange, Jon" <jlange@...rosoft.com>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: RE: Linux guest kernel threat model for Confidential Computing

> No relation other than it would be nice to have a solution that does not
>require kernel command line and that prevents __init()s.

For __inits see below. For the command line, it is pretty straightforward to 
measure it and attest its integrity later: we need to do it for other parts
anyhow as acpi tables, etc. So I don’t see why we need to do smth special
about it? In any case it is indeed very different from driver discussion and
goes into "what should be covered by attestation for CC guest" topic. 

> More pressing concern than wasted memory, which may be unimportant, there's
> the issue of what are those driver init functions doing. For example, as
> part of device setup, MMIO regs may be involved, which we cannot trust. It's
> a lot more code to worry about from a CoCo perspective.

Yes, we have seen such cases in kernel where drivers or modules would access
MMIO or pci config space already in their __init() functions. 
Some concrete examples from modules and drivers (there are more):

 intel_iommu_init() -> init_dmars() -> check_tylersburg_isoch()
skx_init() -> get_all_munits()
skx_init() -> skx_register_mci() -> skx_get_dimm_config()
intel_rng_mod_init() -> intel_init_hw_struct()
i10nm_exit()->enable_retry_rd_err_log ->__enable_retry_rd_err_log()

However, this is how we address this from security point of view:

1. In order for a MMIO read to obtain data from a untrusted host, the memory
range must be shared with the host to begin with. We enforce that
all MMIO mappings are private by default to the CC guest unless it is 
explicitly shared (and we do automatically share for the authorized devices
and their drivers from the allow list). This removes a problem of an 
"unexpected MMIO region interaction"
(modulo acpi AML operation regions that we do have to share also unfortunately,
but acpi is a whole different difficult case on its own).

2. For pci config space, we limit any interaction with pci config
space only to authorized devices and their drivers (that are in the allow list).
As a result device drivers outside of the allow list are not able to access pci
config space even in their __init routines. It is done by setting the
to_pci_dev(dev)->error_state = pci_channel_io_perm_failure for non-authorized
devices. 

 So, even if host made the driver __init function to run
(by faking the device on the host side), it should not be able to supply any
malicious data to it via MMIO or pci config space, so running their __init 
routines should be ok from security point of view or does anyone see any
holes here? 

Best Regards,
Elena.