<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Ting,<br></div><div><br></div><div>Here's my thoughts on the topic / proposal.</div><div><br></div><div>To jump straight to my main concern, I am sceptical of storing a 'trust state' in yet another API, especially for trusted compute, as we then need to trust an API and it's less secure (than a TPM) components (database, memory, disc etc).<br></div><div><br></div><div>Up to present the trusted compute approach in OpenStack has been always been some type of API query to establish if a node can be 'trusted' and hooking that into nova's scheduler. One current approach being the traits API. <br></div><div><br></div><div>The problem with this is that the stored state of 'trusted' is then on disc or volatile memory , typically a row in a mariaDB table somewhere on the controller - this then means we immediately lose all of the true attractiveness of a TPM, that being a tamper proof hardware route of trust ,  unlike an API which sets the 'trust state' in a datastore on disc or memory (which can be hacked to spoof trust).</div><div><br></div><div>So I can't really comment on the current proposal or really get behind it, as its to vague at present in why it should provide unified trust and how we would trust it. On the face of it, this proposal appears to be another actor susceptible to the flaws outlined above. I would need to know how the above concern would be resolved, so that there is implicit hardware routed trust presented to the workload wanting a trusted node to schedule upon, without a go between actor hosting the trust state of compute nodes. <br></div><div><br></div><div>Perhaps you have already solved this, if so I would recommend you outline it in your proposal. <br></div><div><br></div><div>Best Regards,</div><div><br></div><div>Luke</div><div><br></div><div><div class="gmail_quote"><div dir="ltr">On Wed, Oct 17, 2018 at 3:48 PM TING PANG <<a href="mailto:chengfeiyoiua@gmail.com">chengfeiyoiua@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><p class="MsoNormal" style="margin:0cm 0cm 8pt;line-height:15.6933px;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">Dear all,</span></p><p class="MsoNormal" style="margin:0cm 0cm 8pt;text-align:justify;line-height:15.6933px;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">As we all known, security has always been a hot topic among people. In OpenStack, if an attacker make a system un-</span><span style="font-size:14.6667px">trustworthy, it will make a risk for entire infrastructure and affect customers confidence. Fortunately, more and more vendors start providing security solutions with the t</span><span style="font-size:14.6667px">rusted computing. It is a security technology based on a hardware trust format to improve system integrity and trustworthy.</span><span style="font-size:14.6667px"> T</span><span style="font-size:14.6667px">he risks and threats on cloud can be mitigated and managed with trusted computing technology, which can make a customer more confident when utilizing OpenStack.</span></p><p class="MsoNormal" style="margin:0cm 0cm 8pt;text-align:justify;line-height:15.6933px;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">However, there are some mainstream trusted formats (e.g. TPM, TCM) and some special trusted formats provided by vendors (e.g. Google, Microsoft ) in the world, which cause huge development costs and interoperability issues for vendors to support various trusted formats.</span></p><p class="MsoNormal" style="margin:0cm 0cm 8pt;text-align:justify;line-height:15.6933px;font-size:11pt;font-family:Calibri,sans-serif">To resolve problems above, we want to create a new security project named "Hawthorn" that provides a general unified trust management framework to be compatible with different trust formats in OpenStack.</p><p class="MsoNormal" style="margin:0cm 0cm 8pt;line-height:15.6933px"><span style="font-family:Calibri,sans-serif;font-size:11pt" lang="EN-US">More general information can be found here:  </span><font face="Calibri, sans-serif" color="#1155cc"><span style="font-size:14.6667px"><u><a href="https://wiki.openstack.org/wiki/Hawthorn" target="_blank">https://wiki.openstack.org/wiki/Hawthorn</a></u></span></font></p><p class="MsoNormal" style="margin:0cm 0cm 8pt;text-align:justify;line-height:15.6933px;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">Please feel free to contact me if you are interested in this proposal or have questions and suggestion.</span></p><p class="MsoNormal" style="margin:0cm 0cm 8pt;line-height:15.6933px;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">Best regards,</span></p><p class="MsoNormal" style="margin:0cm 0cm 8pt;line-height:15.6933px;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">Ting</span></p><div class="gmail-m_-6302676280618882880gmail-yj6qo"></div><br class="gmail-m_-6302676280618882880gmail-Apple-interchange-newline"></div></div>
_______________________________________________<br>
openstack-sigs mailing list<br>
<a href="mailto:openstack-sigs@lists.openstack.org" target="_blank">openstack-sigs@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="font-size:12.8px">Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat</span><br style="font-size:12.8px"><span style="font-size:12.8px">e: </span><a href="mailto:lhinds@redhat.com" style="color:rgb(17,85,204);font-size:12.8px" target="_blank">lhinds@redhat.com</a><span style="font-size:12.8px"> | irc: lhinds @freenode |</span><span style="font-size:12.8px"> t: </span>+44 12 52 36 2483<br style="font-size:12.8px"></div></div></div></div></div></div></div></div></div></div></div>