From owner-freebsd-arch@freebsd.org Fri Jul 13 16:16:35 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 2972C1042968 for ; Fri, 13 Jul 2018 16:16:35 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 9DCE68CF55 for ; Fri, 13 Jul 2018 16:16:34 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pg1-x536.google.com with SMTP id k3-v6so5142775pgq.5 for ; Fri, 13 Jul 2018 09:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=K0cMYBCi1pzqLFLOLvAw25PPNRR4GU1GIRxviV8I8uA=; b=NvMlIc+PGawgMd1kKf22buILxNo4TuhROASRx388xWY2TZ2Mh+j+zuyV4/1vT56Gog cDNIQAUeaHfV8UUxG9hB/TA8ImobtjmWAqKA9ek69JYaVXQkyFS4nuQZ1okvGdfomRlB +Z/hpn7q1I0jEdbG4FlTu7HuMwfyyzMA4K+KB/6+6E+WsQaB6gUSIOmhLJgPwrMTgs9f GQo74EH5ZbTl7iL6Jx6ydoV6X83CDv8UO3vUnkOH2rwDB1VvBZF0fni4JvciOMnvd5Cq 7EQyX8ls57MZB2u4PPzrJczLmDK/vNR7mSU3QQFvW2vU1l6nkgqoKzC5xvNUW/fJnmMk ObIg== 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:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=K0cMYBCi1pzqLFLOLvAw25PPNRR4GU1GIRxviV8I8uA=; b=MAd/e8OiSUi4qMY4CnPC4xd+jD/sIO9R+FoADabam1KF662nXXbIcc4DgEc6fU2Jhj pzIEgoQ4L0bJgGu+hCE1aKK4dWiJf8b0kNA9C17WBME11NFKCbCN90qGySYEklqriHAS 9mxmiGSPs5tk9mm+9TLdUL4CXaL3dO3qzgr4Y0Iucm2RUkVUGlF0h5Ba03npcm101qiq 8Xn9+88A4Qk6dHWjAbG+rftE+8UPKVewp5E2YmREyCWG5dNOf/s1tdxbyfaz+cMMh1s4 X4kww8aaOdsnir/WGY7/uxBKdbCMFkfVCOs+MgYPQTqlZna7Je5gMLs0IT4xLUDChqJl HqZQ== X-Gm-Message-State: AOUpUlGK521b2gcs6u5JpjYA2bfUH6YELx50+LWrJk2qT0dg5SZRnmm6 x3KyrHFWVHW3Sa0a8QHRcuq0JA== X-Google-Smtp-Source: AAOMgpcjPR0ThzS0TBFiBXD65zeriUe8qDjqRH97Yma+V1qI3lbhnHR7mWi7PNZ+iJZAtUAGhESmqw== X-Received: by 2002:a63:455c:: with SMTP id u28-v6mr6726216pgk.210.1531498593697; Fri, 13 Jul 2018 09:16:33 -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 b67-v6sm90041094pfd.74.2018.07.13.09.16.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jul 2018 09:16:32 -0700 (PDT) Sender: Mark Johnston Date: Fri, 13 Jul 2018 12:16:30 -0400 From: Mark Johnston To: Shawn Webb Cc: freebsd-arch@freebsd.org Subject: Re: early x86 microcode loading Message-ID: <20180713161630.GD26064@raichu> References: <20180712183116.GB15892@raichu> <20180712193015.kvupmvmusqr3cy4y@mutt-hbsd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180712193015.kvupmvmusqr3cy4y@mutt-hbsd> 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: Fri, 13 Jul 2018 16:16:35 -0000 On Thu, Jul 12, 2018 at 03:30:15PM -0400, Shawn Webb wrote: > Hey Mark, > > Thank you very much for working on this and opening the discussion. > What you've drafted sounds reasonable to me, but perhaps with one > edge case. > > On Thu, Jul 12, 2018 at 02:31:16PM -0400, Mark Johnston wrote: > > 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" > > I'm curious about what would happen if I moved the drives to a new > system and booted off of them, perhaps forgetting to comment out the > above lines in loader.conf beforehand. > > Additionally, how would I instruct the system in such a case to > re-probe which firmware file I need? > > I recognize this could be construed as an edge case, but I've done > this multiple times (and, thanks to ZFS, really easily). This is being discussed in another subthread. Right now, an update simply wouldn't be applied during the first boot. My notion is that an rc script provided by the port would automatically reconfigure the update, so it'd be applied upon a subsequent reboot.