[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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |