From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues Date: Fri, 30 Jan 2015 16:41:32 +0000 Message-ID: <54CBC24C020000780005B7A1@mail.emea.novell.com> References: <20150128161744.GB3473@olila.local.net-space.pl> <54C922B2020000780005A79A@mail.emea.novell.com> <20150128172045.GB7189@l.oracle.com> <54CA1AEC020000780005AAD0@mail.emea.novell.com> <20150130141727.GC4506@l.oracle.com> <54CB97EE.1050702@citrix.com> <20150130145200.GA6221@l.oracle.com> <54CB9BDC.9090102@citrix.com> <20150130150955.GA29167@olila.local.net-space.pl> <54CBB28B020000780005B6F6@mail.emea.novell.com> <20150130162411.GB29167@olila.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YHEdR-0007Ho-H5 for xen-devel@lists.xenproject.org; Fri, 30 Jan 2015 16:41:33 +0000 In-Reply-To: <20150130162411.GB29167@olila.local.net-space.pl> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel Kiper Cc: Andrew Cooper , David Vrabel , xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 30.01.15 at 17:24, wrote: > On Fri, Jan 30, 2015 at 03:34:19PM +0000, Jan Beulich wrote: >> >>> On 30.01.15 at 16:09, wrote: >> > I suppose that we should provide additional kexec hypercall >> > function which will return info about RS. kexec-tools should >> > load new kernel as usual and add relevant argument to its >> > command line. Most things are in place so we should just >> > learn kexec-tools to do new things. >> >> There is a reason why the RS table info can't currently be >> obtained via a hypercall - Dom0 has nothing to do with it. Plus any >> kexec-ed kernel (Linux or other) will, under EFI, want this >> information, so a mechanism by which to pass the information to >> the secondary kernel without exposing it to entities not having a >> need to know would be preferable (albeit I have no idea so far >> how that might look like). > > Currently, anybody able to use HYPERVISOR_memory_op hypercall on dom0 > is able to get full machine memory map. So, what is the problem with > exposing more details about RS? Do you think about security? I suppose > that we expose to dom0 other hardware details which potentially could > be used in malicious way and RS details exposure will not undermine > our security so strong. I'm not seeing what the exposure of the machine memory map has to do with the RS table. Anyway - my concern isn't a malicious consumer, but an ignorant one (e.g. then trying to make runtime calls directly from Dom0). >> Plus, this still doesn't in any way deal with the aspect that was >> so far discussed in this thread - SetVirtualAddressMap() being >> callable only once. > > Well, we must live with it because this is part of UEFI spec. Or change > UEFI spec. Still thinking why spec does not allow OS do this operation > more then once. OTH, Konrad pointed out a solution (workaround) for this > issue used in Linux which seems sensible and could be used by us too. Like Konrad, you're thinking too Linux-centric here: Yes, a Linux- specific workaround is possible, but a finding a proper generic solution would be much better. And a very obvious one is: Don't call SetVirtualAddressMap() when you may want to kexec. Jan