1. 09 6月, 2017 2 次提交
    • M
      thunderbolt: Add support for host and device NVM firmware upgrade · e6b245cc
      Mika Westerberg 提交于
      Starting from Intel Falcon Ridge the NVM firmware can be upgraded by
      using DMA configuration based mailbox commands. If we detect that the
      host or device (device support starts from Intel Alpine Ridge) has the
      DMA configuration based mailbox we expose NVM information to the
      userspace as two separate Linux NVMem devices: nvm_active and
      nvm_non_active. The former is read-only portion of the active NVM which
      firmware upgrade tools can be use to find out suitable NVM image if the
      device identification strings are not enough.
      
      The latter is write-only portion where the new NVM image is to be
      written by the userspace. It is up to the userspace to find out right
      NVM image (the kernel does very minimal validation). The ICM firmware
      itself authenticates the new NVM firmware and fails the operation if it
      is not what is expected.
      
      We also expose two new sysfs files per each switch: nvm_version and
      nvm_authenticate which can be used to read the active NVM version and
      start the upgrade process.
      
      We also introduce safe mode which is the mode a switch goes when it does
      not have properly authenticated firmware. In this mode the switch only
      accepts a couple of commands including flashing a new NVM firmware image
      and triggering power cycle.
      
      This code is based on the work done by Amir Levy and Michael Jamet.
      Signed-off-by: NMichael Jamet <michael.jamet@intel.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NYehezkel Bernat <yehezkel.bernat@intel.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6b245cc
    • M
      thunderbolt: Add support for Internal Connection Manager (ICM) · f67cf491
      Mika Westerberg 提交于
      Starting from Intel Falcon Ridge the internal connection manager running
      on the Thunderbolt host controller has been supporting 4 security
      levels. One reason for this is to prevent DMA attacks and only allow
      connecting devices the user trusts.
      
      The internal connection manager (ICM) is the preferred way of connecting
      Thunderbolt devices over software only implementation typically used on
      Macs. The driver communicates with ICM using special Thunderbolt ring 0
      (control channel) messages. In order to handle these messages we add
      support for the ICM messages to the control channel.
      
      The security levels are as follows:
      
        none - No security, all tunnels are created automatically
        user - User needs to approve the device before tunnels are created
        secure - User need to approve the device before tunnels are created.
      	   The device is sent a challenge on future connects to be able
      	   to verify it is actually the approved device.
        dponly - Only Display Port and USB tunnels can be created and those
                 are created automatically.
      
      The security levels are typically configurable from the system BIOS and
      by default it is set to "user" on many systems.
      
      In this patch each Thunderbolt device will have either one or two new
      sysfs attributes: authorized and key. The latter appears for devices
      that support secure connect.
      
      In order to identify the device the user can read identication
      information, including UUID and name of the device from sysfs and based
      on that make a decision to authorize the device. The device is
      authorized by simply writing 1 to the "authorized" sysfs attribute. This
      is following the USB bus device authorization mechanism. The secure
      connect requires an additional challenge step (writing 2 to the
      "authorized" attribute) in future connects when the key has already been
      stored to the NVM of the device.
      
      Non-ICM systems (before Alpine Ridge) continue to use the existing
      functionality and the security level is set to none. For systems with
      Alpine Ridge, even on Apple hardware, we will use ICM.
      
      This code is based on the work done by Amir Levy and Michael Jamet.
      Signed-off-by: NMichael Jamet <michael.jamet@intel.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NYehezkel Bernat <yehezkel.bernat@intel.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f67cf491
  2. 18 11月, 2016 2 次提交
  3. 15 11月, 2016 1 次提交
    • L
      thunderbolt, efi: Fix Kconfig dependencies · 79f9cd35
      Lukas Wunner 提交于
      Fix this EFI build failure on certain (rand)configs:
      
        drivers/firmware/efi/apple-properties.c:149:9: error: implicit declaration of function ???efi_get_device_by_path??? [-Werror=implicit-function-declaration]
      
      which is due to:
      
        warning: (THUNDERBOLT) selects APPLE_PROPERTIES which has unmet direct dependencies (EFI && EFI_STUB && X86)
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Cc: Andreas Noever <andreas.noever@gmail.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Pedro Vilaça <reverser@put.as>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Pierre Moreau <pierre.morrow@free.fr> [MacBookPro11,3]
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20161114151033.GA10141@wunner.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      79f9cd35
  4. 13 11月, 2016 1 次提交
    • L
      thunderbolt: Use Device ROM retrieved from EFI · c9cc3aaa
      Lukas Wunner 提交于
      Macs with Thunderbolt 1 do not have a unit-specific DROM: The DROM is
      empty with uid 0x1000000000000. (Apple started factory-burning a unit-
      specific DROM with Thunderbolt 2.)
      
      Instead, the NHI EFI driver supplies a DROM in a device property. Use
      it if available. It's only available when booting with the efistub.
      If it's not available, silently fall back to our hardcoded DROM.
      
      The size of the DROM is always 256 bytes. The number is hardcoded into
      the NHI EFI driver. This commit can deal with an arbitrary size however,
      just in case they ever change that.
      
      Background information: The EFI firmware volume contains ROM files for
      the NHI, GMUX and several other chips as well as key material. This
      strategy allows Apple to deploy ROM or key updates by simply publishing
      an EFI firmware update on their website. Drivers do not access those
      files directly but rather through a file server via EFI protocol
      AC5E4829-A8FD-440B-AF33-9FFE013B12D8. Files are identified by GUID, the
      NHI DROM has 339370BD-CFC6-4454-8EF7-704653120818.
      
      The NHI EFI driver amends that file with a unit-specific uid. The uid
      has 64 bit but its entropy is much lower: 24 bit represent the model,
      24 bit are taken from a serial number, 16 bit are fixed. The NHI EFI
      driver obtains the serial number via the DataHub protocol, copies it
      into the DROM, calculates the CRC and submits the result as a device
      property.
      
      A modification is needed in the resume code where we currently read the
      uid of all switches in the hierarchy to detect plug events that occurred
      during sleep. On Thunderbolt 1 root switches this will now lead to a
      mismatch between the uid of the empty DROM and the EFI DROM. Exempt the
      root switch from this check: It's built in, so the uid should never
      change. However we continue to *read* the uid of the root switch, this
      seems like a good way to test its reachability after resume.
      
      Tested-by: Lukas Wunner <lukas@wunner.de> [MacBookPro9,1]
      Tested-by: Pierre Moreau <pierre.morrow@free.fr> [MacBookPro11,3]
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Acked-by: NAndreas Noever <andreas.noever@gmail.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Pedro Vilaça <reverser@put.as>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20161112213237.8804-10-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c9cc3aaa
  5. 22 6月, 2014 1 次提交
  6. 21 6月, 2014 1 次提交
  7. 20 6月, 2014 1 次提交
    • A
      thunderbolt: Add initial cactus ridge NHI support · 16603153
      Andreas Noever 提交于
      Thunderbolt hotplug is supposed to be handled by the firmware. But Apple
      decided to implement thunderbolt at the operating system level. The
      firmare only initializes thunderbolt devices that are present at boot
      time. This driver enables hotplug of thunderbolt of non-chained
      thunderbolt devices on Apple systems with a cactus ridge controller.
      
      This first patch adds the Kconfig file as well the parts of the driver
      which talk directly to the hardware (that is pci device setup, interrupt
      handling and RX/TX ring management).
      Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16603153