lkml.org 
[lkml]   [2019]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Documentation/admin-guide: Embargoed hardware security issues
    On Thu, 25 Jul 2019, Jonathan Corbet wrote:
    > > Note, this document has gone through numerous reviews by a number of
    > > kernel developers, developers at some of the Linux distros, as well as
    > > all of the lawyers from almost all open source-related companies. It's
    > > been sitting on my local drive with no comments for a few months now,
    > > and it's about time to get this out and merged properly.
    > >
    > > If anyone has any final comments, please let me know.
    >
    > I do think it could benefit from a pass for basic language issues; I can do
    > that if such an effort would be welcome.

    Definitely!

    > > +
    > > +The list is encrypted and email to the list can be sent by either PGP or
    > > +S/MIME encrypted and must be signed with the reporter's PGP key or S/MIME
    > > +certificate. The list's PGP key and S/MIME certificate are available from
    > > +https://www.kernel.org/....
    >
    > Somebody needs to fill in some dots there...:)

    Yes. I need to sort that out with Konstantin before the thing gets merged,
    but we wanted to give it a wider audience in general.

    > > +The hardware security team identifies the developers (domain experts) which
    > > +form the initial response team for a particular issue. The initial response
    >
    > s/which form/who will form/
    >
    > > +team can bring in further developers (domain experts) to address the issue
    > > +in the best technical way.
    >
    > Does the reporter get any say in who can be in this group? That should
    > probably be made explicit either way.

    See below.

    > > +The hardware security team will provide the disclosing party a list of
    > > +developers (domain experts) who should be informed initially about the
    > > +issue after confirming with the developers that they will adhere to this
    > > +Memorandum of Understanding and the documented process. These developers
    > > +form the initial response team and will be responsible for handling the
    > > +issue after initial contact. The hardware security team is supporting the
    > > +response team, but is not necessarily involved in the mitigation
    > > +development process.
    >
    > Again, "should be informed" is conditional, suggesting that the reporter
    > might have some sort of veto power. But the actual policy is not clear.

    Yes and no. That's a tricky field. We surely need some agreement with the
    reporter/owner, but of course we want as much freedom here as we can
    get. The past issues were always a pain when we had the need to get a
    particular expert into the group.

    > > +While individual developers might be covered by a non-disclosure agreement
    > > +via their employer, they cannot enter individual non-disclosure agreements
    > > +in their role as Linux kernel developers. They will, however, adhere to
    > > +this documented process and the Memorandum of Understanding.
    >
    > They will *agree to* adhere ... We expect that actual adherence will be
    > the case but there is no way (even if an NDA were involved) to guarantee
    > that.

    Correct.

    > > +Disclosure
    > > +""""""""""
    > > +
    > > +The disclosing party provides detailed information to the initial response
    > > +team via the specific encrypted mailing-list.
    > > +
    > > +From our experience the technical documentation of these issues is usually
    > > +a sufficient starting point and further technical clarification is best
    > > +done via email.
    > > +
    > > +Mitigation development
    > > +""""""""""""""""""""""
    > > +
    > > +The initial response team sets up an encrypted mailing-list or repurposes
    > > +an existing one if appropriate. The disclosing party should provide a list
    > > +of contacts for all other parties who have already been, or should be
    > > +informed about the issue. The response team contacts these parties so they
    > > +can name experts who should be subscribed to the mailing-list.
    > > +
    > > +Using a mailing-list is close to the normal Linux development process and
    > > +has been successfully used in developing mitigations for various hardware
    > > +security issues in the past.
    > > +
    > > +The mailing-list operates in the same way as normal Linux development.
    > > +Patches are posted, discussed and reviewed and if agreed on applied to a
    > > +non-public git repository which is only accessible to the participating
    > > +developers via a secure connection. The repository contains the main
    > > +development branch against the mainline kernel and backport branches for
    > > +stable kernel versions as necessary.
    >
    > Do we want to envision a KPTI-like situation where the mitigation can be
    > developed publicly? Or perhaps just handle any such case if and when it
    > ever arises?

    Yes, we handle that when it happens which is hopefully never.

    > > +Process ambassadors
    > > +-------------------
    > > +
    > > +For assistance with this process we have established ambassadors in various
    > > +organizations, who can answer questions about or provide guidance on the
    > > +reporting process and further handling. Ambassadors are not involved in the
    > > +disclosure of a particular issue, unless requested by a response team or by
    > > +an involved disclosed party. The current ambassadors list:
    > > +
    > > + ============== ========================================================
    > > + ARM
    > > + AMD
    > > + IBM
    > > + Intel
    > > + Qualcomm
    > > +
    > > + Microsoft
    > > + VMware
    > > + XEN
    > > +
    > > + Canonical
    > > + Debian
    > > + Oracle
    > > + Redhat
    > > + Suse Jiri Kosina <jkosina@suse.com>
    > > +
    > > + Amazon
    > > + Google
    > > + ============== ========================================================
    >
    > Having companies without names seems a little weird. Unless perhaps you
    > have people teed up to add their names in follow-on patches?

    We already talked to companies and the names should come forth before this
    is finished.

    > > +Encrypted mailing-lists
    > > +-----------------------
    > > +
    > > +We use encrypted mailing-lists for communication. The operating principle
    > > +of these lists is that email sent to the list is encrypted either with the
    > > +list's PGP key or with the list's S/MIME certificate. The mailing-list
    > > +software decrypts the email and re-encrypts it individually for each
    > > +subscriber with the subscriber's PGP key or S/MIME certificate. Details
    > > +about the mailing-list software and the setup which is used to ensure the
    > > +security of the lists and protection of the data can be found here:
    > > +https://www.kernel.org/....
    >
    > That URL is also in need of completion.
    >
    > The topic of encrypted mailing lists is visited several times in this
    > document; I wonder if that could be coalesced somehow?

    Suggestions welcome.

    > > +Each subscriber needs to send a subscription request to the response team
    > > +by email. The email must be signed with the subscriber's PGP key or S/MIME
    > > +certificate. If a PGP key is used, it must be available from a public key
    > > +server and is ideally connected to the Linux kernel's PGP web of trust. See
    > > +also: https://www.kernel.org/signature.html.
    >
    > The "public key server" thing isn't working quite as well as it was; does
    > this requirement need to be revisited?

    I think so. That was written way before that mess happened.

    Thanks,

    tglx

    \
     
     \ /
      Last update: 2019-07-26 16:48    [W:2.589 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site