[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 30.01.15 at 17:24, <daniel.kiper@xxxxxxxxxx> wrote:
> 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.

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.