)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"4ab8c595158e828b0e5a4195e1f065701585c0ba","unresolved":false,"context_lines":[{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Two options:"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"(a) Write the mitigation document for rest of the previous"},{"line_number":29,"context_line":"    vulnerabilities too, for completeness\u0027 sake.  (In April 2018 I wrote"},{"line_number":30,"context_line":"    this doc[1] for Meltdown — polish it and submit it?  Parts of"},{"line_number":31,"context_line":"    that document\u0027s content is already incorporated into the help text"},{"line_number":32,"context_line":"    for the config attribute `cpu_model_extra_flags`.)"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"(b) For now, we can live with the cliché \"something is better than"},{"line_number":35,"context_line":"    nothing\"; we\u0027ll add the other docs \"when we get to it\".  And"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"bfb3d3c7_3e3dbadc","line":32,"range":{"start_line":28,"start_character":0,"end_line":32,"end_character":54},"updated":"2019-05-28 09:38:49.000000000","message":"If you already have something then yes lets open a separate change for Meltdown.","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Two options:"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"(a) Write the mitigation document for rest of the previous"},{"line_number":29,"context_line":"    vulnerabilities too, for completeness\u0027 sake.  (In April 2018 I wrote"},{"line_number":30,"context_line":"    this doc[1] for Meltdown — polish it and submit it?  Parts of"},{"line_number":31,"context_line":"    that document\u0027s content is already incorporated into the help text"},{"line_number":32,"context_line":"    for the config attribute `cpu_model_extra_flags`.)"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"(b) For now, we can live with the cliché \"something is better than"},{"line_number":35,"context_line":"    nothing\"; we\u0027ll add the other docs \"when we get to it\".  And"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"9fb8cfa7_d3066a21","line":32,"range":{"start_line":28,"start_character":0,"end_line":32,"end_character":54},"in_reply_to":"bfb3d3c7_3e3dbadc","updated":"2019-06-03 13:48:46.000000000","message":"+1 because","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":31,"context_line":"    that document\u0027s content is already incorporated into the help text"},{"line_number":32,"context_line":"    for the config attribute `cpu_model_extra_flags`.)"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"(b) For now, we can live with the cliché \"something is better than"},{"line_number":35,"context_line":"    nothing\"; we\u0027ll add the other docs \"when we get to it\".  And"},{"line_number":36,"context_line":"    meanwhile, operators get mitigation details from various other"},{"line_number":37,"context_line":"    places, too: processor vendors, Linux distributions, etc."},{"line_number":38,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"9fb8cfa7_8efe8903","line":35,"range":{"start_line":34,"start_character":41,"end_line":35,"end_character":13},"updated":"2019-06-03 13:48:46.000000000","message":"this","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"}],"doc/source/admin/mitigation-for-Intel-MDS-security-flaws.rst":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":21,"context_line":"as follows."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"(1) Update the following components to the versions from your Linux"},{"line_number":24,"context_line":"    distribution that has fixes for the MDS flaws, on all Compute nodes"},{"line_number":25,"context_line":"    with Intel x86_64 CPUs:"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"    - microcode_ctl"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_f344ceb9","line":24,"range":{"start_line":24,"start_character":22,"end_line":24,"end_character":25},"updated":"2019-06-03 13:48:46.000000000","message":"have","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"471d17e7dbe1572c0a6a6044f9028beb404586c8","unresolved":false,"context_lines":[{"line_number":21,"context_line":"as follows."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"(1) Update the following components to the versions from your Linux"},{"line_number":24,"context_line":"    distribution that has fixes for the MDS flaws, on all Compute nodes"},{"line_number":25,"context_line":"    with Intel x86_64 CPUs:"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"    - microcode_ctl"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_82a41d0a","line":24,"range":{"start_line":24,"start_character":22,"end_line":24,"end_character":25},"in_reply_to":"9fb8cfa7_f344ceb9","updated":"2019-06-03 16:27:40.000000000","message":"Ha, the \"have\" is correct, because it is referring to \"versions\", which is plural.","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":29,"context_line":"    - qemu-system-x86"},{"line_number":30,"context_line":"    - libvirt"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"(2) Live migrate all the Nova instances to another Compute node."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"(3) Ensure that the CPU flag `md-clear` is exposed to the Nova instance."},{"line_number":35,"context_line":"    It can be done so in one of the three following ways, given that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_f3e04e99","line":32,"range":{"start_line":32,"start_character":0,"end_line":32,"end_character":64},"updated":"2019-06-03 13:48:46.000000000","message":"Why is this necessary? Am I migrating them to a compute node that\u0027s not vulnerable? Don\u0027t I have to patch that compute node too?\n\n(also nit: lowercase \u0027compute\u0027)\n\n[Later] Okay, I see Alex was confused by this too. So perhaps a bit of clarity could be added to this step.","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"aa1fc382309750ec487f13d99d5247cd1ffa3750","unresolved":false,"context_lines":[{"line_number":29,"context_line":"    - qemu-system-x86"},{"line_number":30,"context_line":"    - libvirt"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"(2) Live migrate all the Nova instances to another Compute node."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"(3) Ensure that the CPU flag `md-clear` is exposed to the Nova instance."},{"line_number":35,"context_line":"    It can be done so in one of the three following ways, given that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_fbfca03f","line":32,"range":{"start_line":32,"start_character":0,"end_line":32,"end_character":64},"in_reply_to":"9fb8cfa7_6294898c","updated":"2019-06-03 17:23:13.000000000","message":"\u003e The \"live-migrate\" step is for patching the *compute* node—with the\n \u003e goal to  maximize the uptime of the instances running critical\n \u003e workloads.\n\nAh, because you reboot the compute node in step 4. So technically you could do this any time before step 4 - or not at all, if you don\u0027t care about the downtime.\n\nIn that case I would just fold it into step 4 (which would then become step 3).\n\n \u003e (On casing nit: The reason I consistently use uppercase \u0027Compute\u0027\n \u003e is that we were using it as a noun, instead as a verb.  But ...\n \u003e keeping my OCD aside, I realize, as a _convention_ we simply use\n \u003e lowercase across the board, just like we do for \"nova\".)\n\nI would argue that it would be more appropriate to capitalize Nova, as a \"proper noun\", whereas we use \"compute\" or \"compute node\" as a regular (non proper) noun almost always. This ain\u0027t German.\n\nBut Dude, I really don\u0027t care. We\u0027ve spent too much Time on this already.","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"471d17e7dbe1572c0a6a6044f9028beb404586c8","unresolved":false,"context_lines":[{"line_number":29,"context_line":"    - qemu-system-x86"},{"line_number":30,"context_line":"    - libvirt"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"(2) Live migrate all the Nova instances to another Compute node."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"(3) Ensure that the CPU flag `md-clear` is exposed to the Nova instance."},{"line_number":35,"context_line":"    It can be done so in one of the three following ways, given that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_6294898c","line":32,"range":{"start_line":32,"start_character":0,"end_line":32,"end_character":64},"in_reply_to":"9fb8cfa7_f3e04e99","updated":"2019-06-03 16:27:40.000000000","message":"The \"live-migrate\" step is for patching the *compute* node—with the goal to  maximize the uptime of the instances running critical workloads. But still, at _some_ point (as I noted at the end of point (4), below) you _must_ cold-reboot the instance itself, to pick up CPU flags, machine type and related bits—you can\u0027t get away without it.\n\n(On casing nit: The reason I consistently use uppercase \u0027Compute\u0027 is that we were using it as a noun, instead as a verb.  But ... keeping my OCD aside, I realize, as a _convention_ we simply use lowercase across the board, just like we do for \"nova\".)","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"df85b5562f47254487111173eacdd2c7ee6882af","unresolved":false,"context_lines":[{"line_number":29,"context_line":"    - qemu-system-x86"},{"line_number":30,"context_line":"    - libvirt"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"(2) Live migrate all the Nova instances to another Compute node."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"(3) Ensure that the CPU flag `md-clear` is exposed to the Nova instance."},{"line_number":35,"context_line":"    It can be done so in one of the three following ways, given that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_31a9e77a","line":32,"range":{"start_line":32,"start_character":0,"end_line":32,"end_character":64},"in_reply_to":"9fb8cfa7_fbfca03f","updated":"2019-06-05 13:36:04.000000000","message":"\u003e \u003e The \"live-migrate\" step is for patching the *compute* node—with\n \u003e the\n \u003e \u003e goal to  maximize the uptime of the instances running critical\n \u003e \u003e workloads.\n \u003e \n \u003e Ah, because you reboot the compute node in step 4. So technically\n \u003e you could do this any time before step 4 - or not at all, if you\n \u003e don\u0027t care about the downtime.\n \u003e \n \u003e In that case I would just fold it into step 4 (which would then\n \u003e become step 3).\n\nWill adjust.\n\n \u003e \u003e (On casing nit: The reason I consistently use uppercase \u0027Compute\u0027\n \u003e \u003e is that we were using it as a noun, instead as a verb.  But ...\n \u003e \u003e keeping my OCD aside, I realize, as a _convention_ we simply use\n \u003e \u003e lowercase across the board, just like we do for \"nova\".)\n \u003e \n \u003e I would argue that it would be more appropriate to capitalize Nova,\n \u003e as a \"proper noun\", whereas we use \"compute\" or \"compute node\" as a\n \u003e regular (non proper) noun almost always. This ain\u0027t German.\n\n[Not to be belabor it further...]\n\nOh, yes, I\u0027m fully with you on capitalizing the proper noun, Nova.  I find the \"justification\"[*] to be lazy: \"Lowercase for project names as a rule is then easiest to review and enforce at this scale and growth pattern.\" \n\n \u003e But Dude, I really don\u0027t care. We\u0027ve spent too much Time on this\n \u003e already.\n\nYes, yes.  Sorry for pedantry.\n\n[*] https://governance.openstack.org/tc/reference/service-project-naming.html","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"a3721ae8ee60a294c55e2871f4bab12bb86ae7b2","unresolved":false,"context_lines":[{"line_number":31,"context_line":""},{"line_number":32,"context_line":"(2) Live migrate all the Nova instances to another Compute node."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"(3) Ensure that the CPU flag `md-clear` is exposed to the Nova instance."},{"line_number":35,"context_line":"    It can be done so in one of the three following ways, given that"},{"line_number":36,"context_line":"    OpenStack Nova supports three distinct CPU modes:"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"    a. ``[libvirt]/cpu_mode \u003d host-model``"},{"line_number":39,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfb3d3c7_bb28dc96","line":36,"range":{"start_line":34,"start_character":0,"end_line":36,"end_character":53},"updated":"2019-05-28 08:41:06.000000000","message":"nit - Would it be worth listing the virt drivers here, making it clear the following only applies to the Libvirt driver?","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"471d17e7dbe1572c0a6a6044f9028beb404586c8","unresolved":false,"context_lines":[{"line_number":31,"context_line":""},{"line_number":32,"context_line":"(2) Live migrate all the Nova instances to another Compute node."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"(3) Ensure that the CPU flag `md-clear` is exposed to the Nova instance."},{"line_number":35,"context_line":"    It can be done so in one of the three following ways, given that"},{"line_number":36,"context_line":"    OpenStack Nova supports three distinct CPU modes:"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"    a. ``[libvirt]/cpu_mode \u003d host-model``"},{"line_number":39,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_62cd695c","line":36,"range":{"start_line":34,"start_character":0,"end_line":36,"end_character":53},"in_reply_to":"9fb8cfa7_73ee9e89","updated":"2019-06-03 16:27:40.000000000","message":"Yes, with `virt_type\u003dkvm[|qemu]`","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":31,"context_line":""},{"line_number":32,"context_line":"(2) Live migrate all the Nova instances to another Compute node."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"(3) Ensure that the CPU flag `md-clear` is exposed to the Nova instance."},{"line_number":35,"context_line":"    It can be done so in one of the three following ways, given that"},{"line_number":36,"context_line":"    OpenStack Nova supports three distinct CPU modes:"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"    a. ``[libvirt]/cpu_mode \u003d host-model``"},{"line_number":39,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_73ee9e89","line":36,"range":{"start_line":34,"start_character":0,"end_line":36,"end_character":53},"in_reply_to":"bfb3d3c7_3eba9a6d","updated":"2019-06-03 13:48:46.000000000","message":"+1\n\nDoes this document only apply to libvirt?","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"dbfa2573290af1a079fd9c60f9ad0b95fd5e7f3a","unresolved":false,"context_lines":[{"line_number":31,"context_line":""},{"line_number":32,"context_line":"(2) Live migrate all the Nova instances to another Compute node."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"(3) Ensure that the CPU flag `md-clear` is exposed to the Nova instance."},{"line_number":35,"context_line":"    It can be done so in one of the three following ways, given that"},{"line_number":36,"context_line":"    OpenStack Nova supports three distinct CPU modes:"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"    a. ``[libvirt]/cpu_mode \u003d host-model``"},{"line_number":39,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfb3d3c7_3eba9a6d","line":36,"range":{"start_line":34,"start_character":0,"end_line":36,"end_character":53},"in_reply_to":"bfb3d3c7_bb28dc96","updated":"2019-05-28 09:33:54.000000000","message":"Yes, certainly worth it; will fix.  Matt Riedemann also sometimes reminds me of that: \"virt driver\" doesn\u0027t always mean \"libvirt driver\".","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":41,"context_line":"       will be passed through to the Nova guests automatically."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"       This mode is the default, when ``virt_type\u003dkvm|qemu`` is"},{"line_number":44,"context_line":"       set in ``/etc/nova/nova/conf``."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"    b. ``[libvirt]/cpu_mode \u003d host-passthrough``"},{"line_number":47,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_73877ed9","line":44,"range":{"start_line":44,"start_character":26,"end_line":44,"end_character":35},"updated":"2019-06-03 13:48:46.000000000","message":"nova.conf\n\n(Is it called nova-cpu.conf on compute nodes?)","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"df85b5562f47254487111173eacdd2c7ee6882af","unresolved":false,"context_lines":[{"line_number":41,"context_line":"       will be passed through to the Nova guests automatically."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"       This mode is the default, when ``virt_type\u003dkvm|qemu`` is"},{"line_number":44,"context_line":"       set in ``/etc/nova/nova/conf``."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"    b. ``[libvirt]/cpu_mode \u003d host-passthrough``"},{"line_number":47,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_91b1b3e4","line":44,"range":{"start_line":44,"start_character":26,"end_line":44,"end_character":35},"in_reply_to":"9fb8cfa7_73877ed9","updated":"2019-06-05 13:36:04.000000000","message":"Yeah","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":46,"context_line":"    b. ``[libvirt]/cpu_mode \u003d host-passthrough``"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"       When using ``host-passthrough`` CPU mode, the ``md-clear`` CPU"},{"line_number":49,"context_line":"       flag will be passed through to the Nova guests automatically."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"    c. A specific custom CPU model — this can be enabled using the"},{"line_number":52,"context_line":"       Nova config attributes: ``[libvirt]/cpu_mode \u003d custom`` plus a"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_b3665651","line":49,"updated":"2019-06-03 13:48:46.000000000","message":"meh, could combine a and b","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"471d17e7dbe1572c0a6a6044f9028beb404586c8","unresolved":false,"context_lines":[{"line_number":46,"context_line":"    b. ``[libvirt]/cpu_mode \u003d host-passthrough``"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"       When using ``host-passthrough`` CPU mode, the ``md-clear`` CPU"},{"line_number":49,"context_line":"       flag will be passed through to the Nova guests automatically."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"    c. A specific custom CPU model — this can be enabled using the"},{"line_number":52,"context_line":"       Nova config attributes: ``[libvirt]/cpu_mode \u003d custom`` plus a"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_c5b77fd8","line":49,"in_reply_to":"9fb8cfa7_b3665651","updated":"2019-06-03 16:27:40.000000000","message":"Here I disagree—the behavior of \u0027host-model\u0027 and \u0027host-passthrough\u0027 differ enough to justify explicitly spelling them out.  I know you\u0027re suggesting to combine points (a) \u0026 (b) to \"avoid repetition\", but in this case it\u0027s worth it.","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"aa1fc382309750ec487f13d99d5247cd1ffa3750","unresolved":false,"context_lines":[{"line_number":46,"context_line":"    b. ``[libvirt]/cpu_mode \u003d host-passthrough``"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"       When using ``host-passthrough`` CPU mode, the ``md-clear`` CPU"},{"line_number":49,"context_line":"       flag will be passed through to the Nova guests automatically."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"    c. A specific custom CPU model — this can be enabled using the"},{"line_number":52,"context_line":"       Nova config attributes: ``[libvirt]/cpu_mode \u003d custom`` plus a"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_1bfad441","line":49,"in_reply_to":"9fb8cfa7_c5b77fd8","updated":"2019-06-03 17:23:13.000000000","message":"Sure, no worries.","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":54,"context_line":"       IvyBridge``"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"       (The list of all valid named CPU models that are supported by"},{"line_number":57,"context_line":"       your host, QEMU and libvirt can be found out by running the"},{"line_number":58,"context_line":"       command ``virsh domcapabilities``.)"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"       When using a custom CPU mode, you must *explicitly* enable the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_33526669","line":57,"range":{"start_line":57,"start_character":42,"end_line":57,"end_character":51},"updated":"2019-06-03 13:48:46.000000000","message":"\"found\" or \"discovered\"","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"aa1fc382309750ec487f13d99d5247cd1ffa3750","unresolved":false,"context_lines":[{"line_number":67,"context_line":"           cpu_model \u003d IvyBridge"},{"line_number":68,"context_line":"           cpu_model_extra_flags \u003d spec-ctrl,ssbd,md-clear"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"(4) Reboot the Compute node for the fixes to take effect."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Once the above steps have been taken on every vulnerable compute"},{"line_number":73,"context_line":"node in the deployment, each running guest in the cluster must be"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_5b85acac","line":70,"updated":"2019-06-03 17:23:13.000000000","message":"\"To minimize workload downtime, you may wish to live migrate all guests to another compute node first.\"","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"aa1fc382309750ec487f13d99d5247cd1ffa3750","unresolved":false,"context_lines":[{"line_number":69,"context_line":""},{"line_number":70,"context_line":"(4) Reboot the Compute node for the fixes to take effect."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Once the above steps have been taken on every vulnerable compute"},{"line_number":73,"context_line":"node in the deployment, each running guest in the cluster must be"},{"line_number":74,"context_line":"fully powered down, and cold-booted (i.e. an explicit stop followed"},{"line_number":75,"context_line":"by a start), in order to activate the new CPU model.  This can be done"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_bbbdc869","line":72,"updated":"2019-06-03 17:23:13.000000000","message":"nit, this could be (5)","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"39e0c1bb73aa9b6822218ed2148fbebc1e275c5a","unresolved":false,"context_lines":[{"line_number":70,"context_line":"(4) Reboot the Compute node for the fixes to take effect."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Once the above steps have been taken on every vulnerable compute"},{"line_number":73,"context_line":"node in the deployment, each running guest in the cluster must be"},{"line_number":74,"context_line":"fully powered down, and cold-booted (i.e. an explicit stop followed"},{"line_number":75,"context_line":"by a start), in order to activate the new CPU model.  This can be done"},{"line_number":76,"context_line":"by the guest administrators at a time of their choosing."},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfb3d3c7_dced74f0","line":74,"range":{"start_line":73,"start_character":24,"end_line":74,"end_character":18},"updated":"2019-05-29 06:53:42.000000000","message":"sounds like the live migration is useless, since whatever you need to reboot the compute.","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"471d17e7dbe1572c0a6a6044f9028beb404586c8","unresolved":false,"context_lines":[{"line_number":70,"context_line":"(4) Reboot the Compute node for the fixes to take effect."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Once the above steps have been taken on every vulnerable compute"},{"line_number":73,"context_line":"node in the deployment, each running guest in the cluster must be"},{"line_number":74,"context_line":"fully powered down, and cold-booted (i.e. an explicit stop followed"},{"line_number":75,"context_line":"by a start), in order to activate the new CPU model.  This can be done"},{"line_number":76,"context_line":"by the guest administrators at a time of their choosing."},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_2247714e","line":74,"range":{"start_line":73,"start_character":24,"end_line":74,"end_character":18},"in_reply_to":"9fb8cfa7_53211a9f","updated":"2019-06-03 16:27:40.000000000","message":"(I was wrong on my previous point; sorry.)\n\n \u003e When the instance migrated to the _patched compute node, it can\u0027t\n \u003e get the new cpu feature, right?\n\nRight; it can\u0027t—you still need to cold-reboot (stop + start) the instance, for it to pick up the new features.","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":70,"context_line":"(4) Reboot the Compute node for the fixes to take effect."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Once the above steps have been taken on every vulnerable compute"},{"line_number":73,"context_line":"node in the deployment, each running guest in the cluster must be"},{"line_number":74,"context_line":"fully powered down, and cold-booted (i.e. an explicit stop followed"},{"line_number":75,"context_line":"by a start), in order to activate the new CPU model.  This can be done"},{"line_number":76,"context_line":"by the guest administrators at a time of their choosing."},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_f38e0ecf","line":74,"range":{"start_line":73,"start_character":24,"end_line":74,"end_character":18},"in_reply_to":"9fb8cfa7_53211a9f","updated":"2019-06-03 13:48:46.000000000","message":"Yeah, does the migrated instance still need to be cold booted?","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"db6e90d72c9cf26d64a3d0e4b6686ed1773ac3f1","unresolved":false,"context_lines":[{"line_number":70,"context_line":"(4) Reboot the Compute node for the fixes to take effect."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Once the above steps have been taken on every vulnerable compute"},{"line_number":73,"context_line":"node in the deployment, each running guest in the cluster must be"},{"line_number":74,"context_line":"fully powered down, and cold-booted (i.e. an explicit stop followed"},{"line_number":75,"context_line":"by a start), in order to activate the new CPU model.  This can be done"},{"line_number":76,"context_line":"by the guest administrators at a time of their choosing."},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_53211a9f","line":74,"range":{"start_line":73,"start_character":24,"end_line":74,"end_character":18},"in_reply_to":"9fb8cfa7_7f4ae580","updated":"2019-06-03 12:57:42.000000000","message":"When the instance migrated to the _patched compute node, it can\u0027t get the new cpu feature, right?","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"471d17e7dbe1572c0a6a6044f9028beb404586c8","unresolved":false,"context_lines":[{"line_number":70,"context_line":"(4) Reboot the Compute node for the fixes to take effect."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Once the above steps have been taken on every vulnerable compute"},{"line_number":73,"context_line":"node in the deployment, each running guest in the cluster must be"},{"line_number":74,"context_line":"fully powered down, and cold-booted (i.e. an explicit stop followed"},{"line_number":75,"context_line":"by a start), in order to activate the new CPU model.  This can be done"},{"line_number":76,"context_line":"by the guest administrators at a time of their choosing."},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_826f3dc4","line":74,"range":{"start_line":73,"start_character":24,"end_line":74,"end_character":18},"in_reply_to":"9fb8cfa7_f38e0ecf","updated":"2019-06-03 16:27:40.000000000","message":"\u003e Yeah, does the migrated instance still need to be cold booted?\n\nYes.\n\nLive-migrating never changes anything—because the guest ABI has to remain stable.  (Double-confirmed it with the libvirt and QEMU folks.)","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"c5b21d7a4e4db3350460c95c8ab8e5fcaba6923e","unresolved":false,"context_lines":[{"line_number":70,"context_line":"(4) Reboot the Compute node for the fixes to take effect."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Once the above steps have been taken on every vulnerable compute"},{"line_number":73,"context_line":"node in the deployment, each running guest in the cluster must be"},{"line_number":74,"context_line":"fully powered down, and cold-booted (i.e. an explicit stop followed"},{"line_number":75,"context_line":"by a start), in order to activate the new CPU model.  This can be done"},{"line_number":76,"context_line":"by the guest administrators at a time of their choosing."},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_7f4ae580","line":74,"range":{"start_line":73,"start_character":24,"end_line":74,"end_character":18},"in_reply_to":"bfb3d3c7_dced74f0","updated":"2019-06-03 09:43:55.000000000","message":"No, it is not useless: maybe you have introduced a Compute node that is already _patched_, and thus you can migrate your critical instances there, thus eliminating downtime for those instances.","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"df85b5562f47254487111173eacdd2c7ee6882af","unresolved":false,"context_lines":[{"line_number":83,"context_line":"patches are in effect by running either of the following (on the host)::"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"    # dmesg | grep \"MDS:\""},{"line_number":86,"context_line":"    [    0.162571] MDS: Vulnerable: Clear CPU buffers attempted, no microcode"},{"line_number":87,"context_line":"    [  181.862076] MDS: Mitigation: Clear CPU buffers"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"    # cat /sys/devices/system/cpu/vulnerabilities/mds"},{"line_number":90,"context_line":"    Mitigation: Clear CPU buffers; SMT vulnerable"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_7e1155ac","line":87,"range":{"start_line":86,"start_character":4,"end_line":87,"end_character":52},"updated":"2019-06-05 13:36:04.000000000","message":"Note to self: Copy/paste damage above.  On a machine that has SMT enabled, the above message is actually (which matches what \u0027sysfs\u0027 reports):\n\n    # dmesg | grep \"MDS:\"\n    [  181.862076] MDS: Mitigation: Clear CPU buffers; SMT vulnerable","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"79f0ff00db3c6531fee2a948e0431c9b3b115625","unresolved":false,"context_lines":[{"line_number":83,"context_line":"patches are in effect by running either of the following (on the host)::"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"    # dmesg | grep \"MDS:\""},{"line_number":86,"context_line":"    [    0.162571] MDS: Vulnerable: Clear CPU buffers attempted, no microcode"},{"line_number":87,"context_line":"    [  181.862076] MDS: Mitigation: Clear CPU buffers"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"    # cat /sys/devices/system/cpu/vulnerabilities/mds"},{"line_number":90,"context_line":"    Mitigation: Clear CPU buffers; SMT vulnerable"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_d82bb47f","line":87,"range":{"start_line":86,"start_character":4,"end_line":87,"end_character":52},"in_reply_to":"9fb8cfa7_7e1155ac","updated":"2019-06-05 14:39:21.000000000","message":"Actually, this whole \"dmesg\" bit should be removed, as it is not persistent.  I\u0027ll just refer to the \u0027sysfs\u0027 one, which _is_ persistent.","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":82,"context_line":"After applying relevant updates, administrators can check to ensure the"},{"line_number":83,"context_line":"patches are in effect by running either of the following (on the host)::"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"    # dmesg | grep \"MDS:\""},{"line_number":86,"context_line":"    [    0.162571] MDS: Vulnerable: Clear CPU buffers attempted, no microcode"},{"line_number":87,"context_line":"    [  181.862076] MDS: Mitigation: Clear CPU buffers"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"    # cat /sys/devices/system/cpu/vulnerabilities/mds"},{"line_number":90,"context_line":"    Mitigation: Clear CPU buffers; SMT vulnerable"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"On the host, validate that KVM is capable of exposing the ``md-clear``"},{"line_number":93,"context_line":"flag to guests::"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"    # virsh domcapabilities kvm | grep md-clear"},{"line_number":96,"context_line":"        \u003cfeature policy\u003d\u0027require\u0027 name\u003d\u0027md-clear\u0027/\u003e"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Also, refer to the \u0027Diagnosis\u0027 tab in this security notice document"},{"line_number":99,"context_line":"`here \u003chttps://access.redhat.com/security/vulnerabilities/mds\u003e`_"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_733f7ed6","line":96,"range":{"start_line":85,"start_character":0,"end_line":96,"end_character":51},"updated":"2019-06-03 13:48:46.000000000","message":"For dummies like me, it would be nice to add a little blurb explaining which bits of output mean that I\u0027ve done things right.\n\n\"If you see \u0027Mitigation\u0027, you\u0027re good.\"\n\n...if that\u0027s the key part.\n\nCause when I see \"SMT vulnerable\" it makes me think that there\u0027s still something wrong.","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"df85b5562f47254487111173eacdd2c7ee6882af","unresolved":false,"context_lines":[{"line_number":82,"context_line":"After applying relevant updates, administrators can check to ensure the"},{"line_number":83,"context_line":"patches are in effect by running either of the following (on the host)::"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"    # dmesg | grep \"MDS:\""},{"line_number":86,"context_line":"    [    0.162571] MDS: Vulnerable: Clear CPU buffers attempted, no microcode"},{"line_number":87,"context_line":"    [  181.862076] MDS: Mitigation: Clear CPU buffers"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"    # cat /sys/devices/system/cpu/vulnerabilities/mds"},{"line_number":90,"context_line":"    Mitigation: Clear CPU buffers; SMT vulnerable"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"On the host, validate that KVM is capable of exposing the ``md-clear``"},{"line_number":93,"context_line":"flag to guests::"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"    # virsh domcapabilities kvm | grep md-clear"},{"line_number":96,"context_line":"        \u003cfeature policy\u003d\u0027require\u0027 name\u003d\u0027md-clear\u0027/\u003e"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Also, refer to the \u0027Diagnosis\u0027 tab in this security notice document"},{"line_number":99,"context_line":"`here \u003chttps://access.redhat.com/security/vulnerabilities/mds\u003e`_"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_1eccd968","line":96,"range":{"start_line":85,"start_character":0,"end_line":96,"end_character":51},"in_reply_to":"9fb8cfa7_1b041417","updated":"2019-06-05 13:36:04.000000000","message":"\u003e Yeah, that\u0027s a good addition, but my point was more general. Even\n \u003e seeing:\n \u003e Mitigation: Clear CPU buffers\n \u003e ...I don\u0027t know whether that means I\u0027m good or not. Does that mean\n \u003e I should clear (verb) CPU buffers in order to mitigate? Does it\n \u003e mean I\u0027m mitigated because my CPU buffers are clear (adjective)?\n \u003e Does it mean I have a mitigation called \"Clear CPU buffers\" (noun)\n \u003e activated?\n\n\"Mitigation: Clear CPU buffers; SMT vulnerable\" means two things:\n\n* You have a \"CPU buffer clearing mitigation enabled\", as the Kernel doc[*] states.  \n* SMT is still enabled, that means you may still be vulnerable to SMT-problems, depending on your workload.\n\n[*] https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html#mds-system-information\n\n \u003e I\u0027m not necessarily expecting you to explain all of this here in\n \u003e the document. I was kind of hoping the link below would do it so\n \u003e you could just say, \"Please refer to \u003clink\u003e_ to verify the meaning\n \u003e of the output you\u0027re seeing.\"\n \u003e \n \u003e But it doesn\u0027t; it kinda just says the same thing you\u0027ve said here\n \u003e :(\n\nYeah, I hear your frustration; but the situation is, unfortunately, complex.\n\n \u003e So I\u0027m not sure what to do about this. I guess leave it alone\n \u003e unless you can find some better reference that you can refer to.\n\nI\u0027ve got a slightly better reference (the one I mentioned up the thread) that outlines what are the different possible values the `/sys/devices/system/cpu/vulnerabilities/mds` file can have, and their meaning:\n\nhttps://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html#mds-system-information","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f943291676b2bf2e99490aa43e7207d63a7aa244","unresolved":false,"context_lines":[{"line_number":82,"context_line":"After applying relevant updates, administrators can check to ensure the"},{"line_number":83,"context_line":"patches are in effect by running either of the following (on the host)::"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"    # dmesg | grep \"MDS:\""},{"line_number":86,"context_line":"    [    0.162571] MDS: Vulnerable: Clear CPU buffers attempted, no microcode"},{"line_number":87,"context_line":"    [  181.862076] MDS: Mitigation: Clear CPU buffers"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"    # cat /sys/devices/system/cpu/vulnerabilities/mds"},{"line_number":90,"context_line":"    Mitigation: Clear CPU buffers; SMT vulnerable"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"On the host, validate that KVM is capable of exposing the ``md-clear``"},{"line_number":93,"context_line":"flag to guests::"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"    # virsh domcapabilities kvm | grep md-clear"},{"line_number":96,"context_line":"        \u003cfeature policy\u003d\u0027require\u0027 name\u003d\u0027md-clear\u0027/\u003e"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Also, refer to the \u0027Diagnosis\u0027 tab in this security notice document"},{"line_number":99,"context_line":"`here \u003chttps://access.redhat.com/security/vulnerabilities/mds\u003e`_"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_98ae9c96","line":96,"range":{"start_line":85,"start_character":0,"end_line":96,"end_character":51},"in_reply_to":"9fb8cfa7_1eccd968","updated":"2019-06-05 14:58:06.000000000","message":"\u003e I\u0027ve got a slightly better reference\n\nAh, beautiful, so just leave it as:\n- run this command\n  \u003cexample output\u003e\n- refer to link_ to find out wtf the output means for you\n\nand don\u0027t even try to explain it here","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"aa1fc382309750ec487f13d99d5247cd1ffa3750","unresolved":false,"context_lines":[{"line_number":82,"context_line":"After applying relevant updates, administrators can check to ensure the"},{"line_number":83,"context_line":"patches are in effect by running either of the following (on the host)::"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"    # dmesg | grep \"MDS:\""},{"line_number":86,"context_line":"    [    0.162571] MDS: Vulnerable: Clear CPU buffers attempted, no microcode"},{"line_number":87,"context_line":"    [  181.862076] MDS: Mitigation: Clear CPU buffers"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"    # cat /sys/devices/system/cpu/vulnerabilities/mds"},{"line_number":90,"context_line":"    Mitigation: Clear CPU buffers; SMT vulnerable"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"On the host, validate that KVM is capable of exposing the ``md-clear``"},{"line_number":93,"context_line":"flag to guests::"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"    # virsh domcapabilities kvm | grep md-clear"},{"line_number":96,"context_line":"        \u003cfeature policy\u003d\u0027require\u0027 name\u003d\u0027md-clear\u0027/\u003e"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Also, refer to the \u0027Diagnosis\u0027 tab in this security notice document"},{"line_number":99,"context_line":"`here \u003chttps://access.redhat.com/security/vulnerabilities/mds\u003e`_"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_1b041417","line":96,"range":{"start_line":85,"start_character":0,"end_line":96,"end_character":51},"in_reply_to":"9fb8cfa7_65001336","updated":"2019-06-03 17:23:13.000000000","message":"Yeah, that\u0027s a good addition, but my point was more general. Even seeing:\n\n Mitigation: Clear CPU buffers\n\n...I don\u0027t know whether that means I\u0027m good or not. Does that mean I should clear (verb) CPU buffers in order to mitigate? Does it mean I\u0027m mitigated because my CPU buffers are clear (adjective)? Does it mean I have a mitigation called \"Clear CPU buffers\" (noun) activated?\n\nI\u0027m not necessarily expecting you to explain all of this here in the document. I was kind of hoping the link below would do it so you could just say, \"Please refer to \u003clink\u003e_ to verify the meaning of the output you\u0027re seeing.\"\n\nBut it doesn\u0027t; it kinda just says the same thing you\u0027ve said here :(\n\nSo I\u0027m not sure what to do about this. I guess leave it alone unless you can find some better reference that you can refer to.","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"471d17e7dbe1572c0a6a6044f9028beb404586c8","unresolved":false,"context_lines":[{"line_number":82,"context_line":"After applying relevant updates, administrators can check to ensure the"},{"line_number":83,"context_line":"patches are in effect by running either of the following (on the host)::"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"    # dmesg | grep \"MDS:\""},{"line_number":86,"context_line":"    [    0.162571] MDS: Vulnerable: Clear CPU buffers attempted, no microcode"},{"line_number":87,"context_line":"    [  181.862076] MDS: Mitigation: Clear CPU buffers"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"    # cat /sys/devices/system/cpu/vulnerabilities/mds"},{"line_number":90,"context_line":"    Mitigation: Clear CPU buffers; SMT vulnerable"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"On the host, validate that KVM is capable of exposing the ``md-clear``"},{"line_number":93,"context_line":"flag to guests::"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"    # virsh domcapabilities kvm | grep md-clear"},{"line_number":96,"context_line":"        \u003cfeature policy\u003d\u0027require\u0027 name\u003d\u0027md-clear\u0027/\u003e"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Also, refer to the \u0027Diagnosis\u0027 tab in this security notice document"},{"line_number":99,"context_line":"`here \u003chttps://access.redhat.com/security/vulnerabilities/mds\u003e`_"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_65001336","line":96,"range":{"start_line":85,"start_character":0,"end_line":96,"end_character":51},"in_reply_to":"9fb8cfa7_733f7ed6","updated":"2019-06-03 16:27:40.000000000","message":"Well, there _is_ something still wrong, that\u0027s the point of \"SMT vulnerable\" :-)\n\nThere are two parts to MDS:\n\n(a) Seeing the \u0027Mitigation\u0027 is _one_ of the main mitigations.\n\n(b) On the more complicated, \"SMT vulnerable\" bit, it means the unsatisfying: \"you have to make a decision whether to disable SMT or not based on your workloads\":\n\nOne case I learnt where you don\u0027t need to disable SMT is, *if* you can guarantee that a single CPU core is always pinned to a single VM, that is, two VMs don\u0027t share threads on a single core.  IOW, pinning cores mitigates the full effect.\n\nThat\u0027s not the *full* answer.  And there is no single \"true\" or \"false\" answer here.  On SMT, Red Hat\u0027s Security Notice doc[1] states:\n\n\"Disabling SMT for affected systems will reduce some of the attack surface, but will not completely eliminate all threats from these vulnerabilities.  To mitigate the risks these vulnerabilities introduce, systems will need updated microcode, updated kernel, virtualization patches, and administrators will need to evaluate if disabling SMT/HT is the right choice for their deployments. Additionally, applications may have a performance impact.\"\n\nI\u0027d refer to[2], and other similar docs from distributions.\n\n[1] https://access.redhat.com/security/vulnerabilities/mds\n    See the \"Resolve\" tab --\u003e \u0027Mitigation\u0027 section.\n[2] https://access.redhat.com/solutions/rhel-smt\n              - - -\n\nI\u0027ll capture all of this with the short and unsatisfying statement: \"The `SMT vulnerable` means you need to evaluate whether your workloads need SMT (also called \"Hyper-Threading\") to be disabled or not.  Refer to guidance from your Linux distribution and processor vendor.\"","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":105,"context_line":"Refer to this section titled \"Performance Impact and Disabling MDS\" from"},{"line_number":106,"context_line":"the security notice document `here"},{"line_number":107,"context_line":"\u003chttps://access.redhat.com/security/vulnerabilities/mds\u003e`_, under the"},{"line_number":108,"context_line":"\u0027Resolve\u0027 tab.  (Note that despite the article referred to is from Red"},{"line_number":109,"context_line":"Hat, the findings and recommendations about performance impact applies"},{"line_number":110,"context_line":"for other distributions as well.)"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_734a1e81","line":108,"range":{"start_line":108,"start_character":27,"end_line":108,"end_character":34},"updated":"2019-06-03 13:48:46.000000000","message":"although","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":106,"context_line":"the security notice document `here"},{"line_number":107,"context_line":"\u003chttps://access.redhat.com/security/vulnerabilities/mds\u003e`_, under the"},{"line_number":108,"context_line":"\u0027Resolve\u0027 tab.  (Note that despite the article referred to is from Red"},{"line_number":109,"context_line":"Hat, the findings and recommendations about performance impact applies"},{"line_number":110,"context_line":"for other distributions as well.)"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_332106b6","line":109,"range":{"start_line":109,"start_character":63,"end_line":109,"end_character":70},"updated":"2019-06-03 13:48:46.000000000","message":"apply","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"29a263f9b0976f8a7a8d1c6bf67d59933b79b78a","unresolved":false,"context_lines":[{"line_number":87,"context_line":"    # cat /sys/devices/system/cpu/vulnerabilities/mds"},{"line_number":88,"context_line":"    Mitigation: Clear CPU buffers; SMT vulnerable"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"To unpact the message \"Mitigation: Clear CPU buffers; SMT vulnerable\":"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"  - The ``Mitigation: Clear CPU buffers`` bit means, you have the \"CPU"},{"line_number":93,"context_line":"    buffer clearing mitigation enabled\" (which is mechanism to invoke a"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_5b5b3e53","line":90,"range":{"start_line":90,"start_character":3,"end_line":90,"end_character":9},"updated":"2019-06-05 15:52:48.000000000","message":"unpack","commit_id":"f265a364eed4f74919c67a4c5868af1d34edde1f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"29a263f9b0976f8a7a8d1c6bf67d59933b79b78a","unresolved":false,"context_lines":[{"line_number":90,"context_line":"To unpact the message \"Mitigation: Clear CPU buffers; SMT vulnerable\":"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"  - The ``Mitigation: Clear CPU buffers`` bit means, you have the \"CPU"},{"line_number":93,"context_line":"    buffer clearing mitigation enabled\" (which is mechanism to invoke a"},{"line_number":94,"context_line":"    flush of various exploitable CPU buffers by invoking a CPU"},{"line_number":95,"context_line":"    instruction called \"VERW\")."},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_1b55c61d","line":93,"range":{"start_line":93,"start_character":38,"end_line":93,"end_character":39},"updated":"2019-06-05 15:52:48.000000000","message":"nit, move closing quote one word earlier?","commit_id":"f265a364eed4f74919c67a4c5868af1d34edde1f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"29a263f9b0976f8a7a8d1c6bf67d59933b79b78a","unresolved":false,"context_lines":[{"line_number":100,"context_line":"    be disabled or not.  Refer to the guidance from your Linux"},{"line_number":101,"context_line":"    distribution and processor vendor."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"To see what are the other possible values for the sysfs file,"},{"line_number":104,"context_line":"``/sys/devices/system/cpu/vulnerabilities/mds``, refer to the `MDS"},{"line_number":105,"context_line":"system information"},{"line_number":106,"context_line":"\u003chttps://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html#mds-system-information\u003e`_"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_5b201eb1","line":103,"range":{"start_line":103,"start_character":7,"end_line":103,"end_character":15},"updated":"2019-06-05 15:52:48.000000000","message":"strike","commit_id":"f265a364eed4f74919c67a4c5868af1d34edde1f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"29a263f9b0976f8a7a8d1c6bf67d59933b79b78a","unresolved":false,"context_lines":[{"line_number":104,"context_line":"``/sys/devices/system/cpu/vulnerabilities/mds``, refer to the `MDS"},{"line_number":105,"context_line":"system information"},{"line_number":106,"context_line":"\u003chttps://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html#mds-system-information\u003e`_"},{"line_number":107,"context_line":"section in Linux kernel\u0027s documentation for MDS."},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"On the host, validate that KVM is capable of exposing the ``md-clear``"},{"line_number":110,"context_line":"flag to guests::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_bb1a7a7a","line":107,"updated":"2019-06-05 15:52:48.000000000","message":"++","commit_id":"f265a364eed4f74919c67a4c5868af1d34edde1f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"e8c9118bb1a561b00f6ad15a741634f250b016b3","unresolved":false,"context_lines":[{"line_number":1,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":2,"context_line":"Mitigation for MDS (\"Microarchitectural Data Sampling\") Security Flaws"},{"line_number":3,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":4,"context_line":""},{"line_number":5,"context_line":"Issue"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_0a6a44b2","line":2,"range":{"start_line":2,"start_character":0,"end_line":2,"end_character":70},"updated":"2019-06-06 08:28:21.000000000","message":"maybe we should call it out this is just for libvirt virt driver in the title","commit_id":"f394703f7e1e0d2df3af197ff39be04c8f51a562"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"58400de86a563973326d3a47e116820e5732a209","unresolved":false,"context_lines":[{"line_number":1,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":2,"context_line":"Mitigation for MDS (\"Microarchitectural Data Sampling\") Security Flaws"},{"line_number":3,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":4,"context_line":""},{"line_number":5,"context_line":"Issue"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_2ac70848","line":2,"range":{"start_line":2,"start_character":0,"end_line":2,"end_character":70},"in_reply_to":"9fb8cfa7_0a6a44b2","updated":"2019-06-06 08:51:40.000000000","message":"Hmm, probably.  But I mentioned in the Resolution section, in the second step.  (Yeah, that\u0027s a bit buried, but hope it would be quickly obvious.)","commit_id":"f394703f7e1e0d2df3af197ff39be04c8f51a562"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"e8c9118bb1a561b00f6ad15a741634f250b016b3","unresolved":false,"context_lines":[{"line_number":66,"context_line":"           cpu_model \u003d IvyBridge"},{"line_number":67,"context_line":"           cpu_model_extra_flags \u003d spec-ctrl,ssbd,md-clear"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"(3) Reboot the compute node for the fixes to take effect.  (To minimize"},{"line_number":70,"context_line":"    workload downtime, you may wish to live migrate all guests to"},{"line_number":71,"context_line":"    another compute node first.)"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Once the above steps have been taken on every vulnerable compute"},{"line_number":74,"context_line":"node in the deployment, each running guest in the cluster must be"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_2a65c8e1","line":71,"range":{"start_line":69,"start_character":60,"end_line":71,"end_character":31},"updated":"2019-06-06 08:28:21.000000000","message":"maybe worth a link to the regular upgrade process.","commit_id":"f394703f7e1e0d2df3af197ff39be04c8f51a562"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"58400de86a563973326d3a47e116820e5732a209","unresolved":false,"context_lines":[{"line_number":66,"context_line":"           cpu_model \u003d IvyBridge"},{"line_number":67,"context_line":"           cpu_model_extra_flags \u003d spec-ctrl,ssbd,md-clear"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"(3) Reboot the compute node for the fixes to take effect.  (To minimize"},{"line_number":70,"context_line":"    workload downtime, you may wish to live migrate all guests to"},{"line_number":71,"context_line":"    another compute node first.)"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Once the above steps have been taken on every vulnerable compute"},{"line_number":74,"context_line":"node in the deployment, each running guest in the cluster must be"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_eac0102d","line":71,"range":{"start_line":69,"start_character":60,"end_line":71,"end_character":31},"in_reply_to":"9fb8cfa7_2a65c8e1","updated":"2019-06-06 08:51:40.000000000","message":"Yeah, can do as a follow-up.","commit_id":"f394703f7e1e0d2df3af197ff39be04c8f51a562"}],"doc/source/admin/security.rst":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb43b6a59e47d6cd3ca18b8d428ad759479f9df","unresolved":false,"context_lines":[{"line_number":54,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"It is strongly recommended to patch all compute nodes and nova instances"},{"line_number":57,"context_line":"from the processor-related security flaws, such as MDS (and other"},{"line_number":58,"context_line":"previous vulnerabilities).  For details on applying mitigation for the"},{"line_number":59,"context_line":"MDS flaws, refer to the :doc:`mitigation-for-Intel-MDS-security-flaws`"},{"line_number":60,"context_line":"document."}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_b31e566e","line":57,"range":{"start_line":57,"start_character":0,"end_line":57,"end_character":4},"updated":"2019-06-03 13:48:46.000000000","message":"against?","commit_id":"b28b4d748e3e70c6b2754389ead3ad6345dfa7d3"}]}