Message-ID: <alpine.DEB.2.21.1907261522050.1791@nanos.tec.linutronix.de>
Date:   Fri, 26 Jul 2019 16:47:35 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Jonathan Corbet <corbet@....net>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, security@...nel.org,
        linux-doc@...r.kernel.org, Jiri Kosina <jkosina@...e.com>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
Subject: Re: [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@...e.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

Powered by blists - more mailing lists