From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Kiper 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 17:24:11 +0100 Message-ID: <20150130162411.GB29167@olila.local.net-space.pl> 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> 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 1YHEMr-0005NT-ME for xen-devel@lists.xenproject.org; Fri, 30 Jan 2015 16:24:25 +0000 Content-Disposition: inline In-Reply-To: <54CBB28B020000780005B6F6@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andrew Cooper , David Vrabel , xen-devel List-Id: xen-devel@lists.xenproject.org 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. > 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. Daniel