From owner-freebsd-arch@freebsd.org Thu Jul 12 18:31:22 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC4981030FCC for ; Thu, 12 Jul 2018 18:31:21 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B32677806 for ; Thu, 12 Jul 2018 18:31:21 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pg1-x52a.google.com with SMTP id e6-v6so4149825pgv.2 for ; Thu, 12 Jul 2018 11:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=j4g7bIfIkdmc8pkGkfarN90PZbewcT4sSg3C4TAWbqQ=; b=EjuSBOlAc6tH0/bBOJKVkVDDoABaW10r7ke0CI024giPaq49eaeRot+u8CZe+e6qoL zmf/h3+tGTnwA1Zsy3CxbMtF2iRRHxddfC4dZsL/VXO2gFYgoF+YNncCTDbu6EHTohIE jD3HYrZxG6Q3hIJLgPfT3Mt7NRbI+UvPz+q/T8jDGgiglwk7Rl9W8yBersgz8lwIyrjT gEo19Ykko6wi+ETYzQQ+sEDfMdmEEgb9kqDX8E+GEg6cq9cNU7cGksj4t0NsHzeZmIFr CeFKU+roz2CSuo1MMYMXpXT24DidUVF4TQGgooJAmBcNxFKUrhmuC1doCNe4Lt20KvH0 p3Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:subject:message-id :mime-version:content-disposition:user-agent; bh=j4g7bIfIkdmc8pkGkfarN90PZbewcT4sSg3C4TAWbqQ=; b=XpQ5/UodnJC3Y3Ybn2zICNAvdLd5495NbtTw8ZnxA2a6Ixmv8DLyCfpX1kKbgViQ1E 70SZ7Y4gUDdnu6iZW08prm0hvPIoWcIFrLC8rT60SZCg6h/lUwMJsfD4mzpSMJ31Kf7F 5IAJ/MNq80NEsnl1pN1RrQZjdeCgSCo03PoO2aosB0WCBunG4HMoG9efGYuBCfxnvOzv hOhSUGmLpeOV3d7fopH/OmRsRNyF2zUol7m7cXZMGQxi46e1AWClh7i8tslq/woCS2jQ 9zBM9Vyfa4Ydgnuxd5B29L/gUCoryRk1hMdogBU49tjYCp2zYs7PYoP80p4DeGmpUQ2g IT+g== X-Gm-Message-State: AOUpUlFZD8heM1q7Wbnm4DneUJqnBzquFEzmeyL2s+JgwFInm93eQPSH F6xmrUw1kP+mUnIwVsko7JS+6Q== X-Google-Smtp-Source: AAOMgpfdRUgL5xz/D094tYW2e7Qvbq1lN1C09NNLN/ztYX24IJkAy6yH7PG6gGbxOJF41J8bJaNdpw== X-Received: by 2002:a65:5683:: with SMTP id v3-v6mr3037967pgs.176.1531420280019; Thu, 12 Jul 2018 11:31:20 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-107.dsl.bell.ca. [70.52.224.107]) by smtp.gmail.com with ESMTPSA id y9-v6sm18463501pfk.7.2018.07.12.11.31.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 11:31:19 -0700 (PDT) Sender: Mark Johnston Date: Thu, 12 Jul 2018 14:31:16 -0400 From: Mark Johnston To: freebsd-arch@freebsd.org Subject: early x86 microcode loading Message-ID: <20180712183116.GB15892@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 18:31:22 -0000 I've been working on support for early loading of microcode updates and wanted to solicit feedback on the approach before starting to get any code changes reviewed. Currently we support microcode updates via cpuctl(4), where cpucontrol(8) passes microcode blobs to the kernel via an ioctl interface. Updates are distributed by the sysutils/devcpu-data port. The scheme has a few shortcomings: - Microcode updates may introduce new CPU features, but since we load microcode from userland, updates are performed well after the kernel has done CPU feature detection. - Updates need to be reapplied after an ACPI suspend/resume, and there's currently no mechanism to automatically reapply the update after a resume. - Updates aren't applied until userspace starts running, so there exists a window in which the kernel is running without vulnerability mitigations provided by microcode updates. The aim of this work is to instead use the boot loader to load microcode updates into kernel memory, and modify the kernel to apply the updates as the first step in BSP and AP initialization, as well as after an ACPI resume. To configure an update, one would then just need to add the following lines to loader.conf: cpu_ucode_load="YES" cpu_ucode_name="/boot/firmware/microcode.bin" cpu_ucode_type="cpu_ucode" The kernel would then automatically load the update during processor initialization in the subsequent boot-up. A given Intel microcode update applies only to CPUs of a specific tuple, while AMD releases a single update per processor family. My plan is to extend cpucontrol(8) to determine the correct microcode update for the running system, and have the devcpu-data port install the corresponding file to /boot/firmware. The port could then add the following to loader.conf.local: devcpu_data_load="YES" devcpu_data_name="/boot/firmware/" devcpu_data_type="cpu_ucode" Currently, the port doesn't automatically enable microcode updates; one needs to enable the microcode_update rc script after installing the port. I'm not yet sure how this should be integrated with early loading. For example, if "service microcode_update onestart" enables early loading, how should early loading be disabled? Would it be reasonable for the port to automatically enable updates when it is installed? For at least Intel, my intention is to support loading of multiple update files concatenated together, and have the kernel determine the correct update to apply. This is to make it easier to support a cluster of mixed systems which boot from some shared environment; rather than needing to select and configure the correct update for each machine, one can supply all updates as a single file and have each machine select the right one automatically. This would come at the expense of some wasted memory: the combined set of Intel microcode files is currently about 1.8MB in size. A small patch to the loader is needed to guarantee the 16 byte-alignment of the loaded microcode update required by Intel. This will require a bootcode update on GPT-based systems in order for early loading to work reliably. I'm interested in any feedback on the above, and especially any suggestions on how this feature should be integrated with the devcpu-data port. Thanks in advance.