28 Jan, 2015

1 commit

  • Commits 65cef1311d5d ("x86, microcode: Add a disable chicken bit") and
    a18a0f6850d4 ("x86, microcode: Don't initialize microcode code on
    paravirt") allow microcode driver skip initialization when microcode
    loading is not permitted.

    However, they don't prevent the driver from being loaded since the
    init code returns 0. If at some point later the driver gets unloaded
    this will result in an oops while trying to deregister the (never
    registered) device.

    To avoid this, make init code return an error on paravirt or when
    microcode loading is disabled. The driver will then never be loaded.

    Signed-off-by: Boris Ostrovsky
    Link: http://lkml.kernel.org/r/1422411669-25147-1-git-send-email-boris.ostrovsky@oracle.com
    Reported-by: James Digwall
    Cc: stable@vger.kernel.org # 3.18
    Signed-off-by: Borislav Petkov

    Boris Ostrovsky
     

06 Dec, 2014

2 commits

  • Normally, we do reapply microcode on resume. However, in the cases where
    that microcode comes from the early loader and the late loader hasn't
    been utilized yet, there's no easy way for us to go and apply the patch
    applied during boot by the early loader.

    Thus, reuse the patch stashed by the early loader for the BSP.

    Signed-off-by: Borislav Petkov

    Borislav Petkov
     
  • Paravirtual guests are not expected to load microcode into processors
    and therefore it is not necessary to initialize microcode loading
    logic.

    In fact, under certain circumstances initializing this logic may cause
    the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
    macro which does not work in Xen (the code path that leads to this macro
    happens during resume when we call mc_bp_resume()->load_ucode_ap()
    ->check_loader_disabled_ap())

    Signed-off-by: Boris Ostrovsky
    Link: http://lkml.kernel.org/r/1417469264-31470-1-git-send-email-boris.ostrovsky@oracle.com
    Signed-off-by: Borislav Petkov

    Boris Ostrovsky
     

19 Nov, 2014

1 commit

  • In the situation when we apply early microcode but do *not* apply late
    microcode, we fail to update the BSP's microcode on resume because we
    haven't initialized the uci->mc microcode pointer. So, in order to
    alleviate that, we go and dig out the stashed microcode patch during
    early boot. It is basically the same thing that is done on the APs early
    during boot so do that too here.

    Tested-by: alex.schnaidt@gmail.com
    Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
    Cc: Henrique de Moraes Holschuh
    Cc: Fenghua Yu
    Cc: # v3.9
    Signed-off-by: Borislav Petkov
    Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
    Signed-off-by: Thomas Gleixner

    Borislav Petkov
     

21 May, 2014

1 commit

  • Add a cmdline param which disables the microcode loader. This is useful
    mostly in debugging situations where we want to turn off microcode
    loading, both early from the initrd and late, as a means to be able to
    rule out its influence on the machine.

    Signed-off-by: Borislav Petkov
    Link: http://lkml.kernel.org/r/1400525957-11525-3-git-send-email-bp@alien8.de
    Signed-off-by: H. Peter Anvin

    Borislav Petkov
     

14 Jan, 2014

1 commit

  • We've grown a bunch of microcode loader files all prefixed with
    "microcode_". They should be under cpu/ because this is strictly
    CPU-related functionality so do that and drop the prefix since they're
    in their own directory now which gives that prefix. :)

    While at it, drop MICROCODE_INTEL_LIB config item and stash the
    functionality under CONFIG_MICROCODE_INTEL as it was its only user.

    Signed-off-by: Borislav Petkov
    Tested-by: Aravind Gopalakrishnan

    Borislav Petkov