lkml.org 
[lkml]   [2013]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation
    Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> writes:

    > On Thu, Jan 10, 2013 at 08:16:48PM -0800, Eric W. Biederman wrote:

    >> The basic kexec interface is.
    >>
    >> load ranges of virtual addresses physical addresses.
    >> jump to the physical address with identity mapped page tables.
    >>
    >> There are a few flags to allow for different usage scenarios like
    >> kexec on panic vs normal kexec.
    >
    > And there is nothing fancy to be done for EFI and SecureBoot?

    There is a mess with EFI. Reports are that EFI is a bug ridden pile,
    and people keep advocating that we make more and more EFI calls in the
    main kernel. There is an argument over set_virtual_mapping, which is a
    call that can be made only once which relocates the EFI code to a
    different address, which makes life inconvient for kexec. There is
    another argument that EFI doesn't actually work if you don't make the
    set_virtual_mapping call so we can't remove it and always use physical
    addresses.

    Frankly the only sane way to run a linux kernel under EFI is to scrape
    up the information needed to talk to the hardware directly and ignore
    EFI. That is what we have historically done in the face of BIOS madness
    and if anything the situation is worse with EFI, but it looks like we
    are going to have to learn that the hard way.

    Recently there is a desire to figure out how to /sbin/kexec support
    signed kernel images. What will probably happen is to have a specially
    trusted userspace application perform the verification. Sort of like
    dom0 for the linux userspace. A few other ideas have been batted around
    but none that have stuck.

    None of that is really about SecureBoot. It is all trusting the kernel
    binary but not trusting userspace. With SecureBoot being an excuse for
    coming up with a policy like that.

    It looks like the answer to SecureBoot at this point may simply be just
    reconfigure your BIOS or root Windows and EFI to get the hardware to do
    what you want.

    So the answer for looking forward for Xen dom0 is: A trusted /sbin/kexec
    won't require changes. The other suggest solution is a flag that says a
    specific chunk of the loaded image is a signature that the magic trust
    faires can verify. As long as you have a flag bit free you should be
    able to implement that policy if we ever implement it.

    Eric


    \
     
     \ /
      Last update: 2013-01-11 22:01    [W:4.084 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site