similar to: [PATCH] x86: disable stack-protector for __restore_processor_state()

On Tue, Jul 14, 2020 at 02:08:36PM +0200, Joerg Roedel wrote: > From: Joerg Roedel <jroedel at suse.de> > > The code inserted by the stack protector does not work in the early > boot environment because it uses the GS segment, at least with memory > encryption enabled. Make sure the early code is compiled without this > feature enabled. > > Signed-off-by: Joerg

From: Joerg Roedel <jroedel at suse.de> The code inserted by the stack protector does not work in the early boot environment because it uses the GS segment, at least with memory encryption enabled. Make sure the early code is compiled without this feature enabled. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/Makefile | 4 ++++ 1 file changed, 4 insertions(+)

From: Joerg Roedel <jroedel at suse.de> The code inserted by the stack protector does not work in the early boot environment because it uses the GS segment, at least with memory encryption enabled. Make sure the early code is compiled without this feature enabled. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/Makefile | 4 ++++ 1 file changed, 4 insertions(+)

On Tue, Apr 28, 2020 at 11:28 AM Joerg Roedel <joro at 8bytes.org> wrote: > > From: Joerg Roedel <jroedel at suse.de> > > The code inserted by the stack protector does not work in the early > boot environment because it uses the GS segment, at least with memory > encryption enabled. Make sure the early code is compiled without this > feature enabled. > >

On Tue, Apr 28, 2020 at 11:28 AM Joerg Roedel <joro at 8bytes.org> wrote: > > From: Joerg Roedel <jroedel at suse.de> > > The code inserted by the stack protector does not work in the early > boot environment because it uses the GS segment, at least with memory > encryption enabled. Make sure the early code is compiled without this > feature enabled. > >

This patch updates the tboot tarfile used by the optional tboot-* build targets to be the latest one in the Trusted Boot SourceForge site. Please include this patch in 1.3. Joe # HG changeset patch # User Joseph Cihula <joseph.cihula@intel.com> # Date 1215027500 25200 # Node ID 1877486e4c371c9d3fe52671cdcb0a13feafefa7 # Parent 08f77df14cba8e2dfe580779bb9ca2f64e1ae0ae Update tboot tarfile

There is no need to include pv-guest only object files in a kernel not configured to support those. Move Xen's irq.o, xen-asm*.o and pv parts of entry_*.o into CONFIG_XEN_PV sections. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/entry/entry_32.S | 4 +++- arch/x86/entry/entry_64.S | 6 ++++-- arch/x86/xen/Makefile | 8 ++++---- 3 files changed, 11 insertions(+), 7

flight 10626 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/10626/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-multivcpu 16 guest-start.2 fail in 10623 REGR. vs. 10621 Tests which are failing intermittently (not blocking): test-amd64-i386-rhel6hvm-intel 4 xen-install fail

The new sboot module that performs the measured launch, for Intel(R) TXT support. Part c - use ''cat'' to concatenate the pieces Signed-off-by: Joseph Cihula <joseph.cihula@intel.com> Signed-off-by: Jimmy Wei <gang.wei@intel.com> Signed-off-by: Shane Wang <shane.wang@intel.com> Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>

Changes to Xen for Intel(r) TXT support. Signed-off-by: Joseph Cihula <joseph.cihula@intel.com <<txt-xen-0608_01-xen.patch>> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Attached and below are a patch that unifies the shutdown code paths in Xen, including those from EARLY_FAIL. This will facilitate the use of Intel(R) TXT for measured launch by ensuring that all shutdowns will call the necessary hook to tear down the measured environment. It also centralizes any future shutdown-related changes. The patch also postpones clearing the online status APs in

New versions of tboot support ACPI GAS (Generic Address Structure) for handling sleep states. This required a change to the tboot_shared_t data structure that is not backwards compatible. This patch requires that new version makes use of GAS when invoking tboot on shutdown. Signed-off-by: Shane Wang <shane.wang@intel.com> Signed-off-by: Joseph Cihula <joseph.cihula@intel.com> diff

This release features a dash sync to latest dash git (We continue in the tradition of providing the freshest dash), porter fixes for arm Debian and ppc64 Ubuntu. To the utils got added a minimal mv, so that /run initramfs content can be moved to the real rootfs. The shortlog is dominated by dash commits, plus usual minimal fixes. git repository: git://git.kernel.org/pub/scm/libs/klibc/klibc.git

XEN_DOM0 is a silent option that has been automatically selected when CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was changed to a menu configurable option then it would only give users the ability to compile out about 100 kbytes of code. As that option makes little sense to choose, and the option isn''t menu selectable anyway, then we can clean up some code by simply

XEN_DOM0 is a silent option that has been automatically selected when CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was changed to a menu configurable option then it would only give users the ability to compile out about 100 kbytes of code. As that option makes little sense to choose, and the option isn''t menu selectable anyway, then we can clean up some code by simply

XEN_DOM0 is a silent option that has been automatically selected when CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was changed to a menu configurable option then it would only give users the ability to compile out about 100 kbytes of code. As that option makes little sense to choose, and the option isn''t menu selectable anyway, then we can clean up some code by simply

Hey Stefano, I setup a cross ARM build system so that the generic changes won''t cause build issues on ARM (and actually caught a bug with fallback.o being enabled there - I''ve a fix for that). But more interestingly the build system I do also makes a variations of config entries. So there is the allmodules, allyes, allyes, but all Xen drivers are modules, etc. I found out that

It seems that xenstore watches do not work from domU userspace (they obviously do for drivers). In some preliminary debugging of this, there are two aspects of the failure: not sending the watch to xenstore and not handling watch events for userspace watches. The former can be easily fixed by adding the missing ''case XS_WATCH:'' to xenbus_dev_write() in xenbus_dev.c. The

This patch adds SMP support to the previous version. Since that has not been merged I have included it in this patch. This should apply cleanly to the tip. Below is the text of the original submittal, slightly updated. Attached is a preliminary patch that adds Intel(R) LaGrande Technology (LT) (Safer Mode Extensions - SMX) support to Xen. While there are still several enhancements needed for

Can someone provide instructions and the necessary environment/toolchain support needed to get Xen to build and boot on a native EFI system (i.e. with no CSM/legacy support)? Joe