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:0.160 / U:18.388 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site