lkml.org 
[lkml]   [2023]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Linux guest kernel threat model for Confidential Computing
    From
    On 1/25/23 6:28 AM, Reshetova, Elena wrote:
    > Hi Greg,
    >
    > You mentioned couple of times (last time in this recent thread:
    > https://lore.kernel.org/all/Y80WtujnO7kfduAZ@kroah.com/) that we ought to start
    > discussing the updated threat model for kernel, so this email is a start in this direction.
    >
    > (Note: I tried to include relevant people from different companies, as well as linux-coco
    > mailing list, but I hope everyone can help by including additional people as needed).
    >
    > As we have shared before in various lkml threads/conference presentations
    > ([1], [2], [3] and many others), for the Confidential Computing guest kernel, we have a
    > change in the threat model where guest kernel doesn’t anymore trust the hypervisor.
    > This is a big change in the threat model and requires both careful assessment of the
    > new (hypervisor <-> guest kernel) attack surface, as well as careful design of mitigations
    > and security validation techniques. This is the activity that we have started back at Intel
    > and the current status can be found in
    >
    > 1) Threat model and potential mitigations:
    > https://intel.github.io/ccc-linux-guest-hardening-docs/security-spec.html>
    > 2) One of the described in the above doc mitigations is "hardening of the enabled
    > code". What we mean by this, as well as techniques that are being used are
    > described in this document: > https://intel.github.io/ccc-linux-guest-hardening-docs/tdx-guest-hardening.html

    Regarding driver hardening, does anyone have a better filtering idea?

    The current solution assumes the kernel command line is trusted and cannot
    avoid the __init() functions that waste memory. I don't know if the
    __exit() routines of the filtered devices are called, but it doesn't sound
    much better to allocate memory and free it right after.

    >
    > 3) All the tools are open-source and everyone can start using them right away even
    > without any special HW (readme has description of what is needed).
    > Tools and documentation is here:
    > https://github.com/intel/ccc-linux-guest-hardening
    >
    > 4) all not yet upstreamed linux patches (that we are slowly submitting) can be found
    > here: https://github.com/intel/tdx/commits/guest-next
    >
    > So, my main question before we start to argue about the threat model, mitigations, etc,
    > is what is the good way to get this reviewed to make sure everyone is aligned?
    > There are a lot of angles and details, so what is the most efficient method?
    > Should I split the threat model from https://intel.github.io/ccc-linux-guest-hardening-docs/security-spec.html
    > into logical pieces and start submitting it to mailing list for discussion one by one?
    > Any other methods?
    >
    > The original plan we had in mind is to start discussing the relevant pieces when submitting the code,
    > i.e. when submitting the device filter patches, we will include problem statement, threat model link,
    > data, alternatives considered, etc.
    >
    > Best Regards,
    > Elena.
    >
    > [1] https://lore.kernel.org/all/20210804174322.2898409-1-sathyanarayanan.kuppuswamy@linux.intel.com/
    > [2] https://lpc.events/event/16/contributions/1328/
    > [3] https://events.linuxfoundation.org/archive/2022/linux-security-summit-north-america/program/schedule/

    Thanks,
    Carlos

    \
     
     \ /
      Last update: 2023-03-27 00:11    [W:4.237 / U:0.336 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site