{"push_id":2330321825,"size":24,"distinct_size":24,"ref":"refs/heads/staging-4.6","head":"75bdd693033e6dbd6fe5ae235f79961d2f0aa84d","before":"44ad7f6895da9861042d7a41e635d42d83cb2660","commits":[{"sha":"a735c7ae8046024925927406747d4a6ca5bf7fcc","author":{"name":"Tom Lendacky","email":"aae724d943dd57e8b9dec8b455e9688272d2d782@amd.com"},"message":"x86/microcode: Add support for fam17h microcode loading\n\nThe size for the Microcode Patch Block (MPB) for an AMD family 17h\nprocessor is 3200 bytes.  Add a #define for fam17h so that it does\nnot default to 2048 bytes and fail a microcode load/update.\n\nSigned-off-by: Tom Lendacky <thomas.lendacky@amd.com>\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nReviewed-by: Borislav Petkov <bp@alien8.de>\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n[Linux commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf]\n\nPorted to Xen.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nAcked-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: 61d458ba8c171809e8dd9abd19339c87f3f934ca\nmaster date: 2017-12-13 14:30:10 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/a735c7ae8046024925927406747d4a6ca5bf7fcc"},{"sha":"9ce1a7180050353c07321980cf1ed0b0baebf38a","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/alt: Break out alternative-asm into a separate header file\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Wei Liu <wei.liu2@citrix.com>\nAcked-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: 9d7b4351d3bb5c744db311cffa57ba3ebb583327\nmaster date: 2018-01-05 19:57:07 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/9ce1a7180050353c07321980cf1ed0b0baebf38a"},{"sha":"03c7d2cd1b4bb9868c10c4a3db2b092d211d055a","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/alt: Introduce ALTERNATIVE{,_2} macros\n\nTo help creating alternative frames in assembly.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: 4711428f5e2a9bfff9f8d75b6a696072118c19a4\nmaster date: 2018-01-05 19:57:07 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/03c7d2cd1b4bb9868c10c4a3db2b092d211d055a"},{"sha":"f7e273a07ccf993063727675589f10da206f1683","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/entry: Rearrange RESTORE_ALL to restore register in stack order\n\nResults in a more predictable (i.e. linear) memory access pattern.\n\nNo functional change.\n\nThis is part of XSA-254.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nReviewed-by: Wei Liu <wei.liu2@citrix.com>\nmaster commit: f85d105e27735f0e20aa30d77f03774f3ed55ae5\nmaster date: 2018-01-05 19:57:08 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/f7e273a07ccf993063727675589f10da206f1683"},{"sha":"75263f7908a02f5673c25df9bcdaed9fe5f9de5c","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/hvm: Use SAVE_ALL to construct the cpu_user_regs frame after VMExit\n\nNo practical change.\n\nOne side effect in debug builds is that %rbp is inverted in the manner\nexpected by the stack unwinder to indicate a interrupt frame.\n\nThis is part of XSA-254.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nReviewed-by: Wei Liu <wei.liu2@citrix.com>\nmaster commit: 13682ca8c94bd5612a44f7f1edc1fd8ff675dacb\nmaster date: 2018-01-05 19:57:08 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/75263f7908a02f5673c25df9bcdaed9fe5f9de5c"},{"sha":"ec05090403ef4d760fbe701e31afd0f0edc414d5","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/entry: Erase guest GPR state on entry to Xen\n\nThis reduces the number of code gadgets which can be attacked with arbitrary\nguest-controlled GPR values.\n\nThis is part of XSA-254.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nReviewed-by: Wei Liu <wei.liu2@citrix.com>\nmaster commit: 03bd8c3a70d101fc2f8f36f1e171b7594462a4cd\nmaster date: 2018-01-05 19:57:08 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/ec05090403ef4d760fbe701e31afd0f0edc414d5"},{"sha":"af5b61af9e350bcc2c8b0f053682e3c7a700b46f","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"common/wait: Clarifications to wait infrastructure\n\nThis logic is not as clear as it could be.  Add some comments to help.\n\nRearrange the asm block in __prepare_to_wait() to separate the GPR\nsaving/restoring from the internal logic.\n\nWhile tweaking, add an unreachable() following the jmp in\ncheck_wakeup_from_wait().\n\nNo functional change.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: 2d1c82261d966735e82e5971eddb63ba3c565a37\nmaster date: 2018-01-05 19:57:08 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/af5b61af9e350bcc2c8b0f053682e3c7a700b46f"},{"sha":"8edfc82f67f25137909dda13e6658cba4d1e5d26","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86: Support compiling with indirect branch thunks\n\nUse -mindirect-branch=thunk-extern/-mindirect-branch-register when available.\nTo begin with, use the retpoline thunk.  Later work will add alternative\nthunks which can be selected at boot time.\n\nThis is part of XSA-254.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nAcked-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: 3659f0f4bcc6ca08103d1a7ae4e97535ecc978be\nmaster date: 2018-01-16 17:45:50 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/8edfc82f67f25137909dda13e6658cba4d1e5d26"},{"sha":"9089da9cd06875be6c1022d59a6651cf3919da2e","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86: Support indirect thunks from assembly code\n\nIntroduce INDIRECT_CALL and INDIRECT_JMP which either degrade to a normal\nindirect branch, or dispatch to the __x86_indirect_thunk_* symbols.\n\nUpdate all the manual indirect branches in to use the new thunks.  The\nindirect branches in the early boot and kexec path are left intact as we can't\nuse the compiled-in thunks at those points.\n\nThis is part of XSA-254.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: 7c508612f7a5096b4819d4ef2ce566e01bd66c0c\nmaster date: 2018-01-16 17:45:50 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/9089da9cd06875be6c1022d59a6651cf3919da2e"},{"sha":"ab20c5c804ae814de9bed5f85d55fecc894dc78f","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/boot: Report details of speculative mitigations\n\nNothing very interesting at the moment, but the logic will grow as new\nmitigations are added.\n\nThis is part of XSA-254.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nAcked-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: 31d6c53adf6417bf449ca50e8416e41b64d46803\nmaster date: 2018-01-16 17:45:50 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/ab20c5c804ae814de9bed5f85d55fecc894dc78f"},{"sha":"8335c8aedacd9a50b4796afb533dc8205f2129e4","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/amd: Try to set lfence as being Dispatch Serialising\n\nThis property is required for the AMD's recommended mitigation for Branch\nTarget Injection, but Xen needs to cope with being unable to detect or modify\nthe MSR.\n\nThis is part of XSA-254.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: fe3ee5530a8d0d0b6a478167125d00c40f294a86\nmaster date: 2018-01-16 17:45:50 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/8335c8aedacd9a50b4796afb533dc8205f2129e4"},{"sha":"2613a1bc709ed4b46af36b0bab3200ed9d3c86d0","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86: Introduce alternative indirect thunks\n\nDepending on hardware and microcode availability, we will want to replace\nIND_THUNK_REPOLINE with other implementations.\n\nFor AMD hardware, choose IND_THUNK_LFENCE in preference to retpoline if lfence\nis known to be (or was successfully made) dispatch serialising.\n\nThis is part of XSA-254.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: 858cba0d4c6b6b45180afcb41561fd6585ad51a3\nmaster date: 2018-01-16 17:45:50 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/2613a1bc709ed4b46af36b0bab3200ed9d3c86d0"},{"sha":"ff4800cac63756f7755e6c251571cd29fd5171eb","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/feature: Definitions for Indirect Branch Controls\n\nContemporary processors are gaining Indirect Branch Controls via microcode\nupdates.  Intel are introducing one bit to indicate IBRS and IBPB support, and\na second bit for STIBP.  AMD are introducing IBPB only, so enumerate it with a\nseparate bit.\n\nFurthermore, depending on compiler and microcode availability, we may want to\nrun Xen with IBRS set, or clear.\n\nTo use these facilities, we synthesise separate IBRS and IBPB bits for\ninternal use.  A lot of infrastructure is required before these features are\nsafe to offer to guests.\n\nThis is part of XSA-254.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nAcked-by: Wei Liu <wei.liu2@citrix.com>\nmaster commit: 0d703a701cc4bc47773986b2796eebd28b1439b5\nmaster date: 2018-01-16 17:45:50 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/ff4800cac63756f7755e6c251571cd29fd5171eb"},{"sha":"4d2154914e3f44bae123dc6a93fbb3f1b39c0fee","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/cmdline: Introduce a command line option to disable IBRS/IBPB, STIBP and IBPB\n\nInstead of gaining yet another top level boolean, introduce a more generic\ncpuid= option.  Also introduce a helper function to parse a generic boolean\nvalue.\n\nThis is part of XSA-254.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\n\nxen/cmdline: Fix parse_boolean() for unadorned values\n\nA command line such as \"cpuid=no-ibrsb,no-stibp\" tickles a bug in\nparse_boolean() because the separating comma fails the NUL case.\n\nInstead, check for slen == nlen which accounts for the boundary (if any)\npassed via the 'e' parameter.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: 7850b1c00749df834ea2ad0c1f5d9364c4838795\nmaster date: 2018-01-16 17:45:50 +0000\nmaster commit: ac37ec1ddef234eeba6f438c29ff687c64962ebd\nmaster date: 2018-01-31 10:47:12 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/4d2154914e3f44bae123dc6a93fbb3f1b39c0fee"},{"sha":"4e1b9e98dffbc2f29a0a90a4ae43b9e19f323089","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests\n\nIntel specifies IBRS/IBPB (combined, in a single bit) and STIBP as a separate\nbit.  AMD specifies IBPB alone in a 3rd bit.\n\nAMD's IBPB is a subset of Intel's combined IBRS/IBPB.  For performance\nreasons, administrators might wish to express \"IBPB only\" even on Intel\nhardware, so we allow the AMD bit to be used for this purpose.\n\nThe behaviour of STIBP is more complicated.\n\nIt is our current understanding that STIBP will be advertised on HT-capable\nhardware irrespective of whether HT is enabled, but not advertised on\nHT-incapable hardware.  However, for ease of virtualisation, STIBP's\nfunctionality is ignored rather than reserved by microcode/hardware on\nHT-incapable hardware.\n\nFor guest safety, we treat STIBP as special, always override the toolstack\nchoice, and always advertise STIBP if IBRS is available.  This removes the\ncorner case where STIBP is not advertised, but the guest is running on\nHT-capable hardware where it does matter.\n\nFinally as a bugfix, update the libxc CPUID logic to understand the e8b\nfeature leaf, which has the side effect of also offering CLZERO to guests on\napplicable hardware.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nAcked-by: Wei Liu <wei.liu2@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: d297b56682e730d598e2529cc6998151d3b6f6f8\nmaster date: 2018-01-26 14:10:21 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/4e1b9e98dffbc2f29a0a90a4ae43b9e19f323089"},{"sha":"41a5ccec99e81a768a66995f483f424f848f5b5e","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/msr: Emulation of MSR_{SPEC_CTRL,PRED_CMD} for guests\n\nAs per the spec currently available here:\n\nhttps://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf\n\nMSR_ARCH_CAPABILITIES will only come into existence on new hardware, but is\nimplemented as a straight #GP for now to avoid being leaky when new hardware\narrives.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: ea58a679a6190e714a592f1369b660769a48a80c\nmaster date: 2018-01-26 14:10:21 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/41a5ccec99e81a768a66995f483f424f848f5b5e"},{"sha":"db743b04998a9cbf6866b5f328855239a73220e5","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/migrate: Move MSR_SPEC_CTRL on migrate\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Wei Liu <wei.liu2@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: 0cf2a4eb769302b7d7d7835540e7b2f15006df30\nmaster date: 2018-01-26 14:10:21 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/db743b04998a9cbf6866b5f328855239a73220e5"},{"sha":"44c2666589fefc13049edc874c7ef063823bad90","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL,PRED_CMD}\n\nFor performance reasons, HVM guests should have direct access to these MSRs\nwhen possible.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nReviewed-by: Kevin Tian <kevin.tian@intel.com>\nmaster commit: 5a2fe171144ebcc908ea1fca45058d6010f6a286\nmaster date: 2018-01-26 14:10:21 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/44c2666589fefc13049edc874c7ef063823bad90"},{"sha":"0163087ed6175b00966f4ee991d8c424ad7eb59d","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point\n\nWe need to be able to either set or clear IBRS in Xen context, as well as\nrestore appropriate guest values in guest context.  See the documentation in\nasm-x86/spec_ctrl_asm.h for details.\n\nWith the contemporary microcode, writes to %cr3 are slower when SPEC_CTRL.IBRS\nis set.  Therefore, the positioning of SPEC_CTRL_{ENTRY/EXIT}* is important.\n\nIdeally, the IBRS_SET/IBRS_CLEAR hunks might be positioned either side of the\n%cr3 change, but that is rather more complicated to arrange, and could still\nresult in a guest controlled value in SPEC_CTRL during the %cr3 change,\nnegating the saving if the guest chose to have IBRS set.\n\nTherefore, we optimise for the pre-Skylake case (being far more common in the\nfield than Skylake and later, at the moment), where we have a Xen-preferred\nvalue of IBRS clear when switching %cr3.\n\nThere is a semi-unrelated bugfix, where various asm_defn.h macros have a\nhidden dependency on PAGE_SIZE, which results in an assembler error if used in\na .macro definition.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: 5e7962901131186d3514528ed57c7a9901a15a3e\nmaster date: 2018-01-26 14:10:21 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/0163087ed6175b00966f4ee991d8c424ad7eb59d"},{"sha":"feba571a5d9586778e0978b8df5b9166275b8680","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/entry: Organise the clobbering of the RSB/RAS on entry to Xen\n\nret instructions are speculated directly to values recorded in the Return\nStack Buffer/Return Address Stack, as there is no uncertainty in well-formed\ncode.  Guests can take advantage of this in two ways:\n\n  1) If they can find a path in Xen which executes more ret instructions than\n     call instructions.  (At least one in the waitqueue infrastructure,\n     probably others.)\n\n  2) Use the fact that the RSB/RAS in hardware is actually a circular stack\n     without a concept of empty.  (When it logically empties, stale values\n     will start being used.)\n\nTo mitigate, overwrite the RSB on entry to Xen with gadgets which will capture\nand contain rogue speculation.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nmaster commit: e6c0128e9ab25bf66df11377a33ee5584d7f99e3\nmaster date: 2018-01-26 14:10:21 +0000","distinct":true,"url":"https://api.github.com/repos/xen-project/xen/commits/feba571a5d9586778e0978b8df5b9166275b8680"}]}
{"actor":{"display_login":"hubot"}}