- TSC - lists.trustedfirmware.org

TSC Agenda 12 Sep 2019

by Abhishek Pandit

Hi All, Any agenda items? We have following at present: * Update on Twin CPU enablement work in TF-M (Chris Brand, Cypress) * Secure provisioning discussion (Data I/O) Thanks, Abhishek

6 years, 5 months

1
0
0 0

Overview of being a CVE CNA

by David Brown

This screencast goes through the process I used to manage a CVE as part of being the CNA for the Zephyr project. Not all of the links will be accessible, but this should give a rough idea of the kind of work involved in being a CNA. https://www.youtube.com/watch?v=PksNzJXVDDA David

6 years, 6 months

1
0
0 0

Trusted Firmware TSC 8th August Minutes

by Bill Fletcher

Attendees AbhishekP - Arm DanH - Arm DavidB - Linaro MarkG - TI JoakimB - Linaro OP-TEE ChristianD - Cypress JuliusW - Google KumarG - Linaro LITE KevinT - Linaro LITE BillF - Linaro Community Projects Agenda OP-TEE How to add more maintainers AOB Notes: OP-TEE (Joakim’s slides) BF: OP-TEE now visible via trustedfirmware.org DH: No links to code etc BF: Yes, just a first step that we can reference in any press release/blog post. It links back to the main material at op-tee.org JB: Have cleaned up op-tee.org content and not a big job to move it to trustedfirmware.org JB: Certifications. Should now revisit. However - there are many - need to figure out what to spend the money on. CD: Don’t certify in a vacuum JB: Yes - video, payment ... DH: … common criteria, safety. Generally need to certify a product, but helps if know what you’re aiming for. JB: Previously aimed at GC test suite that benefits everyone. DB: FIPS certification AP: At Arm have often focussed on ‘certifiable’ rather than certified. JB: Sounds sane AP: A lot of certifications have some common stuff - e.g. basic MISRA, some threat model, lifecycle. JB: If you clone the git repo you’ll get a test suite - xtest. You will not get anything from GlobalPlatform. You can include it but you have to be a member or buy it. It’s $6000 and includes support for 2 years. In Linaro we have relied on member’s access to use the test suite. DH: Code audits are good but take a hit - need to have all requirements in place first like incident handling and lifecycle. They are expensive. DH: For vulnerability reporting, have discussed increasing embargo period & especially sensitive stakeholders. DB: Zephyr is now a CNA. Organisation has to be a CNA but in the scope of particular project(s). We’re receiving CVEs for the Zephyr project. It might make sense for TF to become one. DH: Process supposed to use for OSS doesn’t seem to work at all. DB: End up going to the CNA of last resort. Much more responsive to CNAs than random projects. JB: tf.org/security should go to the various security centres and this policy that we’re trying to approve. Action DH to give BF an outline of what should be on the security front page JB: Any interest on TF TSC that I present the plan for the coming cycle? Action: JB to check with Mark Orvek if ok to share the OP-TEE information from the project heathcheck. CD: Generally take same approach as TF-A and TF-M. Share the information but TF TSC not to be a bottleneck and have to ‘approve’. If there’s a specific issue can discuss it at TSC. DH: For the fork, we’d be trying to keep up with op-tee master and submit back through the op-tee process. Don’t want to run on a branch for the long term. DH: Encrypted TEEs. Has always been a provision for encrypted TA’s. Architecture allows for it but have had no strong pull for implementing it. JB: Tricky part is key management DH: May be a requirement on TF-A to help here. JB: Haven’t really planned on this but seeing requirements. No requirements from PSA? DH: no - the requirements are on authentication, not encryption. DH: (Next steps) Expand the list of acceptable licenses. AP: (Documenting answers and decisions) Both TF projects are using Phabricator. Action: JB to contact Ben and try out the Phabricator sandbox. DH: Anything holding back to setup an op-tee project in gerrit? JB: Have an action to talk to Ben about setting that up Maintainers AP: Looking at ways to expand maintainers list since have gaps during vacation period JB: Where is the list? AP: Keep the maintainer list in gerrit AP: Ask other members to talk about non-confidential items. If there are external companies - maintainers should be able to invite them to attend. Action: BF to add link to review.trustedfirmware.org to Nav bar DB: If I go to developer.trustedfirmware.org and click on https://developer.trustedfirmware.org/project/ only see TF-A. CD: Seems that project takes the first query https://developer.trustedfirmware.org/project/query/edit/. Can an administrator change the order of the queries? Action: Move the usability discussion to the mailing list since there are people actively working on Phabricator. Attendance: DH: (In response to KT) anyone should be able to join as long as we know who they are from a member company. When it comes to voting that’s specific to reps. AP: If someone additional invited announce it at the start of the meeting. Date for the next meeting? AP: 12th Sept. -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 6 months

1
0
0 0

TSC Agenda 08 Aug 2019

by Abhishek Pandit

Hi All, We already have one topic: * OP-TEE update (Joakim) Any other agenda items? Thanks, Abhishek

6 years, 6 months

1
0
0 0

Re: [TF-TSC] tf.org security incident handling process (v0.3)

by Dan Handley

Hi Joakim Thanks for reviewing. Some further comments below. > From: Joakim Bech <joakim.bech(a)linaro.org> > Sent: 11 July 2019 13:11 > To: Dan Handley <Dan.Handley(a)arm.com> > Cc: tsc(a)lists.trustedfirmware.org > Subject: Re: [TF-TSC] tf.org security incident handling process (v0.3) > > Hi Dan and TF reps, > > Thanks for putting this together Dan. I like it and it's pretty short and > concise. Nothing big from me, but please find a few comments from me inline > below. > >> On Wed, 10 Jul 2019 at 18:35, Dan Handley via TSC >> <mailto:tsc@lists.trustedfirmware.org> wrote: >> Hi TF TSC >> >> This is a v0.3 update to the proposed http://tf.org security incident >> handling process, which I sent previously, incorporating the comments I've >> had since then. >> <snip> >> >> If you would like replies to be encrypted, please provide your public key. >> Please note the Trusted Firmware security team cannot guarantee that >> encrypted information will remain encrypted when shared with trusted third >> parties. >> >> [DH: Is this acceptable? It allows reporters to use encryption without adding >> too much admin burden on the security team. The alternative is to force >> everyone receiving embargoed information to provide an encryption key and >> decrypt/re-encrypt as information is passed around. I think this adds too >> much overhead without significant security benefit.] > [JB: I do think this is the right level of dealing with this. The > communication with the one reporting the issue can (optionally) be encrypted, > but for sharing between members of the security team I think it's easier to > use things like LDAP protections, Google docs, GitHub private security > advisories (https://help.github.com/en/articles/collaborating-in-a-temporary- > private-fork-to-resolve-a-security-vulnerability) etc.] > I'm glad we're in agreement. I hadn't seen that GitHub security advisory support before - thanks! <snip> >> 3. After the primary embargo period, the fix and relevant vulnerability >> information are shared with registered Trusted Stakeholders (see below >> section). Fix release may be deferred further if a Trusted Stakeholder >> requests it within 1 working day (Monday to Friday) of being notified, > [JB: One day is not much time, there is a chance that people on the receiving > end misses this for both good and bad reasons. However, I don't know how many > days that would be sufficient. In the end these kind of things require some > discipline and extra efforts from both sides.] > I think you're right this is a bit too aggressive. The window for requesting the primary embargo period is extremely short because we expect ESS security teams to operate 24/7 and we want to minimise the delay in proceeding to the next stage when ESSes are unaffected. But Trusted Stakeholders may need more time. We don't want to unnecessarily delay release of fixes but increasing this window a bit is unlikely to cause a problem in practice: If there is no primary embargo period it's likely we'll need at least a few days to prepare a fix anyway; if there is a primary embargo period, it's likely we'll need a secondary embargo period as well. How about making this window 3 working days? <snip> >> [DH: Note, this aggressive release of security fixes is aligned with the >> kernel process. The existing TF-A process allows for early release of fixes, >> which we generally do in practice, but that process doesn't really specify a >> fix embargo period. However it does specify a 4 week embargo on the >> subsequent security advisory. Also note that OP-TEE's fix embargo period is >> 90 days, which is aligned with Google's policy.] > [JB: Right, our initial OP-TEE embargo period was much shorter, but after > getting feedback from our members it was clear that they preferred a longer > embargo, which was the reason we went back to 90 days. Did we end up asking > other people? TF members? Companies that we know are using TF-A/M?] Sorry, I haven't sought any wider feedback. This is purely based on the Google and OP-TEE policies, which I (and I think TF-A partners would) find reasonable. Given that the fixes are made much earlier, I don't see anyone objecting to this longer advisory embargo, except perhaps some reporters. >> 4. After the fix is released, details of the security vulnerability are >> consolidated into a security advisory. This includes a CVE number and the >> security team will request one if not already done by the reporter. It also >> includes credit to the reporter unless they indicate otherwise. Drafts of the >> security advisory are circulated with the reporter, ESSes and Trusted >> Stakeholders as they become available. > [JB: Do we want to have our own numbering schema also? If we believe _all_ > issues will get a CVE number then it's not needed. But if there are issues > that for whatever reasons wouldn't get a CVE, then it's quite useful to have > some internal numbering system. Out of experience, I know that it can become > quite messy if you get a report containing lots of potential security issues. > Having an internal number to use in commits etc has been proven to be quite > useful.] > Yes, I do expect to have our own numbering scheme for the reasons you state. I thought this could be covered by a supplementary internal process, which we could create after this external process is approved. Let me know if you think we should say something here instead. >> 5. 90 days after the vulnerability was reported, the security advisory is >> made public at https://www.trustedfirmware.org/. This 90 day window is the >> public embargo period. >> >> [DH: This public embargo period aligns with Google and OP-TEE processes, >> although this proposal releases fixes earlier.] >> >> In exceptionally rare cases, the above disclosure plan may be extended in >> consultation with the reporter, ESSes and Trusted Stakeholders, for example >> if it is very difficult to develop or deploy a fix, or wider industry >> consultation is needed. >> >> [DH: I'm accommodating for the Spectre/Meltdown case here] >> > [JB: So, is it fair to write the complete timeline as Fast case > | Report given to TF: <X days> | <X days + 1>: first embargo | <+ 1 > | day>: second embargo | <+ 90>: public security advisory | > i.e "X days + 1 + 1 + 90 = X days + 92" > > "Worst" case (mentioned in your attached PDF) > | Report given to TF: <X days> | <X days + 14>: first embargo | <+ 14 > | day>: second embargo | <+ 90>: public security advisory | > i.e "X days + 14 + 14 + 90" = X days + 118 > > Or are the dates running in parallel so to say? Example: public advisory is > always X days + 90?] > The latter! It should always be X days + 90. The above says "90 days after the vulnerability was reported". Let me know if I can make this clearer somehow. <snip> >> Note, the security team reserves the right to deny registration or revoke >> membership to the Trusted Stakeholders list, for example if it has concerns >> about the confidentiality of embargoed information. > [JB: Only stakeholders list? What about ESS list?] > OK, I'll include that too. >> [DH: Note, I've not included severity scoring in this proposal, as I think >> the only value of a score is helping to determine whether a bug is a security >> vulnerability or not, which in the end has a subjective element. I'm open to >> the idea of adding this to the process but I'd prefer it to be optional and >> aligned with CVSSv3 as used by CVE.] > [JB: Agree and regarding the process I'm quite open to have a look at CVSSv3. > The current OP-TEE process is better than the first one, but it's still a bit > rough around the edges. If CVSSv3 works for TF-A/M, then I'll probably also > work for OP-TEE. Also, something that I've been missing when doing work like > this is an internal process also. But that's definitely out of scope for this > discussion.] > OK but the process currently doesn't say anything about scoring. I guess we can look at CVSv3 later if there's a need. I agree we will need internal process documentation as well but that can be worked through later. I can ask the current TF-A security team to help with this. Regards Dan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 7 months

1
0
0 0

Trusted Firmware TSC 11th July Minutes

by Bill Fletcher

Attendees AbhishekP - Arm DanH - Arm DavidB - Linaro MarkG - TI ChristianD - Cypress JuliusW - Google LionelD - ST BillF - Linaro Community Projects Agenda Pending action items Round table Notes Pending actions: Bill to find out about cost of internal Sphinx hosting Gerrit hooks topic was clarified separately BF: Cost of Sphinx hosting will be more than readthedocs ad-free but certainly possible AP: Proposal to go ahead with readthedocs hosting for now and add a link from the website No objections in the call. BF: Will also re-look at Sphinx with TF-A CI ongoing work. CD: Top 2 Engineering topics would be a good input to the agenda - bring it into the forum - ongoing ‘topic du jour’. DH: Is it for knowledge sharing? Not sure TSC is for design review. CD: Bit of both. Information input and where people raise flags/concerns.Might not be discussed here but could be separate meetings. DH: Design reviews should be happening in a public design list. AP: Are only few open design discussions DH: Bigger problem in TF-A than TF-M AP: In TF-M there are some discussions happening on the mailing list AP: Do you think some of the partner engineers would join design review calls? CD: Yes - hence kick off to a separate call from the TSC discussion BF: Topic for next meeting could be OP-TEE since the vote has been passed by the Board. Need to make sure Joakim could make it. DB: Getting close to TF-M bootloader upstreaming JW: Should we pro-actively cancel if we don’t have items BF: Will mail the day before to give the option to cancel in future LD: Open Source Firmware - sponsoring that event. Any plans? DH: Matteo has had a session accepted BF: Also we will have a table and some promotion material AP: Next meeting proposed to be 8th August -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 7 months

1
0
0 0

Re: [TF-TSC] tf.org security incident handling process (v0.3)

by Joakim Bech

Hi Dan and TF reps, Thanks for putting this together Dan. I like it and it's pretty short and concise. Nothing big from me, but please find a few comments from me inline below. On Wed, 10 Jul 2019 at 18:35, Dan Handley via TSC < tsc(a)lists.trustedfirmware.org> wrote: > Hi TF TSC > > This is a v0.3 update to the proposed tf.org security incident handling > process, which I sent previously, incorporating the comments I've had since > then. > > Changes: > * Changed ESS 1 day response window to be from date of notification, not > from date of fix availability. > * Restored the 7 days embargo limit with 14 days in exceptional cases, to > align with kernel process. > * Explicitly stated that it is permitted to point others to a public > vulnerability fix during an embargo period, as long as this is not > identified as a vulnerability. > > I propose that the deadline for feedback is the end of next week (19th > July), with a view to approving the process at the August TSC meeting. We > can discuss this more at tomorrow's TSC meeting. > > Regards > > Dan. > > --- > > This security incident handling process proposal is broadly based on the > kernel process [1], with influence from the existing TF-A [2] and OP-TEE > [3] processes. > > [DH: Note the contrast with the kernel process: mailto:security@kernel.org > is exclusively about fixing the vulnerability; disclosure is delegated to > mailto:linux-distros@vs.openwall.org [4]. This proposal combines these > activities.] > > Reporting > ========= > If you think you have found a security vulnerability, then please send an > email to the Trusted Firmware security team at mailto: > security(a)trustedfirmware.org. This is a private team of security officers > who will help verify the security vulnerability, develop and release a fix, > and disclose the vulnerability details responsibly. Please give us time to > implement the disclosure plan described in the next section before going > public. We do our best to respond and fix any issues as soon as possible. > > As with any bug, the more information you provide, the easier it is to > diagnose and fix. If you already have a fix, please include it with your > report, as that can speed up the process considerably. Any exploit code is > very helpful. The security team may bring in extra help from area > maintainers to understand and fix the vulnerability. The security team may > share any information you provide with trusted third parties and eventually > the public unless you request otherwise. > > [DH: Note, mailto:security@kernel.org provides stronger confidentiality > guarantees because it is only interested in fixes, not disclosure. In > practice, I'd expect members of the security team to be sensitive with > confidential information as with any other open source interactions, and to > get explicit approval from the reporter for disclosure of sensitive > information, e.g. identity, organization, product information,...] > > You may use this PGP/GPG key [insert link] for encrypting the > vulnerability information. This key is also available at > http://keyserver.pgp.com and LDAP port 389 of the same server. The > fingerprint for this key is: > > [Insert Fingerprint] > > If you would like replies to be encrypted, please provide your public key. > Please note the Trusted Firmware security team cannot guarantee that > encrypted information will remain encrypted when shared with trusted third > parties. > > [DH: Is this acceptable? It allows reporters to use encryption without > adding too much admin burden on the security team. The alternative is to > force everyone receiving embargoed information to provide an encryption key > and decrypt/re-encrypt as information is passed around. I think this adds > too much overhead without significant security benefit.] > [JB: I do think this is the right level of dealing with this. The communication with the one reporting the issue can (optionally) be encrypted, but for sharing between members of the security team I think it's easier to use things like LDAP protections, Google docs, GitHub private security advisories ( https://help.github.com/en/articles/collaborating-in-a-temporary-private-fo…) etc.] > > If the security team consider the bug not to be a security vulnerability, > you will be informed and the bug directed to the standard bug fixing > process. > > > Disclosure > ========== > The general security vulnerability disclosure plan is as follows: > > 1. For confirmed security vulnerabilities, develop a robust fix as soon as > possible. During this time, information is only shared with the reporter, > those needed to develop the fix and Especially Sensitive Stakeholders > (ESSes). See the "ESS and Trusted Stakeholder registration" section below > for more information about ESSes. > > 2. After a robust fix becomes available, our preference is to publicly > release it as soon as possible. This will automatically happen if the > vulnerability is already publicly known. However, release may be deferred > if the reporter or an ESS requests it within 1 calendar day of being > notified, and the security team agree the criticality of the vulnerability > requires more time. The requested deferral period should be as short as > possible, up to 7 calendar days after the fix becomes available, with an > exceptional extension to 14 calendar days. The only valid reason for > release deferral is to accommodate deployment of the fix by ESSes. If it is > immediately clear that ESSes are unaffected by the vulnerability then this > stage is skipped. This 0-14 day deferral is the primary embargo period. > > [DH: Note, this stage is only relevant for TF-A currently.] > > [DH: Note, this assumes that ESS security teams operate 7 days a week.] > > 3. After the primary embargo period, the fix and relevant vulnerability > information are shared with registered Trusted Stakeholders (see below > section). Fix release may be deferred further if a Trusted Stakeholder > requests it within 1 working day (Monday to Friday) of being notified, [JB: One day is not much time, there is a chance that people on the receiving end misses this for both good and bad reasons. However, I don't know how many days that would be sufficient. In the end these kind of things require some discipline and extra efforts from both sides.] > and the security team agree the criticality of the vulnerability requires > more time. The requested deferral period should be as short as possible, up > to 7 calendar days after the Trusted Stakeholder is notified, with an > exceptional extension to 14 days. The only valid reason for further release > deferral is to accommodate deployment of the fix by a Trusted Stakeholder. > This further 1-14 day deferral is the secondary embargo period. > > Note, security fixes contain the minimum information required to fix the > bug. The accompanying vulnerability details are disclosed later. > > [DH: Note, the Trusted Stakeholder required response time is slightly > relaxed compared to the ESS response time; 1 working day as oppose to 1 > calendar day.] > > [DH: Note, this aggressive release of security fixes is aligned with the > kernel process. The existing TF-A process allows for early release of > fixes, which we generally do in practice, but that process doesn't really > specify a fix embargo period. However it does specify a 4 week embargo on > the subsequent security advisory. Also note that OP-TEE's fix embargo > period is 90 days, which is aligned with Google's policy.] > [JB: Right, our initial OP-TEE embargo period was much shorter, but after getting feedback from our members it was clear that they preferred a longer embargo, which was the reason we went back to 90 days. Did we end up asking other people? TF members? Companies that we know are using TF-A/M?] > > 4. After the fix is released, details of the security vulnerability are > consolidated into a security advisory. This includes a CVE number and the > security team will request one if not already done by the reporter. It also > includes credit to the reporter unless they indicate otherwise. Drafts of > the security advisory are circulated with the reporter, ESSes and Trusted > Stakeholders as they become available. > [JB: Do we want to have our own numbering schema also? If we believe _all_ issues will get a CVE number then it's not needed. But if there are issues that for whatever reasons wouldn't get a CVE, then it's quite useful to have some internal numbering system. Out of experience, I know that it can become quite messy if you get a report containing lots of potential security issues. Having an internal number to use in commits etc has been proven to be quite useful.] > > [DH: Note, the existing TF-A process only shares information with Trusted > Stakeholders in the form of security advisories. This proposal is more > aligned with the kernel process and means we can focus on fix development > by sharing raw vulnerability information in the early stages.] > > 5. 90 days after the vulnerability was reported, the security advisory is > made public at https://www.trustedfirmware.org/. This 90 day window is > the public embargo period. > > [DH: This public embargo period aligns with Google and OP-TEE processes, > although this proposal releases fixes earlier.] > > In exceptionally rare cases, the above disclosure plan may be extended in > consultation with the reporter, ESSes and Trusted Stakeholders, for example > if it is very difficult to develop or deploy a fix, or wider industry > consultation is needed. > > [DH: I'm accommodating for the Spectre/Meltdown case here] [JB: So, is it fair to write the complete timeline as Fast case | Report given to TF: <X days> | <X days + 1>: first embargo | <+ 1 day>: second embargo | <+ 90>: public security advisory | i.e "X days + 1 + 1 + 90 = X days + 92" "Worst" case (mentioned in your attached PDF) | Report given to TF: <X days> | <X days + 14>: first embargo | <+ 14 day>: second embargo | <+ 90>: public security advisory | i.e "X days + 14 + 14 + 90" = X days + 118 Or are the dates running in parallel so to say? Example: public advisory is always X days + 90?] > > Handling embargoed information > ============================== > On receipt of embargoed information, you must not disclose any of the > provided information beyond the group of people in your organization that > need to know about it. During the primary and secondary embargo periods, > that group of people should be limited to those entrusted to assess the > impact of the vulnerability on your organization and deploy fixes to your > products. After the secondary embargo period but during the public embargo > period, that group of people may be expanded in order to prepare your > organization's public response. The embargoed information must not be > shared outside your organization during the public embargo period under any > circumstances. It is permitted to point others to a public vulnerability > fix during an embargo period, as long as this is not identified as a > vulnerability. > > If you think another individual/organization requires access to the > embargoed information, then please ask them to register as a Trusted > Stakeholder (see next section). If you believe there has been a leak of > embargoed information then please notify the security team immediately. > > [DH: This section is stronger than the existing TF-A and OP-TEE processes, > but not as strong as the linux distros policy [4]. I hope I've struck the > right balance here.] > > The security team welcomes feedback on embargoed information at any time. > > > ESS and Trusted Stakeholder registration > ======================================== > [DH: This is broadly based on the OP-TEE policy.] > > The security team maintains a vetted list of organizations and individuals > who are considered ESSes and Trusted Stakeholders of Trusted Firmware > security vulnerabilities. Contact <mailto:security@trustedfirmware.org> > if you wish to be added to one of the lists, providing the following > information: > > 1. Which list you want to be on. This will almost always be the Trusted > Stakeholder list. > > 2. A justification of why you should be on the list. That is, why you > should know about security vulnerabilities and have access to security > fixes before they are made public. A valid reason to be on the Trusted > Stakeholder list for example, is that you use Trusted Firmware in a > deployed product. The ESS list is strictly limited to those organizations > with large scale deployments of Trusted Firmware that provide bare-metal > access on multi-tenancy systems. > > 3. An organization email address (not gmail, yahoo or similar addresses). > It is preferable for each organization to provide an email alias that you > can manage yourselves rather than providing a long list of individual > addresses. > > 4. Confirmation that the individuals in your organization will handle > embargoed information responsibly as described in the previous section. > > Note, the security team reserves the right to deny registration or revoke > membership to the Trusted Stakeholders list, for example if it has concerns > about the confidentiality of embargoed information. > [JB: Only stakeholders list? What about ESS list?] > > [DH: Note, becoming a Trusted Stakeholder in the current TF-A process > requires having a valid NDA with Arm and requesting to be added via Arm > account management. I propose that Arm send a mail to all existing > stakeholders to invite them to register for the new process.] > > [DH: Note, I expect each TF project to maintain its own ESS/Trusted > Stakeholder lists.] > [JB: Makes sense!] > > [DH: Note, I've not included severity scoring in this proposal, as I think > the only value of a score is helping to determine whether a bug is a > security vulnerability or not, which in the end has a subjective element. > I'm open to the idea of adding this to the process but I'd prefer it to be > optional and aligned with CVSSv3 as used by CVE.] > [JB: Agree and regarding the process I'm quite open to have a look at CVSSv3. The current OP-TEE process is better than the first one, but it's still a bit rough around the edges. If CVSSv3 works for TF-A/M, then I'll probably also work for OP-TEE. Also, something that I've been missing when doing work like this is an internal process also. But that's definitely out of scope for this discussion.] > > [1] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html > [2] > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/secu… > [3] https://optee.readthedocs.io/general/disclosure.html > [4] > https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the… > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc Regards, Joakim

6 years, 7 months

1
0
0 0

Re: [TF-TSC] TSC Agenda 11 Jul 2019

by Dan Handley

Hi Joakim Firstly, the meeting is tomorrow, not today - I'm not sure if that changes your attendance?! I agree the SDL could be an interesting topic, however if we discuss this tomorrow, the Arm attendees would only be expressing personal opinions as we haven't yet had time to discuss this properly within Arm. I haven't seen a deadline for my disclosure policy either but I just proposed one in my other mail. We can discuss more tomorrow. I guess we can check if anyone has anything TSC level to say about OP-TEE, though I can't think of anything specific myself. Regards Dan. From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Joakim Bech via TSC Sent: 10 July 2019 07:21 To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Cc: tsc(a)lists.trustedfirmware.org Subject: Re: [TF-TSC] TSC Agenda 11 Jul 2019 Hi Abhishek, I'm unable to attend today's meeting, but Tim Benton talked to Linaro about SDL (Security Development Lifecycle). That could be an interesting topic to discuss at some point. I.e., figure out if and how that would work with TF project(s). I think we also aimed for having a deadline for reviewing Dan's disclosure policy, however I cannot recall that I've actually seen such a deadline, did I miss it? Third thing, the board voted yes for transferring OP-TEE to TF. In board context I already have pending actions. But there might be something to discuss on TSC level also related to that. But, as said, I'm unable to attend today, so I leave it up to you whether you'd like to discuss any of my suggestions here. Regards, Joakim On Wed, 10 Jul 2019 at 08:00, Abhishek Pandit via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>> wrote: Hi All, Any agenda items for the next TSC meeting? Thanks, Abhishek -- TSC mailing list TSC(a)lists.trustedfirmware.org<mailto:TSC@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tsc IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 7 months

2
1
0 0

tf.org security incident handling process (v0.3)

by Dan Handley

Hi TF TSC This is a v0.3 update to the proposed tf.org security incident handling process, which I sent previously, incorporating the comments I've had since then. Changes: * Changed ESS 1 day response window to be from date of notification, not from date of fix availability. * Restored the 7 days embargo limit with 14 days in exceptional cases, to align with kernel process. * Explicitly stated that it is permitted to point others to a public vulnerability fix during an embargo period, as long as this is not identified as a vulnerability. I propose that the deadline for feedback is the end of next week (19th July), with a view to approving the process at the August TSC meeting. We can discuss this more at tomorrow's TSC meeting. Regards Dan. --- This security incident handling process proposal is broadly based on the kernel process [1], with influence from the existing TF-A [2] and OP-TEE [3] processes. [DH: Note the contrast with the kernel process: mailto:security@kernel.org is exclusively about fixing the vulnerability; disclosure is delegated to mailto:linux-distros@vs.openwall.org [4]. This proposal combines these activities.] Reporting ========= If you think you have found a security vulnerability, then please send an email to the Trusted Firmware security team at mailto:security@trustedfirmware.org. This is a private team of security officers who will help verify the security vulnerability, develop and release a fix, and disclose the vulnerability details responsibly. Please give us time to implement the disclosure plan described in the next section before going public. We do our best to respond and fix any issues as soon as possible. As with any bug, the more information you provide, the easier it is to diagnose and fix. If you already have a fix, please include it with your report, as that can speed up the process considerably. Any exploit code is very helpful. The security team may bring in extra help from area maintainers to understand and fix the vulnerability. The security team may share any information you provide with trusted third parties and eventually the public unless you request otherwise. [DH: Note, mailto:security@kernel.org provides stronger confidentiality guarantees because it is only interested in fixes, not disclosure. In practice, I'd expect members of the security team to be sensitive with confidential information as with any other open source interactions, and to get explicit approval from the reporter for disclosure of sensitive information, e.g. identity, organization, product information,...] You may use this PGP/GPG key [insert link] for encrypting the vulnerability information. This key is also available at http://keyserver.pgp.com and LDAP port 389 of the same server. The fingerprint for this key is: [Insert Fingerprint] If you would like replies to be encrypted, please provide your public key. Please note the Trusted Firmware security team cannot guarantee that encrypted information will remain encrypted when shared with trusted third parties. [DH: Is this acceptable? It allows reporters to use encryption without adding too much admin burden on the security team. The alternative is to force everyone receiving embargoed information to provide an encryption key and decrypt/re-encrypt as information is passed around. I think this adds too much overhead without significant security benefit.] If the security team consider the bug not to be a security vulnerability, you will be informed and the bug directed to the standard bug fixing process. Disclosure ========== The general security vulnerability disclosure plan is as follows: 1. For confirmed security vulnerabilities, develop a robust fix as soon as possible. During this time, information is only shared with the reporter, those needed to develop the fix and Especially Sensitive Stakeholders (ESSes). See the "ESS and Trusted Stakeholder registration" section below for more information about ESSes. 2. After a robust fix becomes available, our preference is to publicly release it as soon as possible. This will automatically happen if the vulnerability is already publicly known. However, release may be deferred if the reporter or an ESS requests it within 1 calendar day of being notified, and the security team agree the criticality of the vulnerability requires more time. The requested deferral period should be as short as possible, up to 7 calendar days after the fix becomes available, with an exceptional extension to 14 calendar days. The only valid reason for release deferral is to accommodate deployment of the fix by ESSes. If it is immediately clear that ESSes are unaffected by the vulnerability then this stage is skipped. This 0-14 day deferral is the primary embargo period. [DH: Note, this stage is only relevant for TF-A currently.] [DH: Note, this assumes that ESS security teams operate 7 days a week.] 3. After the primary embargo period, the fix and relevant vulnerability information are shared with registered Trusted Stakeholders (see below section). Fix release may be deferred further if a Trusted Stakeholder requests it within 1 working day (Monday to Friday) of being notified, and the security team agree the criticality of the vulnerability requires more time. The requested deferral period should be as short as possible, up to 7 calendar days after the Trusted Stakeholder is notified, with an exceptional extension to 14 days. The only valid reason for further release deferral is to accommodate deployment of the fix by a Trusted Stakeholder. This further 1-14 day deferral is the secondary embargo period. Note, security fixes contain the minimum information required to fix the bug. The accompanying vulnerability details are disclosed later. [DH: Note, the Trusted Stakeholder required response time is slightly relaxed compared to the ESS response time; 1 working day as oppose to 1 calendar day.] [DH: Note, this aggressive release of security fixes is aligned with the kernel process. The existing TF-A process allows for early release of fixes, which we generally do in practice, but that process doesn't really specify a fix embargo period. However it does specify a 4 week embargo on the subsequent security advisory. Also note that OP-TEE's fix embargo period is 90 days, which is aligned with Google's policy.] 4. After the fix is released, details of the security vulnerability are consolidated into a security advisory. This includes a CVE number and the security team will request one if not already done by the reporter. It also includes credit to the reporter unless they indicate otherwise. Drafts of the security advisory are circulated with the reporter, ESSes and Trusted Stakeholders as they become available. [DH: Note, the existing TF-A process only shares information with Trusted Stakeholders in the form of security advisories. This proposal is more aligned with the kernel process and means we can focus on fix development by sharing raw vulnerability information in the early stages.] 5. 90 days after the vulnerability was reported, the security advisory is made public at https://www.trustedfirmware.org/. This 90 day window is the public embargo period. [DH: This public embargo period aligns with Google and OP-TEE processes, although this proposal releases fixes earlier.] In exceptionally rare cases, the above disclosure plan may be extended in consultation with the reporter, ESSes and Trusted Stakeholders, for example if it is very difficult to develop or deploy a fix, or wider industry consultation is needed. [DH: I'm accommodating for the Spectre/Meltdown case here] Handling embargoed information ============================== On receipt of embargoed information, you must not disclose any of the provided information beyond the group of people in your organization that need to know about it. During the primary and secondary embargo periods, that group of people should be limited to those entrusted to assess the impact of the vulnerability on your organization and deploy fixes to your products. After the secondary embargo period but during the public embargo period, that group of people may be expanded in order to prepare your organization's public response. The embargoed information must not be shared outside your organization during the public embargo period under any circumstances. It is permitted to point others to a public vulnerability fix during an embargo period, as long as this is not identified as a vulnerability. If you think another individual/organization requires access to the embargoed information, then please ask them to register as a Trusted Stakeholder (see next section). If you believe there has been a leak of embargoed information then please notify the security team immediately. [DH: This section is stronger than the existing TF-A and OP-TEE processes, but not as strong as the linux distros policy [4]. I hope I've struck the right balance here.] The security team welcomes feedback on embargoed information at any time. ESS and Trusted Stakeholder registration ======================================== [DH: This is broadly based on the OP-TEE policy.] The security team maintains a vetted list of organizations and individuals who are considered ESSes and Trusted Stakeholders of Trusted Firmware security vulnerabilities. Contact <mailto:security@trustedfirmware.org> if you wish to be added to one of the lists, providing the following information: 1. Which list you want to be on. This will almost always be the Trusted Stakeholder list. 2. A justification of why you should be on the list. That is, why you should know about security vulnerabilities and have access to security fixes before they are made public. A valid reason to be on the Trusted Stakeholder list for example, is that you use Trusted Firmware in a deployed product. The ESS list is strictly limited to those organizations with large scale deployments of Trusted Firmware that provide bare-metal access on multi-tenancy systems. 3. An organization email address (not gmail, yahoo or similar addresses). It is preferable for each organization to provide an email alias that you can manage yourselves rather than providing a long list of individual addresses. 4. Confirmation that the individuals in your organization will handle embargoed information responsibly as described in the previous section. Note, the security team reserves the right to deny registration or revoke membership to the Trusted Stakeholders list, for example if it has concerns about the confidentiality of embargoed information. [DH: Note, becoming a Trusted Stakeholder in the current TF-A process requires having a valid NDA with Arm and requesting to be added via Arm account management. I propose that Arm send a mail to all existing stakeholders to invite them to register for the new process.] [DH: Note, I expect each TF project to maintain its own ESS/Trusted Stakeholder lists.] [DH: Note, I've not included severity scoring in this proposal, as I think the only value of a score is helping to determine whether a bug is a security vulnerability or not, which in the end has a subjective element. I'm open to the idea of adding this to the process but I'd prefer it to be optional and aligned with CVSSv3 as used by CVE.] [1] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html [2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/secu… [3] https://optee.readthedocs.io/general/disclosure.html [4] https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 7 months

1
0
0 0

Re: [TF-TSC] TSC Agenda 11 Jul 2019

by Joakim Bech

Hi Abhishek, I'm unable to attend today's meeting, but Tim Benton talked to Linaro about SDL (Security Development Lifecycle). That could be an interesting topic to discuss at some point. I.e., figure out if and how that would work with TF project(s). I think we also aimed for having a deadline for reviewing Dan's disclosure policy, however I cannot recall that I've actually seen such a deadline, did I miss it? Third thing, the board voted yes for transferring OP-TEE to TF. In board context I already have pending actions. But there might be something to discuss on TSC level also related to that. But, as said, I'm unable to attend today, so I leave it up to you whether you'd like to discuss any of my suggestions here. Regards, Joakim On Wed, 10 Jul 2019 at 08:00, Abhishek Pandit via TSC < tsc(a)lists.trustedfirmware.org> wrote: > Hi All, > > > > Any agenda items for the next TSC meeting? > > > > Thanks, > > Abhishek > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc >

6 years, 7 months

1
0
0 0

TSC Agenda 11 Jul 2019

by Abhishek Pandit

Hi All, Any agenda items for the next TSC meeting? Thanks, Abhishek

6 years, 7 months

1
0
0 0

Trusted Firmware Project Update and Roadmap

by Shebu Varghese Kuriakose

Hi, Here is the Trsuted Firmware Project progress and roadmap published yesterday https://www.trustedfirmware.org/blog/trusted-firmware-update-may19/ Regards, Shebu

6 years, 8 months

1
0
0 0

TF-M L2 cert slides

by Ashutosh Singh

Hi, Slides that I presented in the last TSC meeting attached, happy to answer further questions. Thanks, Ashu IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 8 months

1
0
0 0

Trusted Firmware TSC 13th June Minutes

by Bill Fletcher

Hi, Here are the minutes from the TSC call last week. Please let me know any additions or corrections. Best regards Bill Attendees AbhishekP - Arm DavidB - Linaro MarkG - TI VickyJ - Linaro EricF - ST BillM - TI ChristianD -Cypress JoakimB - Linaro JuliusW - Google AshutoshS - Arm Agenda Pending action items PSA L2 update for TF-M. Ashutosh Singh (Arm) will be joining to present. Couple of misc items. Documentation hosting on ReadTheDocs. Gerrit hooks to inform specific maintainers of submitted patches. AOB Notes Pending action items AP: Any specific input on security reporting. Otherwise please raise with Dan on email. JB: Have a few points but will raise by mail. AP: By mid-July meeting should try to reach Beta level AP: Coding guidelines patch EF: Should hopefully be next week AP: Static analysis and functional safety - please could everyone think about this. Both TF teams are doing static analysis. JB: Functional safety came up in BKK19 - MISRA C AP: TSC Members - some members have not identified. May need to have invitation-only closed discussions CD: OP-TEE is going to add an extra row to the matrix of interest Representative discussion: Proposal generally agreed - 2 reps, expertise partitioned as member company desired. Ideally designated primary and secondary, either but not both can vote. PSA L2 update for TF-M AS: For v8m, isolation is through hardware. For dual cpu cortex-m each side has separate interrupts and no leakage of information through interrupts JB: Not much information in the document 18/19 pages. Interested in 5.6. What is the list of supported crypto expected. AS: Has not been listed. Should support the crypto currently used in TF-M DB: Secure storage TBD? AS: Crypto shouldn’t allow visibility of the key for secure storage. Have to close this. Action item later in slides. JB: Who is ‘The Lab’ in the slides? AS: 6-7 around the world. Partners have already gone for level 1 certification. Link here: https://www.psacertified.org/security-certification/test-labs/ EF: Foresee any work on mcuboot? AS: Have a fork in TF-M. Can’t comment on open source project. EF: Wondering if TF-M and upstream fork could converge AP: Could happen. Need to look at what it would take. DavidB discussing with TF-M team. JB: Any plans to do (external) security audits AP: Only in early stages. Who would be interested? JB, DB AP: Action: AP will contact JB., DB before next TSC about audits Documentation hosting on ReadTheDocs. AP: Agreed to do this. Joakim has demonstrated how to do this. Free option? JB: Works fine. AP: Any objection from TSC? Otherwise will raise the request to Linaro infrastructure to publish from Gerrit. JB: Ad free - as low as $5. Commercial support is $50-150/month. JW: Do we need an external service? Can we just run Sphinx? Since already asking for engineering effort. DB: Doubt to be able to do it for $5/month Action Bill to find out about cost of internal Sphinx hosting. JW: Coreboot is already doing this. (docs.coreboot.org <https://doc.coreboot.org/>) DB: Can also look into what Zephyr are doing. Gerrit hooks to inform specific maintainers of submitted patches. AP: Just have to update some guidelines AOB MG: is there a longer term roadmap for e.g. Level 3? -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 8 months

1
0
0 0

Re: [TF-TSC] Gerrit notifications and Sphinx

by Sandrine Bailleux

Hi Julius, > On 13/06/2019, 18:58, "TSC on behalf of Julius Werner via TSC" <tsc-bounces(a)lists.trustedfirmware.org on behalf of tsc(a)lists.trustedfirmware.org> wrote: > > As a follow-up to what we just discussed in the meeting, here's how to > set up email notifications on Gerrit: > > 1. Log in to review.trustedfirmware.org > 2. Click on the little Settings gear on the top right (next to your name) > 3. Scroll down to Notifications > 4. Type the repo name (e.g. TF-A/trusted-firmware-a) into the Repo > field (you have to wait for it to auto-complete and then select it, > can't just copy&paste the full name in) > 5. Type a search expression for things to monitor into the field on the right > 6. Click Add > 7. Repeat with as many expressions as you want to monitor > 8. Select checkboxes for the events you want to monitor (e.g. I > believe "Changes" just sends one email when it is first uploaded, > "Patches" sends one for every new patch set) > 9. Click Save Changes > > For the search expression I usually use something like > path:"^plat/common/.*" or > path:"^drivers/(arm/pl011|console|coreboot|delay_timer|gpio|ti).*" to > monitor the subdirectories I'm interested in, but any valid Gerrit > search expression works. You can try out the expression in the normal > search field to make sure it detects all the changes you intended. Thanks for the information, that's really useful :) I was aware of project-specific notifications in general but had never noticed there was a search filter to customize that further to specific files/directories! As a number of people have asked about that in the past, I've captured your instructions on the TF-A wiki here: https://developer.trustedfirmware.org/w/tf_a/gerrit_notifications/ Regards, Sandrine

6 years, 8 months

1
0
0 0

Re: [TF-TSC] TSC Agenda 13 Jun 2019

by David Brown

I've heard back from the Zephyr infrastructure folks. It looks like the Zephyr docs are hosted on an AWS instance. The docs are fetched each night, and the docs regenerated. So it is automatic, but with possibly a one day delay. David On Thu, Jun 13, 2019 at 9:12 AM Abhishek Pandit via TSC < tsc(a)lists.trustedfirmware.org> wrote: > The agenda for today looks like - > > > > - Pending action items > - PSA L2 update for TF-M. Ashutosh Singh (Arm) will be joining to > present. > - Couple of misc items. > - Documentation hosting on ReadTheDocs. > - Gerrit hooks to inform specific maintainers of submitted patches. > - AOB > > > > Thanks, > > Abhishek > > > > *From:* Abhishek Pandit > *Sent:* 11 June 2019 23:13 > *To:* tsc(a)lists.trustedfirmware.org > *Subject:* TSC Agenda 13 Jun 2019 > > > > Hi All, > > > > Any agenda items for the next TSC meeting? > > > > Thanks, > > Abhishek > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc >

6 years, 8 months

1
0
0 0

Re: [TF-TSC] Gerrit notifications and Sphinx

by Joakim Bech

Hi Julius, On Thu, 13 Jun 2019 at 19:58, Julius Werner via TSC < tsc(a)lists.trustedfirmware.org> wrote: > As a follow-up to what we just discussed in the meeting, here's how to > set up email notifications on Gerrit: > > 1. Log in to review.trustedfirmware.org > 2. Click on the little Settings gear on the top right (next to your name) > 3. Scroll down to Notifications > 4. Type the repo name (e.g. TF-A/trusted-firmware-a) into the Repo > field (you have to wait for it to auto-complete and then select it, > can't just copy&paste the full name in) > 5. Type a search expression for things to monitor into the field on the > right > 6. Click Add > 7. Repeat with as many expressions as you want to monitor > 8. Select checkboxes for the events you want to monitor (e.g. I > believe "Changes" just sends one email when it is first uploaded, > "Patches" sends one for every new patch set) > 9. Click Save Changes > > For the search expression I usually use something like > path:"^plat/common/.*" or > path:"^drivers/(arm/pl011|console|coreboot|delay_timer|gpio|ti).*" to > monitor the subdirectories I'm interested in, but any valid Gerrit > search expression works. You can try out the expression in the normal > search field to make sure it detects all the changes you intended. > > I also inquired about the coreboot documentation setup. They just use > a cron job to rebuild the documentation in regular intervals, which I > think would probably suffice for Trusted Firmware as well. (But if we > really need it the moment the patch is merged, we could probably find > a way to kick it off from Jenkins as well.) > Yes, that's an alternative way of dealing with it and I agree that having updates on daily basis is for sure good enough. The thing to strive for is to avoid the need for having a person doing the updates manually, so yes, the cron-job way of dealing with the docs absolutely works fine. // Regards Joakim > > coreboot runs the documentation server in a docker instance, the setup > files for that can be found at > > https://review.coreboot.org/cgit/coreboot.git/tree/util/docker/doc.coreboot… > . If we're also using docker in our infrastructure, we could probably > almost directly copy those. If not, it's still just one time setup of > a few pip packages and running make in a cron job. > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc >

6 years, 8 months

1
0
0 0

Gerrit notifications and Sphinx

by Julius Werner

As a follow-up to what we just discussed in the meeting, here's how to set up email notifications on Gerrit: 1. Log in to review.trustedfirmware.org 2. Click on the little Settings gear on the top right (next to your name) 3. Scroll down to Notifications 4. Type the repo name (e.g. TF-A/trusted-firmware-a) into the Repo field (you have to wait for it to auto-complete and then select it, can't just copy&paste the full name in) 5. Type a search expression for things to monitor into the field on the right 6. Click Add 7. Repeat with as many expressions as you want to monitor 8. Select checkboxes for the events you want to monitor (e.g. I believe "Changes" just sends one email when it is first uploaded, "Patches" sends one for every new patch set) 9. Click Save Changes For the search expression I usually use something like path:"^plat/common/.*" or path:"^drivers/(arm/pl011|console|coreboot|delay_timer|gpio|ti).*" to monitor the subdirectories I'm interested in, but any valid Gerrit search expression works. You can try out the expression in the normal search field to make sure it detects all the changes you intended. I also inquired about the coreboot documentation setup. They just use a cron job to rebuild the documentation in regular intervals, which I think would probably suffice for Trusted Firmware as well. (But if we really need it the moment the patch is merged, we could probably find a way to kick it off from Jenkins as well.) coreboot runs the documentation server in a docker instance, the setup files for that can be found at https://review.coreboot.org/cgit/coreboot.git/tree/util/docker/doc.coreboot… . If we're also using docker in our infrastructure, we could probably almost directly copy those. If not, it's still just one time setup of a few pip packages and running make in a cron job.

6 years, 8 months

1
0
0 0

TSC Agenda 13 Jun 2019

by Abhishek Pandit

Hi All, Any agenda items for the next TSC meeting? Thanks, Abhishek

6 years, 8 months

1
1
0 0

Trusted Firmware TSC 16th May Minutes

by Bill Fletcher

Agenda Binary Policy Security Incident handling Guidance for coding style application for platform specific code. OP-TEE update Notes Binary Policy Went through Gerrit review process. Some wording and structural changes. Has been applied to new TF binaries repository. Also an update to the TF-A contribution guidelines. Other projects can update their contribution guidelines if they need this process in future.. Should we have a statement saying that we welcome binary contributions? Not really ‘welcome’ - it’s a fall-back option. Expect most of the contributions to be open source and this is the exceptional process. Security Incident handling (sharing slides). Align with kernel process. List of sensitive stakeholders - is it fixed? What are the criteria? Have another slide that covers in a bit more detail. 90-day process is manual. Don’t have a policy to automate it. Only a small number of advisories to manage. Also depends when you start the countdown. Had a situation where we got a file and then a meeting 2 weeks later. Countdown starts from receipt of the report. Can also be changed in exceptional circumstances but this is the default case. Same for HW (SW fix) and SW vulnerabilities Yes. Also may need to comment when TF is not impacted by a vulnerability. Would not wait 90 days. Action: DH look for 90 day period automation (doesn’t gate the process) Doesn’t Zephyr use JIRA to track vulnerabilities? Believe they were using private JIRA. Propose to send mail to migrate people from the old to the new process. Can you give an example of companies that might be on the list? AWS, MS Azure, Google Embargo request deadline is 1 working day from being informed. For us it’s very difficult to roll out fixes and keep them embargoed. Are these negotiable and leave the exceptional cases for longer embargo. Could tighten the language. Want to pull in the default period. Go back to the kernel wording - 7 days except in exceptional circumstances. Afraid that if the default is 14 days and we will give it every time. How to distinguish At least decision is on our end. If only 1 day to respond, people may be conservative and ask for the maximum. Still at the discretion of the security team. Could make them work for the embargo - ask for a report every day. Potentially default 7 and then company needs to come back after that. Agreed better not to encourage a longer embargo. Will check internally and re-insert kernel-type wording in next version. Encryption has been optional for us. Some use it, some not. Still have concern about 90 days on the first slide. Why is it 90 days and how much can we say before it is up. Could release a shortened advisory immediately and a full description after 90 days. Hard to say what the boundaries are between the shortened and the full. An informed partner should be able to infer the implications for a fix. Shouldn’t need to spell it out publicly. Can we change wording so that trusted partners are allowed to say there is a security issue without saying what it is. Action DH to clarify what can be said before the 90 days. Guidance for coding style application for platform specific code. How to manage upstreaming ST platform and the proposed coding style. Coding styles are quite pragmatic. To avoid ambiguiity, should detail that it applies for platform-specific code and limit the platform code to a single folder. Can someone from ST make a patch? Someone from ST is in discussion with the TF-M team. Any objections? OP-TEE update Feel free to send email directly to <joakim.bech(a)linaro.org>. AOB TSC public mailing list members - this is a closed meeting. No specified list of TSC representatives. Would like to get a list of specified reps. Feel important for voting. Suggest primary & secondary but also scope because people will also be assigned TF-M or TF-A (and possibly OP-TEE). Add that request in the ask for the emails. Meetings cadence: second Thursday at 1600 UTC. Next meeting will be 16th June. -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 9 months

1
0
0 0

Re: [TF-TSC] Next TSC meeting & Agenda

by Eric FINCO

Hi Abhishek & all Sorry for late input. I would like to come back to the point I raised in BKK: guidance for coding style application for platform specific code. The TF-M coding style includes a "##Consistent style "statement that indicates "The code needs to be consistent with itself, so if existing code in the file violates listed coding style rules then it is better to follow existing style in the file and not break consistency by following the rules listed here" , we propose to precise it applies typically for platform specific code and to add a requirement to put platform specific code (e.g HAL code) in a single folder. To illustrate this in case of a ST STM32 platform: -STM32 Platform specific HAL code will be in a single folder located under /platform<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform>/ext<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext>/target<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…> -Code using the STM32 HAL : - Is matching the indentation style. - Function calls to STM32 HAL are CamelCase to fit with STM32 HAL functions Regards, Eric Finco [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5] Eric FINCO | Tel: +33 (0)2 4402 7154 MDG/MCD | Technical Specialist From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC Sent: jeudi 2 mai 2019 16:39 To: tsc(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-TSC] Next TSC meeting & Agenda Hi All, We didn't get to discuss the next meeting slot in our previous meeting but I would like to suggest Thursday 16th May 16:00 UK time. Hope that works. >From June onwards, we can setup a regular call e.g. on every 2nd Thursday of the month. Let's discuss and finalize in the next call. Any Agenda items that you would like to add for next meeting? Thanks, Abhishek

6 years, 9 months

1
0
0 0

Re: [TF-TSC] tf.org security incident handling process (v0.2)

by Dan Handley

Hi TF TSC This is a v0.2 update to the proposed tf.org security incident handling process, which I sent before the last TSC, incorporating comments I've had since then. Changes since then: * Clarified use of PGP. * Clarified how ESSs get included in the process * Other minor edits. I've included some comment/rationale in square brackets to aid discussion. All comments welcome. I've also jotted down the key points in the attached slides, which might be easier to digest. Hopefully we can discuss this more at Thursday TSC meeting. Regards Dan. ---- This security incident handling process proposal is broadly based on the kernel process [1], with influence from the existing TF-A [2] and OP-TEE [3] processes. [DH: Note the contrast with the kernel process: mailto:security@kernel.org is exclusively about fixing the vulnerability; disclosure is delegated to mailto:linux-distros@vs.openwall.org [4]. This proposal combines these activities.] Reporting ========= If you think you have found a security vulnerability, then please send an email to the Trusted Firmware security team at mailto:security@trustedfirmware.org. This is a private team of security officers who will help verify the security vulnerability, develop and release a fix, and disclose the vulnerability details responsibly. Please give us time to implement the disclosure plan described in the next section before going public. We do our best to respond and fix any issues as soon as possible. As with any bug, the more information you provide, the easier it is to diagnose and fix. If you already have a fix, please include it with your report, as that can speed up the process considerably. Any exploit code is very helpful. The security team may bring in extra help from area maintainers to understand and fix the vulnerability. The security team may share any information you provide with trusted third parties and eventually the public unless you request otherwise. [DH: Note, mailto:security@kernel.org provides stronger confidentiality guarantees because it is only interested in fixes, not disclosure. In practice, I'd expect members of the security team to be sensitive with confidential information as with any other open source interactions, and to get explicit approval from the reporter for disclosure of sensitive information, e.g. identity, organization, product information,...] You may using this PGP/GPG key [insert link] for encrypting the vulnerability information. This key is also available at http://keyserver.pgp.com and LDAP port 389 of the same server. The fingerprint for this key is: [Insert Fingerprint] If you would like replies to be encrypted, please provide your public key. Please note the Trusted Firmware security team cannot guarantee that encrypted information will remain encrypted when shared with trusted third parties. [DH: Is this acceptable? It allows reporters to use encryption without adding too much admin burden on the security team. The alternative is to force everyone receiving embargoed information to provide an encryption key and decrypt/re-encrypt as information is passed around. I think this adds too much overhead without significant security benefit.] If the security team consider the bug not to be a security vulnerability, you will be informed and the bug directed to the standard bug fixing process. Disclosure ========== The general security vulnerability disclosure plan is as follows: 1. For confirmed security vulnerabilities, develop a robust fix as soon as possible. During this time, information is only shared with the reporter, those needed to develop the fix and Especially Sensitive Stakeholders (ESSes). See the "ESS and Trusted Stakeholder registration" section below for more information about ESSes. 2. After a robust fix becomes available, our preference is to publicly release it as soon as possible. This will automatically happen if the vulnerability is already publicly known. However, release may be deferred if the reporter or an ESS requests it within 1 calendar day of the fix becoming available, and the security team agree the criticality of the vulnerability requires more time. The requested deferral period should be as short as possible and no more than 14 calendar days after the fix becomes available. The only valid reason for this release deferral is to accommodate deployment of the fix by ESSes. If it is immediately clear that ESSes are unaffected by the vulnerability then this stage is skipped. This 0-14 day deferral is the primary embargo period. [DH: Note, this stage is only relevant for TF-A currently.] [DH: I removed the nuance between 7 and 14 days used in the kernel process. I don't think it essentially changes the process.] [DH: Note, this assumes that ESS security teams operate 7 days a week.] 3. After the primary embargo period, the fix and relevant vulnerability information are shared with registered Trusted Stakeholders (see below section). Fix release may be deferred further if a Trusted Stakeholder requests it within 1 working day (Monday to Friday) of being notified, and the security team agree the criticality of the vulnerability requires more time. The requested deferral period should be as short as possible and no more than 14 calendar days after the Trusted Stakeholder receives it. The only valid reason for this further release deferral is to accommodate deployment of the fix by a Trusted Stakeholder. This further 1-14 day deferral is the secondary embargo period. Note, security fixes contain the minimum information required to fix the bug. The accompanying vulnerability details are disclosed later. [DH: Note, I've slightly relaxed the Trusted Stakeholder required response time to 1 working day, as oppose to 1 calendar day. Is this reasonable?] [DH: Note, this aggressive release of security fixes is aligned with the kernel process. The existing TF-A process allows for early release of fixes, which we generally do in practice, but that process doesn't really specify a fix embargo period. However it does specify a 4 week embargo on the subsequent security advisory. Also note that OP-TEE's fix embargo period is 90 days, which is aligned with Google's policy.] 4. After the fix is released, details of the security vulnerability are consolidated into a security advisory. This includes a CVE number and the security team will request one if not already done by the reporter. It also includes credit to the reporter unless they indicate otherwise. Drafts of the security advisory are circulated with the reporter, ESSes and Trusted Stakeholders as they become available. [DH: Note, the existing TF-A process only shares information with Trusted Stakeholders in the form of security advisories. This proposal is more aligned with the kernel process and means we can focus on fix development by sharing raw vulnerability information in the early stages.] 5. 90 days after the vulnerability was reported, the security advisory is made public at https://www.trustedfirmware.org/. This 90 day window is the public embargo period. [DH: This public embargo period aligns with Google and OP-TEE processes, although this proposal releases fixes earlier.] In exceptional cases, the above disclosure plan may be extended in consultation with the reporter, ESSes and Trusted Stakeholders, for example if it is very difficult to develop or deploy a fix, or wider industry consultation is needed. [DH: I'm accommodating for the Spectre/Meltdown case here] Handling embargoed information ============================== On receipt of embargoed information, you must not disclose any of the provided information beyond the group of people in your organization that need to know about it. During the primary and secondary embargo periods, that group of people should be limited to those entrusted to assess the impact of the vulnerability on your organization and deploy fixes to your products. After the secondary embargo period but during the public embargo period, that group of people may be expanded in order to prepare your organization's public response. The embargoed information must not be shared outside your organization during the public embargo period under any circumstances. If you think another individual/organization requires access to the embargoed information, then please ask them to register as a Trusted Stakeholder (see next section). If you believe there has been a leak of embargoed information then please notify the security team immediately. [DH: This section is stronger than the existing TF-A and OP-TEE processes, but not as strong as the linux distros policy [4]. I hope I've struck the right balance here.] The security team welcomes feedback on embargoed information at any time. ESS and Trusted Stakeholder registration ======================================== [DH: This is broadly based on the OP-TEE policy.] The security team maintains a vetted list of organizations and individuals who are considered ESSes and Trusted Stakeholders of Trusted Firmware security vulnerabilities. Contact <mailto:security@trustedfirmware.org> if you wish to be added to one of the lists, providing the following information: 1. Which list you want to be on. This will almost always be the Trusted Stakeholder list. 2. A justification of why you should be on the list. That is, why you should know about security vulnerabilities and have access to security fixes before they are made public. A valid reason to be on the Trusted Stakeholder list for example, is that you use Trusted Firmware in a deployed product. The ESS list is strictly limited to those organizations with large scale deployments of Trusted Firmware, providing bare-metal access on multi-tenancy systems. 3. An organization email address (not gmail, yahoo or similar addresses). It is preferable for each organization to provide an email alias that you can manage yourselves rather than providing a long list of individual addresses. 4. Confirmation that the individuals in your organization will handle embargoed information responsibly as described in the previous section. Note, the security team reserves the right to deny registration or revoke membership to the Trusted Stakeholders list, for example if it has concerns about the confidentiality of embargoed information. [DH: Note, becoming a Trusted Stakeholder in the current TF-A process requires having a valid NDA with Arm and requesting to be added via Arm account management. I propose that Arm send a mail to all existing stakeholders to invite them to register for the new process. Any objections?] [DH: Note, I expect each TF project to maintain its own ESS/Trusted Stakeholder lists.] [DH: Note, I've not included severity scoring in this proposal, as I think the only value of a score is helping to determine whether a bug is a security vulnerability or not, which in the end has a subjective element. I'm open to the idea of adding this to the process but I'd prefer it to be optional and aligned with CVSSv3 as used by CVE.] [1] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html [2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/secu… [3] https://optee.readthedocs.io/general/disclosure.html [4] https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 9 months

1
0
0 0

Re: [TF-TSC] Next TSC meeting & Agenda

by Christian Daudt

I'm good with either 16:00 or 17:00. Thanks, Christian. ________________________________ From: TSC <tsc-bounces(a)lists.trustedfirmware.org> on behalf of Abhishek Pandit via TSC <tsc(a)lists.trustedfirmware.org> Sent: Wednesday, May 8, 2019 3:08 AM To: Julius Werner; tsc(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-TSC] Next TSC meeting & Agenda I am okay with 17:00 but let's wait another day. If we don't hear any other preference for time then we can schedule at 17:00. Thanks, Abhishek -----Original Message----- From: Julius Werner <jwerner(a)google.com> Sent: 02 May 2019 21:00 To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Cc: tsc(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [TF-TSC] Next TSC meeting & Agenda > We didn’t get to discuss the next meeting slot in our previous meeting but I would like to suggest Thursday 16th May 16:00 UK time. Hope that works. Any chance we could keep this at 17:00 like the previous calls? Otherwise it becomes really early in California. -- TSC mailing list TSC(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tsc This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 9 months

1
0
0 0

Re: [TF-TSC] Next TSC meeting & Agenda

by Julius Werner

> We didn’t get to discuss the next meeting slot in our previous meeting but I would like to suggest Thursday 16th May 16:00 UK time. Hope that works. Any chance we could keep this at 17:00 like the previous calls? Otherwise it becomes really early in California.

6 years, 9 months

2
1
0 0

Re: [TF-TSC] Next TSC meeting & Agenda

by David Brown

On Thu, May 02, 2019 at 02:38:40PM +0000, Abhishek Pandit via TSC wrote: >We didn’t get to discuss the next meeting slot in our previous meeting but I >would like to suggest Thursday 16^th May 16:00 UK time. Hope that works. > >From June onwards, we can setup a regular call e.g. on every 2^nd Thursday of >the month. Let’s discuss and finalize in the next call. This time regularly works for me, although on the 16th I will be at the ICMC19 conference, and won't be able to attend. David

6 years, 10 months

1
0
0 0

Next TSC meeting & Agenda

by Abhishek Pandit

Hi All, We didn't get to discuss the next meeting slot in our previous meeting but I would like to suggest Thursday 16th May 16:00 UK time. Hope that works. >From June onwards, we can setup a regular call e.g. on every 2nd Thursday of the month. Let's discuss and finalize in the next call. Any Agenda items that you would like to add for next meeting? Thanks, Abhishek

6 years, 10 months

1
0
0 0

Re: [TF-TSC] Trusted Firmware-M Documentation Proposal

by Joakim Bech

Hi Paul, all, I think this is a good proposal. As a side note, we've just completed that exercise for the OP-TEE project [1] and in general it seems like most people appreciate the change. One thing where our process differs compared to what you've proposed is that we are still using GitHub for everything and that is connected directly to https://readthedocs.io using webhooks, which has the nifty feature that as soon as a patch (pull request) has been merged at GitHub, readthedocs will automatically be notified (webhooks) and will immediately rebuild the documentation and publish it. I.e., we always have the latest version available and published and there is no extra cost involved in manually having to deploy the "_build/*" stuff. I'm not sure if that is doable with existing TF infrastructure, but I think it's worth investigating whether someone like that is possible to do, since it saves us from doing "unnecessary" work. [1] https://optee.readthedocs.io/ and https://github.com/OP-TEE/optee_docs/ Regards, Joakim On Tue, 30 Apr 2019 at 11:18, Paul Beesley via TSC < tsc(a)lists.trustedfirmware.org> wrote: > Hi all, > > > > Please find attached a set of slides detailing proposed formats and > processes for TF-M documentation; these proposals cover both existing > documentation and documents produced for the purpose of design review. > Abhishek previously presented a version of these slides to the TSC and we > are now circulating them via the mailing list. > > > > Though it is not explicitly mentioned in the slides, we will look to > implement similar changes in Trusted Firmware-A as well, aligning the two > projects where possible. > > > > As always, comments and feedback on these proposed changes are welcome. > > > > Thanks, > > Paul > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc >

6 years, 10 months

1
0
0 0

Trusted Firmware-M Documentation Proposal

by Paul Beesley

Hi all, Please find attached a set of slides detailing proposed formats and processes for TF-M documentation; these proposals cover both existing documentation and documents produced for the purpose of design review. Abhishek previously presented a version of these slides to the TSC and we are now circulating them via the mailing list. Though it is not explicitly mentioned in the slides, we will look to implement similar changes in Trusted Firmware-A as well, aligning the two projects where possible. As always, comments and feedback on these proposed changes are welcome. Thanks, Paul

6 years, 10 months

1
0
0 0

Trusted Firmware TSC 5th April (BKK19) Minutes

by Bill Fletcher

Attendees Abhishek - Arm Kumar - Linaro MarkG - TI RemiD - Linaro DaveP - Linaro Eric - ST MatteoC - Arm ShebuK - Arm BillM - TI Christian -Cypress DonH - Linaro SobyM - Arm Joakim - Linaro DavidB - Linaro BillF - Linaro Community Projects Pending action items CI discussion - slides circulated Security incident handling - postponed as DanH cannot attend Notes Won’t use TSC-private mailing list any more (will be reactivated if needed) Attestation script home - Arm team will upstream initial patch. Dean to send test cases running on MPS2. Dean is going to do some deployment today (or ASAP). Follow up with Christian if nothing comes from Dean Proposal from documentation - Abhishek to send out initial proposal. Will be circulated after Connect. TF-A Roadmap JB: Will the roadmap be circulated publicly? MC: Would make sense to circulate a version publicly. For now this is the Arm roadmap. Would be a combination of contributions from project, other parties and infrastructure plans from Arm. Don’t know if advance which platforms are coming in from Partners JB: Not exactly clear what should publish. Maybe some kind of lightweight roadmap. SK: Have always published cut down version in TF-M dashboard. (MC shows slides from monthly report on tf.org) (MC shows “Trusted Firmware-A Evolution” #5 slide - this slide will be circulated afterwards). Data is public so follow-up discussions can happen on a public list. Arm & Google discussing to have Hafnium as secure EL2 firmware EF: Any assumption in terms of architecture? MC: v8 systems 32 & 64 bit. Not maintaining v7 TF. MC: Code is moving from GitHub to tf.org git/gerrit JB: Functional safety (2020?) MC: Good topic for TF. Happy to have a discussion on MISRA-C etc. Can’t certify with Arm toolchain linker. Partners need to do own platform port. (SV shows “TF-M v1.0-Beta @ Embedded World’19” - slide, backlog & Roadmap) SV: All work items public under Phabricator. Have 4 engineers working under tf.org. AP: Platform support? Worth to have something along with the roadmap to show which platforms are planned to be upstream. CD: List of platforms that will be supported? All for that. EF: We can create ticket when we work on an upstream platform. Would be easier than putting this in a public roadmap. Should discuss what are the coding rules and what we plan to put in /platform/x/target (?). Action Eric to make a proposal on upstream platforms & tickets AP: Stay away from complete freedom to put code conforming to any code convention in one of the directories. KG: Anyone looking at infrastructure for the project? MISRA, Coverity? (question open) LAVA topic (slides LAVA Remote Labs - previously shared) CD: raised question about having local master to help admin overhead. RD: Linaro believes that it’s better to have from local IT point of view to have single master. Currently lava has either admin or submitter. Linaro working on adding mid-level. It’s a shared master with multiple admins. CD: Already have lava setup internally (with local master?) DP: Remote worker model is not necessarily for everyone. CD: Less shared management is a good proposition if you don’t have already that in place. DP: Provided further input on this. KG: How the hardware is done has impact on adding something in the CI loop Original use case is companies wanting to put device in LAVA without shipping device to a central lab. Different model for sharing open CI with all projects vs making it easier within the companies. After some further discussion we decided to put a pin on this for discussing offline. -- EMEA Field Engineering Linaro Ltd Harston Mill CB22 7GG Cambridge UK +44 7833 498336 <+44%207833%20498336>

6 years, 10 months

1
0
0 0

Re: [TF-TSC] TSC Agenda 5th April 2019

by Bill Fletcher

LAVA Remote Labs slides Best regards Bill On Wed, 3 Apr 2019 at 08:42, Bill Fletcher via TSC < tsc(a)lists.trustedfirmware.org> wrote: > As part of the action on CI infrastructure I have the action to describing > a proposal for a distributed CI instance called Remote Labs. > > Regards > > Bill > > On Wed, 3 Apr 2019 at 08:05, Abhishek Pandit via TSC < > tsc(a)lists.trustedfirmware.org> wrote: > > > Hi All, > > > > Any agenda items for this week's TSC meeting? > > > > Currently this is what I have for the agenda: > > > > > > * Pending action items > > * Major roadmap items for the next quarter > > * Next meeting > > > > Thanks > > Abhishek > > > > -- > > TSC mailing list > > TSC(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tsc > > > > > -- > > > EMEA Field Engineering > Linaro Ltd > Harston Mill CB22 7GG > Cambridge UK > +44 7833 498336 <+44%207833%20498336> > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc > -- EMEA Field Engineering Linaro Ltd Harston Mill CB22 7GG Cambridge UK +44 7833 498336 <+44%207833%20498336>

6 years, 11 months

1
0
0 0

Re: [TF-TSC] tf.org security incident handling process

by David Brown

On Thu, Apr 04, 2019 at 02:44:35PM +0000, Dan Handley via TSC wrote: >If you think you have found a security vulnerability, then please send an email >to the Trusted Firmware security team at <[1]security(a)trusted-firmware.org>. >This is a private team of security officers who will help verify the security >vulnerability, develop and release a fix, and disclose the vulnerability >details responsibly. Please give us time to implement the disclosure plan >described in the next section before going public. We do our best to respond >and fix any issues quickly. I realize that the Linux docs don't mention encryption here, but there will probably be some reporters that will want to send encrypted email. It might be a good idea to have a few people on this list that have well-known PGP keys, and can respond to those people with what key to send a sensitive report to. David

6 years, 11 months

2
1
0 0

tf.org security incident handling process

by Dan Handley

Hi TF TSC This is write up of the proposed tf.org security incident handling process, which is one of my actions from the last TSC. I wanted to circulate this before Friday's TSC meeting. I know there's not much time for you to review before then but perhaps you can have some initial discussion (without me) and we can go into more detail at the next TSC? I've included some comment/rationale in square brackets to aid discussion. All comments welcome. Regards Dan. ---- This security incident handling process proposal is broadly based on the kernel process [1], with influence from the existing TF-A [2] and OP-TEE [3] processes. Reporting ========= If you think you have found a security vulnerability, then please send an email to the Trusted Firmware security team at <security(a)trusted-firmware.org<mailto:security@trusted-firmware.org>>. This is a private team of security officers who will help verify the security vulnerability, develop and release a fix, and disclose the vulnerability details responsibly. Please give us time to implement the disclosure plan described in the next section before going public. We do our best to respond and fix any issues quickly. [DH: Note security(a)kernel.org<mailto:security@kernel.org> is exclusively about fixing the vulnerability; disclosure is delegated to linux-distros(a)vs.openwall.org<mailto:linux-distros@vs.openwall.org> [4]. This proposal combines these activities.] As with any bug, the more information you provide, the easier it is to diagnose and fix. If you already have a fix, please include it with your report, as that can speed up the process considerably. Any exploit code is very helpful. The security team may bring in extra help from area maintainers to understand and fix the vulnerability. The security team may share any information you provide with trusted third parties and eventually the public unless you request otherwise. [DH: Note, security(a)kernel.org<mailto:security@kernel.org> provides stronger confidentiality guarantees because it is only interested in fixes, not disclosure. In practice, I'd expect members of the security team to be sensitive with confidential information as with any other open source interactions, and to get explicit approval from the reporter for disclosure of sensitive information, e.g. identity, organization, product information,...] If the security team consider the bug not to be a security vulnerability, you will be informed and the bug directed to the standard bug fixing process. [DH: Do we need to indicate target reporter response times? TF-A has an internal target of 1 day for an initial response and 1 week for a considered response. Other processes (including TF-A) do not specify a target here. Perhaps one can assume it will always be ASAP?] Disclosure ========== The general security vulnerability disclosure plan is as follows: 1. For confirmed security vulnerabilities, develop a robust fix as soon as possible. During this time, information is only shared with the reporter, those needed to develop the fix and Especially Sensitive Stakeholders (ESSes), in particular organizations with large scale deployments of Trusted Firmware providing bare-metal access on multi-tenancy systems. 2. After a robust fix becomes available, our preference is to publicly release it as soon as possible. This will automatically happen if the vulnerability is already publicly known. However, release may be deferred if the reporter or an ESS requests it within 1 calendar day of the fix becoming available, and the security team agree the criticality of the vulnerability requires more time. The requested deferral period should be as short as possible and no more than 14 calendar days after the fix becomes available. The only valid reason for this release deferral is to accommodate deployment of the fix by ESSs. If it is immediately clear that ESSes are unaffected by the vulnerability then this stage is skipped. This 0-14 day deferral is the primary embargo period. [DH: Note, this stage is only relevant for TF-A currently.] [DH: I removed the nuance between 7 and 14 days used in the kernel process. I don't think it essentially changes the process.] [DH: Note, this assumes that ESS security teams operate 7 days a week.] 3. After the primary embargo period, the fix and relevant vulnerability information are shared with registered Trusted Stakeholders (see below section). Fix release may be deferred further if a Trusted Stakeholder requests it within 1 working day (Monday to Friday) of being notified, and the security team agree the criticality of the vulnerability requires more time. The requested deferral period should be as short as possible and no more than 14 calendar days after the Trusted Stakeholder receives it. The only valid reason for this further release deferral is to accommodate deployment of the fix by a Trusted Stakeholder. This further 1-14 day deferral is the secondary embargo period. Note, security fixes contain the minimum information required to fix the bug. The accompanying vulnerability details are disclosed later. [DH: Note, I've slightly relaxed the Trusted Stakeholder required response time to 1 working day, as oppose to 1 calendar day. Is this reasonable?] [DH: Note, this aggressive release of security fixes is aligned with the kernel process. The existing TF-A process allows for early release of fixes, which we generally do in practice, but that process doesn't really specify a fix embargo period. However it does specify a 4 week embargo on the subsequent security advisory. Also note that OP-TEE's fix embargo period is 90 days, which is aligned with Google's policy.] 4. After the fix is released, details of the security vulnerability are consolidated into a security advisory. This includes a CVE number and the security team will request one if not already done by the reporter. It also includes credit to the reporter unless they indicate otherwise. Drafts of the security advisory are circulated with the reporter, ESSes and Trusted Stakeholders as they become available. [DH: Note, the existing TF-A process only shares information with Trusted Stakeholders in the form of security advisories. This proposal is more aligned with the kernel process and means we can focus on fix development by sharing raw vulnerability information in the early stages.] 5. 90 days after the vulnerability was reported, the security advisory is made public on https://www.trustedfirmware.org/. This 90 day window is the public embargo period. [DH: This public embargo period aligns with Google and OP-TEE processes, although this proposal releases fixes earlier.] In exceptional cases, the above disclosure plan may be extended in consultation with the reporter, ESSes and Trusted Stakeholders, for example if it is very difficult to develop or deploy a fix, or wider industry consultation is needed. [DH: I'm accommodating for the Spectre/Meltdown case here, but does this encourage Trusted Stakeholders to invoke "exceptional cases" casually?] Handling embargoed information ============================== On receipt of embargoed information, you must not disclose any of the provided information beyond the group of people in your organization that need to know about it. During the primary and secondary embargo periods, that group of people should be limited to those entrusted to assess the impact of the vulnerability on your organization and deploy fixes to your products. After the secondary embargo period but during the public embargo period, that group of people may be expanded in order to prepare your organization's public response. The embargoed information must not be shared outside your organization during the public embargo period under any circumstances. If you think another individual/organization requires access to the embargoed information, then please ask them to register as a Trusted Stakeholder (see next section). If you believe there has been a leak of embargoed information then please notify the security team immediately. [DH: This section is stronger than the existing TF-A and OP-TEE processes, but not as strong as the linux distros policy [4]. I hope I've struck the right balance here.] The security team welcomes feedback on embargoed information at any time. Trusted Stakeholder registration ================================ [DH: This is broadly based on the OP-TEE policy.] The security team maintains a vetted list of organizations and individuals who are considered Trusted Stakeholders of Trusted Firmware security vulnerabilities. Contact <security(a)trusted-firmware.org<mailto:security@trusted-firmware.org>> if you wish to be added to the list, providing the following information: 1. A justification of why you need to know about security vulnerabilities and have access to security fixes before they are made public. A valid reason for example, is that you use Trusted Firmware in a deployed product. 2. An organization email address (not gmail, yahoo or similar addresses). It is preferable for each organization to provide an email alias that you can manage yourselves rather than providing a long list of individual addresses. 3. Confirmation that your Trusted Stakeholders will handle embargoed information responsibly as described in the previous section. Note, the security team reserves the right to deny registration or revoke membership to the Trusted Stakeholders list, for example if it has concerns about the confidentiality of embargoed information. [DH: Note, becoming a Trusted Stakeholder in the current TF-A process requires having a valid NDA with Arm and requesting to be added via Arm account management. Should Arm automatically add existing stakeholders to the new process or invite them to be part of it?] [DH: Note, I expect each TF project to have its own Trusted Stakeholder list.] [DH: Note, I've not included severity scoring in this proposal, as I think the only value of a score is helping to determine whether a bug is a security vulnerability or not, which in the end has a subjective element. I'm open to the idea of adding this to the process but I'd prefer it to be optional and aligned with CVSSv3 as used by CVE.] [DH: Note, I haven't specified use of PGP/GPG in this proposal. It makes the process much more difficult to administer in practice for questionable additional security IMO. If we did allow reporters to use PGP, then it implies all recipients of embargoed information should provide a PGP key, and that embargoed information should be decrypted and re-encrypted with recipient keys as it is passed around. I think this is too much effort but if we don't have it, will it put off reporters? The current TF-A process allows optional use of PGP but relies on GitHub security for access to embargoed information. security(a)kernel.org<mailto:security@kernel.org> does not support PGP, though linux-distros(a)vs.openwall.org<mailto:linux-distros@vs.openwall.org> does. OP-TEE does not support it.] [DH: Note, this proposal assumes a single security email alias for all tf.org projects, which was agreed at a previous board/TSC meeting to make things simpler from a reporter's perspective. However, I'm having 2nd thoughts about that. The additional triage stage could unnecessarily delay handling and there will need to be project specific security aliases anyway, whether they're publicly visible or not.] [1] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html [2] https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmw… [3] https://optee.readthedocs.io/general/disclosure.html [4] https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 11 months

1
0
0 0

Re: [TF-TSC] TSC Agenda 5th April 2019

by Bill Fletcher

As part of the action on CI infrastructure I have the action to describing a proposal for a distributed CI instance called Remote Labs. Regards Bill On Wed, 3 Apr 2019 at 08:05, Abhishek Pandit via TSC < tsc(a)lists.trustedfirmware.org> wrote: > Hi All, > > Any agenda items for this week's TSC meeting? > > Currently this is what I have for the agenda: > > > * Pending action items > * Major roadmap items for the next quarter > * Next meeting > > Thanks > Abhishek > > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc > -- EMEA Field Engineering Linaro Ltd Harston Mill CB22 7GG Cambridge UK +44 7833 498336 <+44%207833%20498336>

6 years, 11 months

1
0
0 0

TSC Agenda 5th April 2019

by Abhishek Pandit

Hi All, Any agenda items for this week's TSC meeting? Currently this is what I have for the agenda: * Pending action items * Major roadmap items for the next quarter * Next meeting Thanks Abhishek

6 years, 11 months

1
0
0 0

Trusted Firmware TSC meeting minutes - 14th March

by Bill Fletcher

Attendees David Brown - Linaro Bill Fletcher - Linaro Joakim Bech - Linaro Bill Mills - TI Matteo Carlini - Arm Eric Finco - ST Mark Groesen - TI Shebu Kirakose - Arm Abhishek Pandit - Arm Julius Werner - Google Christian Daudt - Cypress Andrew Davis - TI Dean Arnold - Arm Actions noted Binary repository implementation proposal (name, path, mechanism) - Dan Propose slot for TSC call co-timed with Connect - Abhishek Proposal on incident handling list - Dan Reconcile mailing lists with attendees - Bill Attestation script home - Abhishek to talk with David Dean to send test cases running on MPS2 to Christian Agenda 1. CI system discussion. 2. Security Incident Process. 3. Binary Contribution Policy. Draft has already been circulated. 4. Attestation Token Validation script Arm team has created a validation script for checking the initial attestation token (CBOR/COSE). We would like to open source this script as it helps TF-M users. Would it make sense to have this in tf.org? 5. TF-M Documentation Proposal We have been working on a better documentation proposal for TF-M. I can briefly introduce this to TSC then it can be followed by mailing list discussion. 6. Next meeting – BKK19 F2F? 7. Mailing list subscription status. 8. If time permits we can discus major work items for the next quarter. 9. AOB Minutes Binary Contribution Policy JW: Circulated via Board. Already have some instances. Will have separate repository for TF Binaries. Policy describes rules that need to be followed to upload to the repository. We review case-by-case. Policy describes the process where they discuss with the TSC. How to technically implement this - propose it should be a git submodule. Board has already approved the policy. AP: Expect to send some questions by email. Any other questions? JW: Can we start implementing - creating the repository? DH: All we need is a location and a name for the repo. Do we have a generic (non TF-A, TF-M) namespace? Unified repo. JW: Need someone from Arm to create the submodule repo. Action: Dan to suggest path/name Incident Handling DH: TF-A has an incident handling process. So does OP-TEE (different). TF-M doesn’t have one. Need to have (need from hyperscalers) a very restricted list for who can contribute to the fix before publicizing it. Similar to kernel. MC: In the kernel - restricted to non-disclosed list of security experts. Second list of people for controlled disclosure that are under a linux distro mailing alias. CD: Not quite clear on the distinction. Board discussion was a single entry point. Think the grand goal was to make it simpler reporting. Don’t create artificial separation. Should be obvious to submitter. If could have 2-3 triagers forwarding to TF-A and TF-M. Who are those 2-3 people? DH: Arm looking for them to be Arm people. MC: Distinction is based on individual merit rather than specific companies. Core developers for A & M are currently Arm. Disclosure comes afterwards. CD: 3rd level - an inform list? DH: Yes. Currently would be people with an NDA with Arm. CD: If there’s an embargo don’t want it going to even a semi-open list. Action: Dan to come up with a proposal MC: cf Linux kernel policy. Aim is to push the fix as soon as possible but acknowledge the needs of hyperscalers JB: For OPTEE initial proposal was seen as too tight. Google has 90 days. Difference is if the problem is out in the wild and then fix as quickly as possible. DH: Feedback from hyperscaler vendors that they only need 2 weeks. Even Linux distros only ask for another 2 weeks on top. For TF-A, 4 weeks after initial disclosure it goes public. In kernel process don’t get involved in CVE and severity scoring. Leave that to reports. Anyone have any initial thoughts JB: Not saying TF should use same policy as OPTEE but if there are no other ideas. DH: Reason OPTEE doesn’t use CVSS? JB: Not really. Needed to tweak it with OPTEE wording. JW: Propose to follow Linux policy of releasing the patch as soon as possible. Some project, patching is public Mailing list subscription service AP: Please can everyone check their subscription status. BF: If any issues with lists.trustedfirmware.org then mail BillF Action: Bill to reconcile the mailing lists vs attendees CD: Should maybe consider TSC to be TSC “announce”. BF: TSC was aimed to be as open/transparent as possible Attestation token: AP: Team in Arm has been working on a script. Team have asked if it can be upstreamed somewhere. TF-M generates this token. Does it make sense to create a repo to host this script. Would be someone assigned as maintainer from Arm side. CD: Already a tools directory in TF-M with some Python scripts. Why not there? AP: Might apply to other projects SK: It’s an ITF standard. Just happens that TF-M uses that format DB: Suggest to put it in the repo CD: What open source project do you want it to live under, or does it need it’s own project? Don’t see why it would be in TF. Can import it into TF for use. DB: Cbor implementations tend to be for specific uses. Not sure it’s the trend we want to follow. CD: But if not, someone needs to make sure it’s generic enough. Level of ownership needed. Otherwise throw it in TF-M. DB: Question - who is going to work on generalising it. Will only be when someone has the resources AP: Propose to take input from David [action] CI DA: Have a set up of Jenkins/Build Slaves and LAVA. Will meet with Linaro next week to see how to move that onto their infrastructure. CD: Test cycle is via a LAVA instance testing DA: Yes via MPS2 CD: Is just boot? DA: Have a couple of test cases. Can find out. [action] CD: Is the plan to move this to the LAVA lab? BF: There are a few options, as well as physical location in the lab we have a federated/distributed lab instance concept. Builds and results are central but board farm has instances at vendor sites. Helps avoid lab bottlenecks and shipping boards. CD: Like kernel CI? BF: Yes. Will look at putting together a deck with some more information MG: Does the CI use simulation? i.e. qemu or fast model? DA: TF-A use fast models. Qemu - not done anything at the moment. BF: Does TF-A Test support qemu? DH: Can check MG: Recently has been some more support pushed. CD: LAVA supports qemu. EF: Distributed instance supports TF-A and TF-M? BF: For LAVA infrastructure - yes AP: Next meeting. Board is meeting at Linaro Connect. Any interest in a TSC meeting? (confirmed several TSC members will be there) EF: Yes. Welcome opportunity to discuss work items for the next quarter AP: Documentation - brief overview. Slides to be circulated by email. JB: Done same activity for OPTEE and done same activity. Nice think with Sphinx - interlinking within the documentation is very easy. Like this idea. CD: If RFC discussed in gerrit code review then that could get lost. AP: Should still say in draft folder in the doc. CD: Basically the history of thingks that were discussed by not accepted. AP: review happens on the mailing list CD: So there is history in git if something is turned down AP: And mailing list has the discussion. DB: Reference: https://github.com/rust-lang/rfcs -- EMEA Field Engineering Linaro Ltd Harston Mill CB22 7GG Cambridge UK +44 7833 498336 <+44%207833%20498336>

6 years, 11 months

1
0
0 0

Re: [TF-TSC] Trusted Firmware TSC - meeting proposal - Friday 5th April 01:00 UTC

by Joakim Bech

Den mån 18 mars 2019 17:38Abhishek Pandit via TSC < tsc(a)lists.trustedfirmware.org> skrev: > 8 am Friday should be okay for me. > Thanks, Abhishek > +1 // Joakim > -----Original Message----- > From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill > Fletcher via TSC > Sent: 15 March 2019 16:14 > To: tsc(a)lists.trustedfirmware.org > Subject: [TF-TSC] Trusted Firmware TSC - meeting proposal - Friday 5th > April 01:00 UTC > > Hi all, > > There was a discussion about scheduling a F2F TSC session (with remote > access) during the week of Linaro Connect BKK19 1st-5th April. The agenda > topic is work items for the next quarter. > > We could do 08:00 Bangkok time on Fri 5th April. This equates to 18:00 > Pacific time on 4th April. Dial in from Europe is unfortunately difficult > (UTC 01:00). > > Please let me know if you'd like me to set it up. > > Full details: > > - Bangkok (Thailand) Friday, 5 April 2019, 08:00:00 ICT UTC+7 hours > - San Francisco (USA - California) Thursday, 4 April 2019, 18:00:00 PDT > UTC-7 > hours > - London (United Kingdom - England) Friday, 5 April 2019, 02:00:00 BST > UTC+1 > hour > - Corresponding UTC (GMT) Friday, 5 April 2019, 01:00:00 > > Regards > > Bill > > -- > > > EMEA Field Engineering > Linaro Ltd > Harston Mill CB22 7GG > Cambridge UK > +44 7833 498336 <+44%207833%20498336> > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc >

6 years, 11 months

1
0
0 0

Re: [TF-TSC] Trusted Firmware TSC - meeting proposal - Friday 5th April 01:00 UTC

by Abhishek Pandit

8 am Friday should be okay for me. Thanks, Abhishek -----Original Message----- From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TSC Sent: 15 March 2019 16:14 To: tsc(a)lists.trustedfirmware.org Subject: [TF-TSC] Trusted Firmware TSC - meeting proposal - Friday 5th April 01:00 UTC Hi all, There was a discussion about scheduling a F2F TSC session (with remote access) during the week of Linaro Connect BKK19 1st-5th April. The agenda topic is work items for the next quarter. We could do 08:00 Bangkok time on Fri 5th April. This equates to 18:00 Pacific time on 4th April. Dial in from Europe is unfortunately difficult (UTC 01:00). Please let me know if you'd like me to set it up. Full details: - Bangkok (Thailand) Friday, 5 April 2019, 08:00:00 ICT UTC+7 hours - San Francisco (USA - California) Thursday, 4 April 2019, 18:00:00 PDT UTC-7 hours - London (United Kingdom - England) Friday, 5 April 2019, 02:00:00 BST UTC+1 hour - Corresponding UTC (GMT) Friday, 5 April 2019, 01:00:00 Regards Bill -- EMEA Field Engineering Linaro Ltd Harston Mill CB22 7GG Cambridge UK +44 7833 498336 <+44%207833%20498336> -- TSC mailing list TSC(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tsc

6 years, 11 months

1
0
0 0

Re: [TF-TSC] Trusted Firmware TSC - meeting proposal - Friday 5th April 01:00 UTC

by Christian Daudt

That timeslot works for me. Thanks Christian. ________________________________ From: TSC <tsc-bounces(a)lists.trustedfirmware.org> on behalf of Julius Werner via TSC <tsc(a)lists.trustedfirmware.org> Sent: Friday, March 15, 2019 10:55 AM To: Bill Fletcher Cc: tsc(a)lists.trustedfirmware.org Subject: Re: [TF-TSC] Trusted Firmware TSC - meeting proposal - Friday 5th April 01:00 UTC CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. That would work for me in PDT. On Fri, Mar 15, 2019 at 9:13 AM Bill Fletcher via TSC <tsc(a)lists.trustedfirmware.org> wrote: > > Hi all, > > There was a discussion about scheduling a F2F TSC session (with remote > access) during the week of Linaro Connect BKK19 1st-5th April. The agenda > topic is work items for the next quarter. > > We could do 08:00 Bangkok time on Fri 5th April. This equates to 18:00 > Pacific time on 4th April. Dial in from Europe is unfortunately difficult > (UTC 01:00). > > Please let me know if you'd like me to set it up. > > Full details: > > - Bangkok (Thailand) Friday, 5 April 2019, 08:00:00 ICT UTC+7 hours > - San Francisco (USA - California) Thursday, 4 April 2019, 18:00:00 > PDT UTC-7 > hours > - London (United Kingdom - England) Friday, 5 April 2019, 02:00:00 BST UTC+1 > hour > - Corresponding UTC (GMT) Friday, 5 April 2019, 01:00:00 > > Regards > > Bill > > -- > > > EMEA Field Engineering > Linaro Ltd > Harston Mill CB22 7GG > Cambridge UK > +44 7833 498336 <+44%207833%20498336> > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 11 months

1
0
0 0

Re: [TF-TSC] Trusted Firmware TSC - meeting proposal - Friday 5th April 01:00 UTC

by Julius Werner

That would work for me in PDT. On Fri, Mar 15, 2019 at 9:13 AM Bill Fletcher via TSC <tsc(a)lists.trustedfirmware.org> wrote: > > Hi all, > > There was a discussion about scheduling a F2F TSC session (with remote > access) during the week of Linaro Connect BKK19 1st-5th April. The agenda > topic is work items for the next quarter. > > We could do 08:00 Bangkok time on Fri 5th April. This equates to 18:00 > Pacific time on 4th April. Dial in from Europe is unfortunately difficult > (UTC 01:00). > > Please let me know if you'd like me to set it up. > > Full details: > > - Bangkok (Thailand) Friday, 5 April 2019, 08:00:00 ICT UTC+7 hours > - San Francisco (USA - California) Thursday, 4 April 2019, 18:00:00 > PDT UTC-7 > hours > - London (United Kingdom - England) Friday, 5 April 2019, 02:00:00 BST UTC+1 > hour > - Corresponding UTC (GMT) Friday, 5 April 2019, 01:00:00 > > Regards > > Bill > > -- > > > EMEA Field Engineering > Linaro Ltd > Harston Mill CB22 7GG > Cambridge UK > +44 7833 498336 <+44%207833%20498336> > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc

6 years, 11 months

1
0
0 0

Trusted Firmware TSC - meeting proposal - Friday 5th April 01:00 UTC

by Bill Fletcher

Hi all, There was a discussion about scheduling a F2F TSC session (with remote access) during the week of Linaro Connect BKK19 1st-5th April. The agenda topic is work items for the next quarter. We could do 08:00 Bangkok time on Fri 5th April. This equates to 18:00 Pacific time on 4th April. Dial in from Europe is unfortunately difficult (UTC 01:00). Please let me know if you'd like me to set it up. Full details: - Bangkok (Thailand) Friday, 5 April 2019, 08:00:00 ICT UTC+7 hours - San Francisco (USA - California) Thursday, 4 April 2019, 18:00:00 PDT UTC-7 hours - London (United Kingdom - England) Friday, 5 April 2019, 02:00:00 BST UTC+1 hour - Corresponding UTC (GMT) Friday, 5 April 2019, 01:00:00 Regards Bill -- EMEA Field Engineering Linaro Ltd Harston Mill CB22 7GG Cambridge UK +44 7833 498336 <+44%207833%20498336>

6 years, 11 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

TSC