@section history History
The Xen Test Framework grew out of the work done to debug
-[XSA-106](http://xenbits.xen.org/xsa/advisory-106.html). As reported, Xen's
+[XSA-106](https://xenbits.xen.org/xsa/advisory-106.html). As reported, Xen's
instruction emulator failed to perform dpl checks for instructions generating
software exceptions, which allowed guest userspace to bypass a security check
set up by the guest kernel. Further investigation showed that the exception
not behaving as described in the manual.
Once the embargo on XSA-106 lifted, changesets
-[7dfa94c](http://xenbits.xen.org/gitweb/
+[7dfa94c](https://xenbits.xen.org/gitweb/
?p=xen.git;a=commitdiff;h=7dfa94c6212b979cbfc8cff5ad5336922f4809d9),
-[ecf5678](http://xenbits.xen.org/gitweb/
+[ecf5678](https://xenbits.xen.org/gitweb/
?p=xen.git;a=commitdiff;h=ecf5678200ad2642b69ffea47ad138190bc3e190) and
-[36ebf14](http://xenbits.xen.org/gitweb/
+[36ebf14](https://xenbits.xen.org/gitweb/
?p=xen.git;a=commitdiff;h=36ebf14ebe60310aa22952cbb94de951c158437d) were the
eventual bugfixes which caused Xen to inject software exceptions correctly.
were not being done.
Moving forward by a year, the author was dismayed to discover that the
-[XSA-156](http://xenbits.xen.org/xsa/advisory-156.html) release contained a
+[XSA-156](https://xenbits.xen.org/xsa/advisory-156.html) release contained a
regression (causing infinite loops inside guests which used hardware debugging
-facilities, fixed in [0747bc8](http://xenbits.xen.org/gitweb/
+facilities, fixed in [0747bc8](https://xenbits.xen.org/gitweb/
?p=xen.git;a=commitdiff;h=0747bc8b4d85f3fc0ee1e58418418fa0229e8ff8)) which
would have been caught by the original test for XSA-106, had that test been in
a usable state.
*
* The set of identifiers to be added here shouldn't extend beyond what
* POSIX mandates (see e.g.
- * http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html)
+ * https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html)
* with the exception that we support some optional (XSR) values
* specified there (but no new ones should be added).
*/
cat <<EOF
* @page test-$NAME $NAME_UC
*
- * Advisory: [$NAME_UC](http://xenbits.xen.org/xsa/advisory-${NAME#xsa-}.html)
+ * Advisory: [$NAME_UC](https://xenbits.xen.org/xsa/advisory-${NAME#xsa-}.html)
EOF
fi
* The following general tests are implemented:
*
* 1. Xen, before
- * [46029da12e](http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=46029da12e5efeca6d957e5793bd34f2965fa0a1)
+ * [46029da12e](https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=46029da12e5efeca6d957e5793bd34f2965fa0a1)
* failed to initialise the guests debug registers correctly. On hardware
* which supports Restricted Transactional Memory, this becomes visible,
* as @%dr6.rtm appears asserted (clear, for backwards compatibility)
* The following PV tests are implemented:
*
* 1. Xen, between
- * [65e3554908](http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=65e355490817ac1783c9ef06c13cf980edf05b5b)
+ * [65e3554908](https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=65e355490817ac1783c9ef06c13cf980edf05b5b)
* (Introduced in Xen 4.5) and
- * [adf8feba1a](http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=adf8feba1afa040f3a84a82953e18af02060884a)
+ * [adf8feba1a](https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=adf8feba1afa040f3a84a82953e18af02060884a)
* (Fixed in Xen 4.11) had a bug whereby some writes to @%dr7 didn't take
* immediate effect.
*
* reschedule.
*
* 2. Xen, before
- * [f539ae2706](http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=f539ae27061c6811fd5e80e0755bf0514e22b977)
+ * [f539ae2706](https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=f539ae27061c6811fd5e80e0755bf0514e22b977)
* (Xen 4.11) had a bug whereby a write which cleared @%dr7.L/G would
* leave stale IO shadow state visible in later reads of @%dr7.
*
* Unfortunately, that changeset introduced a second bug, fixed by
- * [237c31b5a1](http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=237c31b5a1d5aa88cdb59b8c31b1b62eb13e82d1)
+ * [237c31b5a1](https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=237c31b5a1d5aa88cdb59b8c31b1b62eb13e82d1)
* (Xen 4.11), which caused an attempt to set up an IO breakpoint with
* @%cr4.DE clear to clobber an already configured state, despite the
* update failing.
*
* @page test-xsa-122 XSA-122
*
- * Advisory: [XSA-122](http://xenbits.xen.org/xsa/advisory-122.html)
+ * Advisory: [XSA-122](https://xenbits.xen.org/xsa/advisory-122.html)
*
* Before XSA-122, Xen would fill a fixed size stack array with a
* NUL-terminated string, and copy the entire array back to guest space. This
*
* @page test-xsa-123 XSA-123
*
- * Advisory: [XSA-123](http://xenbits.xen.org/xsa/advisory-123.html)
+ * Advisory: [XSA-123](https://xenbits.xen.org/xsa/advisory-123.html)
*
* An x86 instruction destination operand is either a memory reference or a
* register. Memory references always have an associated selector, and
*
* @page test-xsa-167 XSA-167
*
- * Advisory: [XSA-167](http://xenbits.xen.org/xsa/advisory-167.html)
+ * Advisory: [XSA-167](https://xenbits.xen.org/xsa/advisory-167.html)
*
* The MMUEXT subops MARK_SUPER and UNMARK_SUPER do not perform a range check
* on the `mfn` parameter before indexing the superframe array. They do
*
* @page test-xsa-168 XSA-168
*
- * Advisory: [XSA-168](http://xenbits.xen.org/xsa/advisory-168.html)
+ * Advisory: [XSA-168](https://xenbits.xen.org/xsa/advisory-168.html)
*
* This vulnerability only affects VT-x hardware, and can only exploited by a
* guest running with shadow paging.
*
* @page test-xsa-170 XSA-170
*
- * Advisory: [XSA-170](http://xenbits.xen.org/xsa/advisory-170.html)
+ * Advisory: [XSA-170](https://xenbits.xen.org/xsa/advisory-170.html)
*
* XSA-170 concerns a vmentry quirk on VMX hardware, which causes the vmentry
* to fail if @%rip is non-canonical. This bug does not affect SVM hardware,
*
* @page test-xsa-173 XSA-173
*
- * Advisory: [XSA-173](http://xenbits.xen.org/xsa/advisory-173.html)
+ * Advisory: [XSA-173](https://xenbits.xen.org/xsa/advisory-173.html)
*
* This vulnerability only affects guests running with shadow paging. Xen
* truncated the shadowed gfn into a 32bit variable, causing issues later when
*
* @page test-xsa-182 XSA-182
*
- * Advisory: [XSA-182](http://xenbits.xen.org/xsa/advisory-182.html)
+ * Advisory: [XSA-182](https://xenbits.xen.org/xsa/advisory-182.html)
*
* There is a trick with pagetables, known as recursive pagetables (also
* linear or twisted pagetables), where a top level pagetable referrers back
*
* @page test-xsa-183 XSA-183
*
- * Advisory: [XSA-183](http://xenbits.xen.org/xsa/advisory-183.html)
+ * Advisory: [XSA-183](https://xenbits.xen.org/xsa/advisory-183.html)
*
* This vulnerability only affects hardware supporting SMAP (Intel
* Broadwell/AMD Zen or later) on Xen 4.5 or later (due to the addition of
*
* @page test-xsa-185 XSA-185
*
- * Advisory: [XSA-185](http://xenbits.xen.org/xsa/advisory-185.html)
+ * Advisory: [XSA-185](https://xenbits.xen.org/xsa/advisory-185.html)
*
* This vulnerability is along the same lines as XSA-182, and was uncovered
* once XSA-182 had been fixed. Please refer to 182 for the discussion of
*
* @page test-xsa-186 XSA-186
*
- * Advisory: [XSA-186](http://xenbits.xen.org/xsa/advisory-186.html)
+ * Advisory: [XSA-186](https://xenbits.xen.org/xsa/advisory-186.html)
*
* Experimentally, Intel and AMD hardware is happy executing a 64bit
* instruction stream which crosses the -1 -> 0 virtual boundary, whether the
* used and behaves normally as a 32bit register, including in 16bit protected
* mode segments, as well as in Real and Unreal mode.
*
- * The upstream change [0640ffb6](http://xenbits.xen.org/gitweb/
+ * The upstream change [0640ffb6](https://xenbits.xen.org/gitweb/
* ?p=xen.git;a=commitdiff;h=0640ffb67fb92e2561c63b9308c27b71281fdd72) broke
* this behaviour, and introduced conditions which resulted in x86 emulator
* state corruption.
*
* @page test-xsa-188 XSA-188
*
- * Advisory: [XSA-188](http://xenbits.xen.org/xsa/advisory-188.html)
+ * Advisory: [XSA-188](https://xenbits.xen.org/xsa/advisory-188.html)
*
* EVTCHNOP_init_control with an invalid control_gfn will correctly
* fail and free resources but incorrectly leaves a pointer to freed
*
* @page test-xsa-191 XSA-191
*
- * Advisory: [XSA-191](http://xenbits.xen.org/xsa/advisory-191.html)
+ * Advisory: [XSA-191](https://xenbits.xen.org/xsa/advisory-191.html)
*
* Before XSA-191, Xen had several bugs with its handling of segments which
* shouldn't be eligible for use. Memory accesses through user segments and
*
* @page test-xsa-192 XSA-192
*
- * Advisory: [XSA-192](http://xenbits.xen.org/xsa/advisory-192.html)
+ * Advisory: [XSA-192](https://xenbits.xen.org/xsa/advisory-192.html)
*
* Before XSA-192, a bug existed with Xen's handling of task switches into
* vm86 mode, whereby LDTR got loaded with vm86 attributes.
*
* @page test-xsa-193 XSA-193
*
- * Advisory: [XSA-193](http://xenbits.xen.org/xsa/advisory-193.html)
+ * Advisory: [XSA-193](https://xenbits.xen.org/xsa/advisory-193.html)
*
- * Xen change [c42494acb2](http://xenbits.xen.org/gitweb/
+ * Xen change [c42494acb2](https://xenbits.xen.org/gitweb/
* ?p=xen.git;a=commitdiff;h=c42494acb2f7f31e561d38f06c59a50ee4198f36)
* switched wrmsr_safe() for wr{f,g}sbase(), neglecting to consider that they
* internally may use plain wrmsr() or the `wr{f,g}sbase` instructions, both
*
* @page test-xsa-194 XSA-194
*
- * Advisory: [XSA-194](http://xenbits.xen.org/xsa/advisory-194.html)
+ * Advisory: [XSA-194](https://xenbits.xen.org/xsa/advisory-194.html)
*
* When a guest requests BSD_SYMTAB, Some versions of libelf use a packed
* struct containing an Elf header, and three Section headers. These headers
*
* @page test-xsa-195 XSA-195
*
- * Advisory: [XSA-195](http://xenbits.xen.org/xsa/advisory-195.html)
+ * Advisory: [XSA-195](https://xenbits.xen.org/xsa/advisory-195.html)
*
* The `bt` family of instructions can reference an arbitrary bit offset from
* their memory operand. The x86 instruction emulator accounts for this by
*
* @page test-xsa-196 XSA-196
*
- * Advisory: [XSA-196](http://xenbits.xen.org/xsa/advisory-196.html)
+ * Advisory: [XSA-196](https://xenbits.xen.org/xsa/advisory-196.html)
*
- * Xen change [36ebf14ebe](http://xenbits.xen.org/gitweb/
+ * Xen change [36ebf14ebe](https://xenbits.xen.org/gitweb/
* ?p=xen.git;a=commitdiff;h=36ebf14ebe60310aa22952cbb94de951c158437d)
* contained a bug when calculating the correct size of an IDT entry.
*
*
* @page test-xsa-200 XSA-200
*
- * Advisory: [XSA-200](http://xenbits.xen.org/xsa/advisory-200.html)
+ * Advisory: [XSA-200](https://xenbits.xen.org/xsa/advisory-200.html)
*
* Before XSA-200, the instruction emulator in Xen had a bug where it
* incorrectly honoured the legacy operand-side override prefix for
*
* @page test-xsa-203 XSA-203
*
- * Advisory: [XSA-203](http://xenbits.xen.org/xsa/advisory-203.html)
+ * Advisory: [XSA-203](https://xenbits.xen.org/xsa/advisory-203.html)
*
* Versions of Xen between 4.6 (when VMFUNC support was introduced) and
* XSA-203, would follow a NULL function pointer on non-Intel hardware.
*
* @page test-xsa-204 XSA-204
*
- * Advisory: [XSA-204](http://xenbits.xen.org/xsa/advisory-204.html)
+ * Advisory: [XSA-204](https://xenbits.xen.org/xsa/advisory-204.html)
*
* SYSCALL (unlike most instructions) evaluates its singlestep action based on
* the resulting EFLAGS.TF, not the starting EFLAGS.TF. As the @#DB is raised
*
* @page test-xsa-212 XSA-212
*
- * Advisory: [XSA-212](http://xenbits.xen.org/xsa/advisory-212.html)
+ * Advisory: [XSA-212](https://xenbits.xen.org/xsa/advisory-212.html)
*
* The XENMEM_exchange hypercall previously had incomplete checks on the
* safety of the parameters passed. XENMEM_exchange takes an input and output
*
* @page test-xsa-213 XSA-213
*
- * Advisory: [XSA-213](http://xenbits.xen.org/xsa/advisory-213.html)
+ * Advisory: [XSA-213](https://xenbits.xen.org/xsa/advisory-213.html)
*
* Before XSA-213, Xen would allow the use of __HYPERCALL_iret in a multicall.
* __HYPERCALL_iret switches the guest from kernel mode into user mode, but
*
* @page test-xsa-221 XSA-221
*
- * Advisory: [XSA-221](http://xenbits.xen.org/xsa/advisory-221.html)
+ * Advisory: [XSA-221](https://xenbits.xen.org/xsa/advisory-221.html)
*
- * The upstream change [fbbd5009e6](http://xenbits.xen.org/gitweb/
+ * The upstream change [fbbd5009e6](https://xenbits.xen.org/gitweb/
* ?p=xen.git;a=commitdiff;h=fbbd5009e6ed1201731b1727762070c1a988e67d)
* neglected to check that ports were suitably initialised before
* dereferencing their structure.
*
* @page test-xsa-224 XSA-224
*
- * Advisory: [XSA-224](http://xenbits.xen.org/xsa/advisory-224.html)
+ * Advisory: [XSA-224](https://xenbits.xen.org/xsa/advisory-224.html)
*
* XSA-224 has multiple CVEs assigned. This testcase exercises CVE-2017-10920
* specifically.
*
* @page test-xsa-227 XSA-227
*
- * Advisory: [XSA-227](http://xenbits.xen.org/xsa/advisory-xsa-227.html)
+ * Advisory: [XSA-227](https://xenbits.xen.org/xsa/advisory-xsa-227.html)
*
* For x86 PV guests, the #GNTTABOP_map_grant_ref hypercall allows mapping by
* nominated linear address, or by nominating a specific L1e. However, there
*
* @page test-xsa-231 XSA-231
*
- * Advisory: [XSA-231](http://xenbits.xen.org/xsa/advisory-231.html)
+ * Advisory: [XSA-231](https://xenbits.xen.org/xsa/advisory-231.html)
*
* Before XSA-231, the node parameter in xen_memory_reservation was passed
* unaudited into the heap allocator, which ASSERT()ed it was range, then
*
* @page test-xsa-232 XSA-232
*
- * Advisory: [XSA-232](http://xenbits.xen.org/xsa/advisory-232.html)
+ * Advisory: [XSA-232](https://xenbits.xen.org/xsa/advisory-232.html)
*
* GNTTABOP_cache_flush takes a machine address, looks up the page owner and
* unconditionally follows the owners grant table pointer. For system domains
*
* @page test-xsa-234 XSA-234
*
- * Advisory: [XSA-234](http://xenbits.xen.org/xsa/advisory-234.html)
+ * Advisory: [XSA-234](https://xenbits.xen.org/xsa/advisory-234.html)
*
* Various grant unmapping operations will succeed and drop a writeable
* reference count, even when the mapping was only read-only. This can be
*
* @page test-xsa-239 XSA-239
*
- * Advisory: [XSA-239](http://xenbits.xen.org/xsa/advisory-239.html)
+ * Advisory: [XSA-239](https://xenbits.xen.org/xsa/advisory-239.html)
*
* The IOAPIC REG_SELECT register is an 8bit register, which is expected to be
* accessed with 32bit accesses.
*
* @page test-xsa-255 XSA-255
*
- * Advisory: [XSA-255](http://xenbits.xen.org/xsa/advisory-255.html)
+ * Advisory: [XSA-255](https://xenbits.xen.org/xsa/advisory-255.html)
*
* The Grant Table v2 API has includes a set of status frames, which the guest
* is expected to map in addition to the regular grant frames. These frames
*
* @page test-xsa-259 XSA-259
*
- * Advisory: [XSA-259](http://xenbits.xen.org/xsa/advisory-259.html)
+ * Advisory: [XSA-259](https://xenbits.xen.org/xsa/advisory-259.html)
*
* The Meltdown mitigation work (XPTI) didn't correctly deal with an error
* path connecting the `int $0x80` special case handing with general exception
*
* @page test-xsa-260 XSA-260
*
- * Advisory: [XSA-260](http://xenbits.xen.org/xsa/advisory-260.html)
+ * Advisory: [XSA-260](https://xenbits.xen.org/xsa/advisory-260.html)
*
* The `mov` and `pop` instructions, when encoded with an @%ss destination
* register, set the `movss` shadow in hardware, which prevents
*
* @page test-xsa-261 XSA-261
*
- * Advisory: [XSA-261](http://xenbits.xen.org/xsa/advisory-261.html)
+ * Advisory: [XSA-261](https://xenbits.xen.org/xsa/advisory-261.html)
*
* Before XSA-261, Xen didn't implement IO-APIC interrupt routing for HPET
* timers properly, and attempting to configure a IRQ above the legacy PIC
*
* @page test-xsa-265 XSA-265
*
- * Advisory: [XSA-265](http://xenbits.xen.org/xsa/advisory-264.html)
+ * Advisory: [XSA-265](https://xenbits.xen.org/xsa/advisory-264.html)
*
* One of the fixes for
- * [XSA-260](http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=75d6828bc2146d0eea16adc92376951a310d94a7)
+ * [XSA-260](https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=75d6828bc2146d0eea16adc92376951a310d94a7)
* introduced logic to try and prevent livelocks of @#DB exceptions in
* hypervisor context. However, it failed to account for the fact that some
* %dr6 bits are sticky and never cleared by hardware.
*
* @page test-xsa-269 XSA-269
*
- * Advisory: [XSA-269](http://xenbits.xen.org/xsa/advisory-269.html)
+ * Advisory: [XSA-269](https://xenbits.xen.org/xsa/advisory-269.html)
*
* Before XSA-269, no reserved bit checking was performed for writes to
* MSR_DEBUGCTL. Branch Trace Store isn't virtualised, and must only be
*
* @page test-xsa-277 XSA-277
*
- * Advisory: [XSA-277](http://xenbits.xen.org/xsa/advisory-277.html)
+ * Advisory: [XSA-277](https://xenbits.xen.org/xsa/advisory-277.html)
*
* Before XSA-277, an error path in the P2M code left a spinlock held when the
* guest tried to remove a page which was already not present.
*
* @page test-xsa-278 XSA-278
*
- * Advisory: [XSA-278](http://xenbits.xen.org/xsa/advisory-278.html)
+ * Advisory: [XSA-278](https://xenbits.xen.org/xsa/advisory-278.html)
*
* Between
- * [ac6a4500b](http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ac6a4500b2bed47fa135afbf8e4caeb4b3df546d)
+ * [ac6a4500b](https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ac6a4500b2bed47fa135afbf8e4caeb4b3df546d)
* (Xen 4.9) and XSA-278, Xen incorrectly handled its concept of "in VMX
* mode", and allowed the use of the VT-x instructions before VMXON had
* completed.
*
* @page test-xsa-279 XSA-279
*
- * Advisory: [XSA-279](http://xenbits.xen.org/xsa/advisory-279.html)
+ * Advisory: [XSA-279](https://xenbits.xen.org/xsa/advisory-279.html)
*
* When `PCID` support was added to Xen to mitigate some of the performance
* hit from the Meltdown protection, Xen's internal TLB flushing changed from