Re: [Xen-devel] Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Fri, Jan 30, 2015 at 03:34:19PM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 16:09, <daniel.kiper@xxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel