{"push_id":1428678368,"size":35,"distinct_size":35,"ref":"refs/heads/master","head":"99a10da1b4fee8ef7a096e5fd3608f6c15932eb0","before":"d4e202c39f0e464dfcec0e28f56725d516e190c6","commits":[{"sha":"60409f690482eaa34d285aa9c070afa0e5bc7f61","author":{"name":"Boris Ostrovsky","email":"8d8eed10c3f35eaa3a548daad1882614e248ed99@oracle.com"},"message":"tools/libacpi: Re-licence remaining GPL code to LGPLv2.1\n\nWe now have permission from Lenovo to relicense commit 801d469ad8b2\n(\"[HVM] ACPI support patch 3 of 4: ACPI _PRT table\") to LGPLv2.1\n\nThis essentially means reverting commits c3397311a658 (\"acpi: Prevent\nGPL-only code from seeping into non-GPL binaries\") and 26c4f0b8a4cf\n(\"tools/libacpi: fix sed usage\")\n\nSigned-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nAcked-by: Ken Lancaster <klancaster@lenovo.com>\nReviewed-by: Wei Liu <wei.liu2@citrix.com>\nAcked-by: Jan Beulich <jbeulich@suse.com>\nRelease-acked-by: Wei Liu <wei.liu2@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/60409f690482eaa34d285aa9c070afa0e5bc7f61"},{"sha":"632ff7847a398a9d0de988633cfe180e5116ec32","author":{"name":"Ian Jackson","email":"1203c8228d8d538986d539e24661885d0473fbb1@citrix.com"},"message":"tools/configure: Drop -lcrypto search\n\nThis seems to be looking for a function MD5.  But nothing uses it.\nThe build works fine if this is disabled and libcrypto is not\ninstalled.\n\nThis check was first introduced in 68a3e1e87325 \"[TOOLS] Add more\nchecks for devel packages.\" in 2006.  At that time -lcrypto was used\nby tools/blktap/ and tools/vtpm_manager/, which are both gone now.\n\nSigned-off-by: Ian Jackson <ian.jackson@citrix.com>\nAcked-by: Wei Liu <wei.liu2@citrix.com>\nRelease-acked-by: Wei Liu <wei.liu2@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/632ff7847a398a9d0de988633cfe180e5116ec32"},{"sha":"fcb618c025f9251d7e22138f6528595037252c21","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/vmx: Correct the long mode check in vmx_cpuid_intercept()\n\n%cs.L may be set in a legacy mode segment, or clear in a compatibility mode\nsegment; it is not the correct way to check for long mode being active.\n\nBoth of these situations result in incorrect visibility of the SYSCALL feature\nin CPUID, and by extension, incorrect behaviour in hvm_efer_valid().\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <JBeulich@suse.com>\nAcked-by: Kevin Tian <kevin.tian@intel.com>\nRelease-acked-by: Wei Liu <wei.liu2@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/fcb618c025f9251d7e22138f6528595037252c21"},{"sha":"0f43883193da76fc928e836e319c3172f394e0f3","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/traps: Don't call hvm_hypervisor_cpuid_leaf() for PV guests\n\nLuckily, hvm_hypervisor_cpuid_leaf() and vmx_hypervisor_cpuid_leaf() are safe\nto execute in the context of a PV guest, but HVM-specific feature flags\nshouldn't be visible to PV guests.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nRelease-acked-by: Wei Liu <wei.liu2@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/0f43883193da76fc928e836e319c3172f394e0f3"},{"sha":"160e12899212f6f666fe38781fc5911fe9f8ad35","author":{"name":"Boris Ostrovsky","email":"8d8eed10c3f35eaa3a548daad1882614e248ed99@oracle.com"},"message":"tools/libacpi: Be specific about which DSDT files to build\n\nThere is no reason to build, for example, dsdt_pvh.asl for hvmloader. We\npass which DSDTs to build via DSDT_FILES parameter.\n\nIf DSDT_FILES is empty all DSDTs for a particular architecture will be built.\n\nSigned-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nAcked-by: Jan Beulich <jbeulich@suse.com>\nRelease-acked-by: Wei Liu <wei.liu2@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/160e12899212f6f666fe38781fc5911fe9f8ad35"},{"sha":"58bd0c7985890e0292212f94a56235228a3445c3","author":{"name":"David Vrabel","email":"0622fb2836634876d1b2a72d98e1723882d22bb8@citrix.com"},"message":"MAINTAINERS: update EVENT CHANNEL and KEXEC maintainer\n\nI am no longer in a position to be a Xen maintainer.  Andrew has\nkindly volunteered to continue maintainance of the KEXEC subsystem.\nEVENT CHANNELS (FIFO-BASED ABI) will be maintained by the \"Other\"\nhypervisor maintainers.\n\nSigned-off-by: David Vrabel <david.vrabel@citrix.com>\nAcked-by: Andrew Cooper <andrew.cooper3@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/58bd0c7985890e0292212f94a56235228a3445c3"},{"sha":"0745f665a575bdb6724f6ec1ab767cd71ba8c253","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/svm: Fix svm_nextrip_insn_length() when crossing the virtual boundary to 0\n\nvmcb->nextrip can legitimately be less than vmcb->rip when execution wraps\nback around to 0.  Instead, complain if the reported length is greater than 15\nand use x86_decode_insn() as a fallback.\n\nWhile making changes here, fix two whitespace issues with the case labels.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nReviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nRelease-acked-by: Wei Liu <wei.liu2@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/0745f665a575bdb6724f6ec1ab767cd71ba8c253"},{"sha":"f678e2c78110e73431217306bbd33c736802d700","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/hvm: Fix non-debug build folling c/s 0745f665a5\n\nThe variable is named inst_len, not insn_len.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nRelease-acked-by: Wei Liu <wei.liu2@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/f678e2c78110e73431217306bbd33c736802d700"},{"sha":"04beafa8e6c66f5cd814c00e2d2b51cfbc41cb8a","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/hvm: Fix the handling of non-present segments\n\nIn 32bit, the data segments may be NULL to indicate that the segment is\nineligible for use.  In both 32bit and 64bit, the LDT selector may be NULL to\nindicate that the entire LDT is ineligible for use.  However, nothing in Xen\nactually checks for this condition when performing other segmentation\nchecks.  (Note however that limit and writeability checks are correctly\nperformed).\n\nNeither Intel nor AMD specify the exact behaviour of loading a NULL segment.\nExperimentally, AMD zeroes all attributes but leaves the base and limit\nunmodified.  Intel zeroes the base, sets the limit to 0xfffffff and resets the\nattributes to just .G and .D/B.\n\nThe use of the segment information in the VMCB/VMCS is equivalent to a native\npipeline interacting with the segment cache.  The present bit can therefore\nhave a subtly different meaning, and it is now cooked to uniformly indicate\nwhether the segment is usable or not.\n\nGDTR and IDTR don't have access rights like the other segments, but for\nconsistency, they are treated as being present so no special casing is needed\nelsewhere in the segmentation logic.\n\nAMD hardware does not consider the present bit for %cs and %tr, and will\nfunction as if they were present.  They are therefore unconditionally set to\npresent when reading information from the VMCB, to maintain the new meaning of\nusability.\n\nIntel hardware has a separate unusable bit in the VMCS segment attributes.\nThis bit is inverted and stored in the present field, so the hvm code can work\nwith architecturally-common state.\n\nThis is CVE-2016-9386 / XSA-191.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/04beafa8e6c66f5cd814c00e2d2b51cfbc41cb8a"},{"sha":"93aa42b85ae0084ba7b749d0e990c94fbf0c17e3","author":{"name":"Jan Beulich","email":"ae7900a0c785918fc3eaa9d1a92a76bc4e651ece@suse.com"},"message":"x86/HVM: don't load LDTR with VM86 mode attrs during task switch\n\nJust like TR, LDTR is purely a protected mode facility and hence needs\nto be loaded accordingly. Also move its loading to where it\narchitecurally belongs.\n\nThis is CVE-2016-9382 / XSA-192.\n\nSigned-off-by: Jan Beulich <jbeulich@suse.com>\nReviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>\nTested-by: Andrew Cooper <andrew.cooper3@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/93aa42b85ae0084ba7b749d0e990c94fbf0c17e3"},{"sha":"f3fa3abf3e61fb1f25ce721e14ac324dda67311f","author":{"name":"Jan Beulich","email":"ae7900a0c785918fc3eaa9d1a92a76bc4e651ece@suse.com"},"message":"x86/PV: writes of %fs and %gs base MSRs require canonical addresses\n\nCommit c42494acb2 (\"x86: fix FS/GS base handling when using the\nfsgsbase feature\") replaced the use of wrmsr_safe() on these paths\nwithout recognizing that wr{f,g}sbase() use just wrmsrl() and that the\nWR{F,G}SBASE instructions also raise #GP for non-canonical input.\n\nSimilarly arch_set_info_guest() needs to prevent non-canonical\naddresses from getting stored into state later to be loaded by context\nswitch code. For consistency also check stack pointers and LDT base.\nDR0..3, otoh, already get properly checked in set_debugreg() (albeit\nwe discard the error there).\n\nThe SHADOW_GS_BASE check isn't strictly necessary, but I think we\nbetter avoid trying the WRMSR if we know it's going to fail.\n\nThis is CVE-2016-9385 / XSA-193.\n\nReported-by: Andrew Cooper <andrew.cooper3@citrix.com>\nSigned-off-by: Jan Beulich <jbeulich@suse.com>\nReviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/f3fa3abf3e61fb1f25ce721e14ac324dda67311f"},{"sha":"fb08f7d009a64b96efa4462c9d19ed6881936859","author":{"name":"Roger Pau Monné","email":"5f4729e48ff357e9d43c7533050665e737ae6983@citrix.com"},"message":"libelf: fix stack memory leak when loading 32 bit symbol tables\n\nThe 32 bit Elf structs are smaller than the 64 bit ones, which means that\nwhen loading them there's some padding left uninitialized at the end of each\nstruct (because the size indicated in e_ehsize and e_shentsize is\nsmaller than the size of elf_ehdr and elf_shdr).\n\nFix this by introducing a new helper that is used to set\n[caller_]xdest_{base/size} and that takes care of performing the appropriate\nmemset of the region. This newly introduced helper is then used to set and\nunset xdest_{base/size} in elf_load_bsdsyms. Now that the full struct\nis zeroed, there's no need to specifically zero the undefined section.\n\nThis is CVE-2016-9384 / XSA-164.\n\nSuggested-by: Ian Jackson <ian.jackson@eu.citrix.com>\nSigned-off-by: Roger Pau Monné <roger.pau@citrix.com>\n\nAlso remove the open coded (and redundant with the earlier\nelf_memset_unchecked()) use of caller_xdest_* from elf_init().\n\nSigned-off-by: Jan Beulich <jbeulich@suse.com>\nSigned-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/fb08f7d009a64b96efa4462c9d19ed6881936859"},{"sha":"1c6c2d60d205f71ede0fbbd9047e459112f576db","author":{"name":"Jan Beulich","email":"ae7900a0c785918fc3eaa9d1a92a76bc4e651ece@suse.com"},"message":"x86emul: fix huge bit offset handling\n\nWe must never chop off the high 32 bits.\n\nThis is CVE-2016-9383 / XSA-195.\n\nReported-by: George Dunlap <george.dunlap@citrix.com>\nSigned-off-by: Jan Beulich <jbeulich@suse.com>\nReviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/1c6c2d60d205f71ede0fbbd9047e459112f576db"},{"sha":"255e8fe95f22ded5186fd75244ffcfb9d5dbc855","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/emul: correct the IDT entry calculation in inject_swint()\n\nThe logic, as introduced in c/s 36ebf14ebe \"x86/emulate: support for emulating\nsoftware event injection\" is buggy.  The size of an IDT entry depends on long\nmode being active, not the width of the code segment currently in use.\n\nIn particular, this means that a compatibility code segment which hits\nemulation for software event injection will end up using an incorrect offset\nin the IDT for DPL/Presence checking.  In practice, this only occurs on old\nAMD hardware lacking NRip support; all newer AMD hardware, and all Intel\nhardware bypass this path in the emulator.\n\nWhile here, fix a minor issue with reading the IDT entry.  The return value\nfrom ops->read() wasn't checked, but in reality the only failure case is if a\npagefault occurs.  This is not a realistic problem as the kernel will almost\ncertainly crash with a double fault if this setup actually occured.\n\nThis is CVE-2016-9377 / part of XSA-196.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/255e8fe95f22ded5186fd75244ffcfb9d5dbc855"},{"sha":"920edccd41db6cb0145545afa1850edf5e7d098e","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/svm: fix injection of software interrupts\n\nThe non-NextRip logic in c/s 36ebf14eb \"x86/emulate: support for emulating\nsoftware event injection\" was based on an older version of the AMD software\nmanual.  The manual was later corrected, following findings from that series.\n\nI took the original wording of \"not supported without NextRIP\" to mean that\nX86_EVENTTYPE_SW_INTERRUPT was not eligible for use.  It turns out that this\nis not the case, and the new wording is clearer on the matter.\n\nDespite testing the original patch series on non-NRip hardware, the\nswint-emulation XTF test case focuses on the debug vectors; it never ended up\nexecuting an `int $n` instruction for a vector which wasn't also an exception.\n\nDuring a vmentry, the use of X86_EVENTTYPE_HW_EXCEPTION comes with a vector\ncheck to ensure that it is only used with exception vectors.  Xen's use of\nX86_EVENTTYPE_HW_EXCEPTION for `int $n` injection has always been buggy on AMD\nhardware.\n\nFix this by always using X86_EVENTTYPE_SW_INTERRUPT.\n\nPrint and decode the eventinj information in svm_vmcb_dump(), as it has\nseveral invalid combinations which cause vmentry failures.\n\nThis is CVE-2016-9378 / part of XSA-196.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/920edccd41db6cb0145545afa1850edf5e7d098e"},{"sha":"27e14d346ed6ff1c3a3cfc479507e62d133e92a9","author":{"name":"Ian Jackson","email":"1203c8228d8d538986d539e24661885d0473fbb1@eu.citrix.com"},"message":"pygrub: Properly quote results, when returning them to the caller:\n\n* When the caller wants sexpr output, use `repr()'\n  This is what Xend expects.\n\n  The returned S-expressions are now escaped and quoted by Python,\n  generally using '...'.  Previously kernel and ramdisk were unquoted\n  and args was quoted with \"...\" but without proper escaping.  This\n  change may break toolstacks which do not properly dequote the\n  returned S-expressions.\n\n* When the caller wants \"simple\" output, crash if the delimiter is\n  contained in the returned value.\n\n  With --output-format=simple it does not seem like this could ever\n  happen, because the bootloader config parsers all take line-based\n  input from the various bootloader config files.\n\n  With --output-format=simple0, this can happen if the bootloader\n  config file contains nul bytes.\n\nThis is CVE-2016-9379 and CVE-2016-9380 / XSA-198.\n\nSigned-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>\nTested-by: Ian Jackson <Ian.Jackson@eu.citrix.com>\nReviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/27e14d346ed6ff1c3a3cfc479507e62d133e92a9"},{"sha":"f6b7fedc896250028cb81dafe9a3f6773aaf1da2","author":{"name":"Jan Beulich","email":"ae7900a0c785918fc3eaa9d1a92a76bc4e651ece@suse.com"},"message":"x86/EFI: meet further spec requirements for runtime calls\n\nSo far we didn't guarantee 16-byte alignment of the stack: While (so\nfar) we don't tell the compiler to use smaller alignment, we also don't\nguarantee 16-byte alignment when establishing stack pointers for new\nvCPU-s. Runtime service functions using SSE instructions may end with\n#GP(0) without that.\n\nNote that making use of -mpreferred-stack-boundary=3, as mentioned in\nthe comment, wouldn't help to reduce the needed alignment: The compiler\nwould then be free to align the stack of the function with the aligned\nobject, but would be permitted to place an odd number of 8-byte objects\nthere, resulting in the callee to still run on an unaligned stack.\n\n(The only working alternative to the approach chosen here would be to\nuse -mincoming-stack-boundary=3, but that would affect all functions in\nruntime.c, not just the ones actually making runtime services calls.\nAnd it would still require the manual alignment logic here to be used\nwith gcc 5.2 and earlier - not permitting that command line option -,\njust that then the alignment amount would become conditional.)\n\nHence enforce the needed alignment by making efi_rs_enter() return a\nsuitably aligned structure, which the caller then necessarily has to\nstore in a suitably aligned local variable, the address of which then\ngets passed to efi_rs_leave(). Also (to limit exposure) move the\nfunction declarations to where they belong: They're local to runtime.c,\nand shared only with compat.c (by the latter including the former).\n\nFurthermore we should avoid #MF to be raised on the FLDCW we do.\n\nSigned-off-by: Jan Beulich <jbeulich@suse.com>\nAcked-by: Andrew Cooper <andrew.cooper3@citrix.com>\nRelease-acked-by: Wei Liu <wei.liu2@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/f6b7fedc896250028cb81dafe9a3f6773aaf1da2"},{"sha":"1d7ecc0348741543cbfec96d4817531efcf755c3","author":{"name":"Dario Faggioli","email":"236d95f5efad1b83a719674bae474fb1e14482b2@citrix.com"},"message":"credit2: fix wrong assert in runq_tickle()\n\nSince b047f888d489 (\"xen: sched: leave CPUs doing tasklet\nwork alone\") a cpu executing a tasklet, is not marked as\nidle.\n\nTherefore:\n - avoid asserting that we can't find the idle vcpu running\n   on one of them, which is not true,\n - avoid triggering a preemption on them (and add an assert\n   checking that).\n\nThis fixes a bug identified by OSSTest, in flight 102372\n(on ARM, but it's not at all ARM specific), where the\nASSERT() was triggering like this:\n\n(XEN) Xen call trace:\n(XEN)    [<0022af78>] sched_credit2.c#runq_tickle+0x3e8/0x61c (PC)\n(XEN)    [<0022aedc>] sched_credit2.c#runq_tickle+0x34c/0x61c (LR)\n(XEN)    [<0022b644>] sched_credit2.c#csched2_context_saved+0x128/0x1a4\n(XEN)    [<0023303c>] context_saved+0x7c/0xa4\n(XEN)    [<0024f660>] domain.c#schedule_tail+0x2b4/0x308\n(XEN)    [<0024faac>] context_switch+0x80/0x94\n(XEN)    [<0022ff48>] schedule.c#schedule+0x76c/0x7ec\n(XEN)    [<002338d4>] softirq.c#__do_softirq+0xcc/0xec\n(XEN)    [<00233968>] do_softirq+0x18/0x28\n(XEN)    [<00261084>] leave_hypervisor_tail+0x58/0x88\n(XEN)    [<002649d0>] entry.o#return_to_guest+0xc/0xb8\n(XEN)\n(XEN) ****************************************\n(XEN) Panic on CPU 1:\n(XEN) Assertion '!is_idle_vcpu(cur->vcpu)' failed at sched_credit2.c:1009\n(XEN) ****************************************\n\nSigned-off-by: Dario Faggioli <dario.faggioli@citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nRelease-acked-by: Wei Liu <wei.liu2@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/1d7ecc0348741543cbfec96d4817531efcf755c3"},{"sha":"986f790e0184d4bf575462077378e14fa9f85aa9","author":{"name":"Jan Beulich","email":"ae7900a0c785918fc3eaa9d1a92a76bc4e651ece@suse.com"},"message":"x86/memshr: properly check grant references\n\nThey need to be range checked against the current table limit in any\nevent.\n\nReported-by: Huawei PSIRT <psirt@huawei.com>\n\nMove the code to where it belongs, eliminating a number of duplicate\ndefinitions. Add locking. Produce proper error codes, and consume them\ninstead of making one up. Check grant type. Convert parameter types at\nonce.\n\nSigned-off-by: Jan Beulich <jbeulich@suse.com>\nReviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>\nAcked-by: Tamas K Lengyel <tamas@tklengyel.com>\nRelease-acked-by: Wei Liu <wei.liu2@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/986f790e0184d4bf575462077378e14fa9f85aa9"},{"sha":"e5745b86e6e114f0e5b15bf67ed8d37a3d019f66","author":{"name":"Roger Pau Monne","email":"5f4729e48ff357e9d43c7533050665e737ae6983@citrix.com"},"message":"libelf: fix symtab/strtab loading for 32bit domains\n\nCommit ed04ca introduced a bug in the symtab/strtab loading for 32bit\nguests, that corrupted the section headers array due to the padding\nintroduced by the elf_shdr union.\n\nThe Elf section header array on 32bit should be accessible as an array of\nElf32_Shdr elements, and the union with Elf64_Shdr done in elf_shdr was\nbreaking this due to size differences between Elf32_Shdr and Elf64_Shdr.\n\nFix this by copying each section header one by one, and using the proper\nsize depending on the bitness of the guest kernel. While there, also fix\na couple of consistency issues, by making sure we always use the sizes of\nour local versions of the ELF header and the ELF sections headers.\n\nReported-by: Brian Marcotte <marcotte@panix.com>\nSigned-off-by: Roger Pau Monné <roger.pau@citrix.com>\nAcked-by: Ian Jackson <ian.jackson@eu.citrix.com>\nReviewed-by: Jan Beulich <jbeulich@suse.com>\nRelease-acked-by: Wei Liu <wei.liu2@citrix.com>","distinct":true,"url":"https://api.github.com/repos/tklengyel/xen/commits/e5745b86e6e114f0e5b15bf67ed8d37a3d019f66"}]}
{"actor":{"display_login":"tklengyel"}}