Re: [Xen-devel] [PATCH 1/2] Add a kexec_crash_loaded() function
On Wed, Jul 13, 2016 at 02:19:55PM +0200, Petr Tesarik wrote:
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -95,6 +95,12 @@ int kexec_should_crash(struct task_struct *p)
> return 0;
> }
>
> +int kexec_crash_loaded(void)
> +{
> + return !!kexec_crash_image;
> +}
Nit: this function should return bool rather than int, since it
effectively returns true/false.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)
On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote: > On 09/11/15 21:30, Josh Triplett wrote: > > On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote: > >> Breaking Debian Wheezy's and BITS's GRUB is also bad, but the former is > >> very old (and has a clear upgrade path), while the latter is mainly used > >> by developers (who can learn about the -fw_cfg switch by googling or > >> asking on the least without huge trouble). In this case I'm leaning > >> towards OVMF being "bleeding edge" by default. But, I could be convinced > >> otherwise. > > > > I certainly think it makes sense for OVMF to adopt the feature sooner > > than normal, and I agree that OVMF serves as a test case. But going > > directly from "not possible to turn on" to "turned on by default", > > without any period of "off by default but possible to turn on", seems a > > bit unfortunate. > > > > That said, we could certainly fix BITS to use newer GRUB2, and use > > (and document) -fw_cfg in the meantime. So I won't push *too* hard for > > changing the default, just mildly. > > Okay. If I'll need to send a v2 for any reason, I'll incorporate this. > If not, then I can post a followup patch later (stating that it's due to > community feedback). Thanks! > > On a vaguely related note, what's the canonical place to report bugs in > > OVMF? > > (Bugs? What bugs? :)) > > It's this list, . There isn't a tracker of some kind? That's unfortunate. But thanks; I'll send mail to the list when we discover an issue while experimenting with BITS. (Also, if you don't intend to use github's issue tracker, you might want to turn it off so people don't file things there and expect a response.) - Josh Triplett ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)
On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote: > On 09/11/15 16:10, Josh Triplett wrote: > > On Fri, Sep 11, 2015 at 01:43:53PM +0200, Laszlo Ersek wrote: > >> On 09/09/15 12:48, Laszlo Ersek wrote: > >>> On 09/09/15 11:37, Ian Campbell wrote: > >>>> On Wed, 2015-09-09 at 01:06 -0600, Jan Beulich wrote: > >>>>>>>> On 09.09.15 at 00:23, wrote: > >>>>>> On 09/08/15 19:26, Anthony PERARD wrote: > >>>>>>> And I get this on the console: > >>>>>>> Welcome to GRUB! > >>>>>>> > >>>>>>> X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - > >>>>>>> > >>>>>>> RIP - 0F5F8918, CS - 0028, RFLAGS - > >>>>>>> 00210206 > >>>>>>> ExceptionData - 0011 > >>>>>>> RAX - , RCX - 07FCE000, RDX - > >>>>>>> > >>>>>>> RBX - 0B6092C0, RSP - 0F5F8590, RBP - > >>>>>>> 0B608EA0 > >>>>>>> RSI - 0F5F8838, RDI - 0B608EA0 > >>>>>>> R8 - , R9 - 0B609200, R10 - > >>>>>>> > >>>>>>> R11 - 000A, R12 - , R13 - > >>>>>>> 001B > >>>>>>> R14 - 0B609360, R15 - > >>>>>>> DS - 0008, ES - 0008, FS - > >>>>>>> 0008 > >>>>>>> GS - 0008, SS - 0008 > >>>>>>> CR0 - 8033, CR2 - 0F5F8918, CR3 - > >>>>>>> 0F597000 > >>>>>>> CR4 - 0668, CR8 - > >>>>>>> DR0 - , DR1 - , DR2 - > >>>>>>> > >>>>>>> DR3 - , DR6 - 0FF0, DR7 - > >>>>>>> 0400 > >>>>>>> GDTR - 0F57BF18 003F, LDTR - > >>>>>>> IDTR - 0EEA5018 0FFF, TR - > >>>>>>> FXSAVE_STATE - 0F5F81F0 > >>>>>>> Find PE image > >>>>>> /build/xen-unstable/src/xen-unstable/tools/firmware/ovmf-dir > >>>>>> -remote/Build > >>>>>> /OvmfX64/DEBUG_GCC49/X64/IntelFrameworkModulePkg/Universal/StatusCode/R > >>>>>> untime > >>>>>> Dxe/StatusCodeRuntimeDxe/DEBUG/StatusCodeRuntimeDxe.dll > >>>>>> (ImageBase=0F556000, EntryPoint=0F55628F) > >>>>>>> > >>>>>>> I did check with other guest (Windows, Ubuntu, Debian Jessie), and > >>>>>>> they are > >>>>>>> working correctly. Debian Wheezy is the only one that fail. > >>>>>> > >>>>>> I don't have an environment to reproduce this in. I think we should try > >>>>>> to understand this problem better, before deciding how to make it go > >>>>>> away. > >>>>>> > >>>>>> Please locate the "StatusCodeRuntimeDxe.debug" file in your Build > >>>>>> directory (ie. under the location listed in the error report). Then, > >>>>>> please disassemble it with "objdump -S". The fault location in the > >>>>>> disassembly can be found based on RIP, ImageBase and EntryPoint; > >>>>> > >>>>> I don't think the exact instruction at that address really matters. The > >>>>> main question appears to be why RIP and RSP both point into the > >>>>> same page (see also the subject of Anthony's mail). > >>>> > >>>> I'm not 100% what is going on, > >>> > >>> me neither :) > >>> > >>>> but if this (executable code on stack) is > >>>> happening in grub is there something which is explicitly forbidden to > >>>> UEFI > >>>> apps by the UEFI spec? > >>> > >>> Yes, there is. This small OvmfPkg patch only enables the edk2 fe
Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)
no changes for QEMU would be necessary. Xen virtual machines > > don't have fw_cfg however, therefore "some other" info passing should > > be implemented in "OvmfPkg/PlatformPei/Xen.c", and (I assume!) in the > > host-side Xen tools as well. > > > > Personally I think that this dynamic approach is overkill (mainly > > because I'm fine with being unable to install Debian Wheezy guests, both > > wearing and not wearing my red fedora; and because the properties table > > feature is not active for *any* OVMF guests anyway, in practice). > > > > So I'd like to ask you guys to decide which one you prefer: a simple > > build time flag called NX_STACK_ENABLE (which will allow you to install > > Wheezy guests, but deprive all other guests from a non-exec stack), or > > the dynamic switches (which will take host-side work in Xen, plus a > > matching OvmfPkg patch). > > I might go ahead and implement the -fw_cfg solution (for when OVMF runs > on QEMU), leaving any parallel Xen functionality to Xen developers, for > later. > > Because, I just found out that the GRUB binary built into the bits-2005 > release ISO <http://biosbits.org/download/> blows up the exact same way, > and *that* is very annoying to me personally. > > Maybe we should invert the default. I'm not so convinced any longer that > the current default is right. I didn't know that the GRUB version with > code on the stack was this wide-spread. Heh. Our fault for still using old (2.00) GRUB2, which we do plan to upgrade at some point, though doing so doesn't top the TODO list. But I do agree that with OVMF not having previously enforced NX in the UEFI environment, going from that to immediately enforcing it *by default* seems a bit quick. I would be surprised if doing so didn't break other UEFI programs too. Could OVMF build with NX support available, but disabled by default, so that qemu can then turn it *on* with a -fw_cfg option? Do any UEFI stacks on systems in the wild have NX turned on? I don't think it makes sense for OVMF to enable NX by default until a majority of new physical systems do so. - Josh Triplett ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86, platform, xen, kconfig: clarify kvmconfig is for kvm
On Tue, Dec 09, 2014 at 03:35:37PM -0800, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > We'll be adding options for xen as well. > > Cc: Josh Triplett > Cc: Borislav Petkov > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Michal Marek > Cc: Randy Dunlap > Cc: penb...@kernel.org > Cc: levinsasha...@gmail.com > Cc: mtosa...@redhat.com > Cc: fengguang...@intel.com > Cc: David Vrabel > Cc: Ian Campbell > Cc: Konrad Rzeszutek Wilk > Cc: xen-de...@lists.xenproject.org > Acked-by: David Rientjes > Acked-by: Borislav Petkov > Signed-off-by: Luis R. Rodriguez Reviewed-by: Josh Triplett > scripts/kconfig/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile > index 9645c07..ff612b0 100644 > --- a/scripts/kconfig/Makefile > +++ b/scripts/kconfig/Makefile > @@ -141,7 +141,7 @@ help: > @echo ' randconfig - New config with random answer to all > options' > @echo ' listnewconfig - List new options' > @echo ' olddefconfig- Same as silentoldconfig but sets new > symbols to their default value' > - @echo ' kvmconfig - Enable additional options for guest kernel > support' > + @echo ' kvmconfig - Enable additional options for kvm guest > kernel support' > @echo ' tinyconfig - Configure the tiniest possible kernel' > > # lxdialog stuff > -- > 2.1.1 > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 0/2]: x86/arm64: add xenconfig
On Mon, Dec 08, 2014 at 03:04:58PM -0800, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > This is based on some old set I had lying around. The virtconfig > changes I had proposed a while ago got merged and reused for > tinyconfig, this adapts my original set to use the new mergeconfig. > > Not sure who's tree this should go through, last time these were > lost in space and only the non-xen things got cherry picked later, > who's tree should this go through? > > Luis R. Rodriguez (2): > x86, platform, xen, kconfig: clarify kvmconfig is for kvm > x86, arm, platform, xen, kconfig: add xen defconfig helper For both: Reviewed-by: Josh Triplett > arch/x86/configs/xen.config | 6 ++ > kernel/configs/xen.config | 32 > scripts/kconfig/Makefile| 7 ++- > 3 files changed, 44 insertions(+), 1 deletion(-) > create mode 100644 arch/x86/configs/xen.config > create mode 100644 kernel/configs/xen.config > > -- > 2.1.1 > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
