From bart.smaalders@sun.com Thu Jun 14 15:55:15 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5EMtFZh006504 for ; Thu, 14 Jun 2007 15:55:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5EMredY002385 for <@newsunmail1brm.central.sun.com:PSARC-EXT@Sun.COM>; Thu, 14 Jun 2007 15:53:41 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJN00A0PE9GEN00@brm-avmta-1.central.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu, 14 Jun 2007 16:53:40 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJN000SBE9FOF40@brm-avmta-1.central.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu, 14 Jun 2007 16:53:40 -0600 (MDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5EMrd8n015782 for ; Thu, 14 Jun 2007 15:53:39 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l5EMrd0n018708 for ; Thu, 14 Jun 2007 15:53:39 -0700 (PDT) Date: Thu, 14 Jun 2007 15:51:46 -0700 From: Bart Smaalders Subject: PSARC/2007/349 Intel Microcode Update Support To: PSARC-EXT@sun.com Message-id: <4671C682.5050402@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_HbIMLNbPLak5JyC/SA9flw)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Status: RO Content-Length: 7078 This is a multi-part message in MIME format. --Boundary_(ID_HbIMLNbPLak5JyC/SA9flw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT I'm sponsoring the attached fast track for Sherry Moore. The requested release boundary is patch/micro, and the case times out on 6/20/2007. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts --Boundary_(ID_HbIMLNbPLak5JyC/SA9flw) Content-type: text/plain; name=onepager.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=onepager.txt Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Intel Microcode Update Support 1.2. Name of Document Author/Supplier: Sherry.Moore@sun.com 1.3. Date of This Document: 05/31/2007 1.4. Name of Major Document Customer(s)/Consumer(s): PSARC 1.5. Email Aliases: 1.5.1. Responsible Manager: Darrin.Johnson@sun.com 1.5.2. Responsible Engineer: Sherry.Moore@sun.com 1.5.3. Marketing Manager: Videhi.Mallela@Sun.COM 1.5.4. Interest List: intel-ext@sun.com 2. Project Summary 2.1. Project Description: The Intel P4, Xeon, P6 family and future processors have the capability to correct errata by loading an Intel-supplied data block called microcode into the processor. This update is typically done by the BIOS. To alleviate the dependencies on BIOS updates and to reduce system down time, it is highly desirable to have the microcode update ability available in the OS. 2.2. Risks and Assumptions: The current families of processors supporting microcode update reject malformed microcode or microcode not intended for their platforms. We assume that will not change with future processors. 3. Business Summary 3.1. Problem Area: Currently, if a processor erratum is identified, customers have to either wait for a BIOS update, or for an OS patch that works around the erratum. The first solution renders us at the BIOS vendors' mercy; the second requires releasing point patches. Both incurs huge delay and financial expenses. 3.2. Market/Requester: Sun is currently producing Intel-based blade systems. More Intel-based platforms are on the Systems Group's roadmap. Such capability will no doubt benefit our customers. 3.3. Business Justification: The ability to work around processor errata in the OS by applying microcode updates will improve RAS on our systems. 3.4. Competitive Analysis: Linux has a driver for updating microcode once the system is up and running. We will provide not only the ability to work around errata once the system is completely up and running, but also the ability to perform microcode update at boot time. Both Intel and AMD stated that microcode updates and errata workarounds should be performed as early as possible during boot. 3.6. How will you know when you are done?: When we have all the software components to enable microcode update at boot time and at run time. 4. Technical Description: 4.1. Technical Details Microcode update can be performed at early boot time by the operating system as each processor is being brought online. During early boot process the kernel would locate the corresponding microcode file if exists and perform the microcode update if necessary. For the boot CPU the update is performed in mlsetup(); for the other CPUs the update is done in mp_startup(). Additionally we also provide a mechanism to dynamically update the microcode when the system is already booted and running. The live update will be done via a user command through ioctl to a driver. The run time update provides a way to load critical microcode updates to ensure system integrity without requiring a reboot or BIOS upgrade. 4.2. Bug/RFE Number(s): 6558456 Need to support microcode update on Intel platforms 4.3. In Scope: 4.4. Out of Scope: 4.5. Interfaces: 4.5.1 Command ucodeadm(1M): committed A new command ucodeadm(1M) is introduced to report processor microcode revision, install microcode files on a target system, and update microcode on a live system. # ucodeadm -h usage: ucodeadm -v Shows running microcode version. ucodeadm -u microcode-text-file Updates microcode to the latest matching version found in microcode-text-file. ucodeadm -i [-R path] microcode-text-file Installs microcode on the file system to be used during subsequent boot. ucodeadm will be installed in /usr/sbin/. Text for ucodeadm man page is attached as ucodeadm.man.txt. The -v option can be performed by a non-privileged user. The -i option requires privilege to write to the destination. The -u option requires privilege secpolicy_ucode_update(), which is currently PRIV_ALL. The privilege checking will be performed by the driver. User with "Maintenance and Repair" profile will be allowed to execute "/usr/sbin/ucodeadm -u" to update microcode. 4.5.2 Driver ucode_drv: Uncommitted The ucode_drv driver will provide two ioctl commands: UCODE_GET_VERSION: report microcode version UCODE_UPDATE: update microcode The driver will be installed as /devices/pseudo/ucode. 4.6. Doc Impact: A man page for ucodeadm(1M) will be delivered. 4.7. Admin/Config Impact: New command ucodeadm(1M). 4.8. HA Impact: None. 4.10. Packaging & Delivery: SUNWckr, SUNWcsu, SUNWcar.i and SUNWhea will be updated. 4.11. Security Impact: None. 4.12. Dependencies: This project has dependency on the Intel microcode format as described in Intel 64 and IA-32 Architectures Software Developer's Manual Section 9-11 "Microcode Update Facilities". 5. Reference Documents: Intel 64 and IA-32 Architectures Software Developer's Manual Section 9-11 "Microcode Update Facilities". http://jurassic-x4600/~sherrym/projects/microcode/microcode.txt http://jurassic-x4600/~sherrym/projects/microcode/ucodeadm.man.txt 6. Resources and Schedule: 6.1. Projected Availability: Q1FY08 6.2. Cost of Effort: 1 person for 3 months 6.3. Cost of Capital Resources: No additional capital resources expected. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: Solaris 6.4.3. Type of CPT Review and Approval expected: FastTrack 6.4.4. Project Boundary Conditions: 6.4.5. Is this a necessary project for OEM agreements: Yes. 6.4.6. Notes: None. 6.4.7. Target RTI Date/Release: 5/30/2007 onnv 6/14/2007 S10U5 6.4.8. Target Code Design Review Date: 6/07/2007 6.4.9. Update approval addition: None. 6.5. ARC review type: FastTrack 7. Prototype Availability: 7.1. Prototype Availability: Prototype is available. 7.2. Prototype Cost: 1 person 2 months. --Boundary_(ID_HbIMLNbPLak5JyC/SA9flw)-- From sommerfeld@sun.com Thu Jun 14 17:25:06 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5F0P6AW009433 for ; Thu, 14 Jun 2007 17:25:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5F0NRfC001742; Fri, 15 Jun 2007 01:23:31 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJN00G1ZIF6Q000@brm-avmta-1.central.sun.com>; Thu, 14 Jun 2007 18:23:30 -0600 (MDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJN000NJIF3OKA0@brm-avmta-1.central.sun.com>; Thu, 14 Jun 2007 18:23:28 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5F0NOGv017917; Thu, 14 Jun 2007 20:23:24 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5F0NOEF013976; Thu, 14 Jun 2007 20:23:24 -0400 (EDT) Date: Thu, 14 Jun 2007 20:23:23 -0400 From: Bill Sommerfeld Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <4671C682.5050402@Sun.COM> To: Bart Smaalders Cc: PSARC-EXT@sun.com, Sherry Moore Message-id: <1181867003.11308.107.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> Status: RO Content-Length: 811 On Thu, 2007-06-14 at 15:51 -0700, Bart Smaalders wrote: > Both Intel and AMD stated that microcode updates and errata > workarounds should be performed as early as possible during > boot. Do we know for sure whether AMD processors support a similar facility using the same interface? > 5. Reference Documents: > > Intel 64 and IA-32 Architectures Software Developer's Manual > Section 9-11 "Microcode Update Facilities". > > http://jurassic-x4600/~sherrym/projects/microcode/microcode.txt > http://jurassic-x4600/~sherrym/projects/microcode/ucodeadm.man.txt it's best to copy files like this into the case directory, both so they're archived for posterity and also (for open cases) they become visible to external reviewers. I'd do it but I want to hear the author's ok first.. - Bill From sherry.moore@sun.com Thu Jun 14 17:50:20 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5F0oJ2k009608 for ; Thu, 14 Jun 2007 17:50:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5F0mdOj007246; Fri, 15 Jun 2007 01:48:45 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJN00H3TJL7ZQ00@brm-avmta-1.central.sun.com>; Thu, 14 Jun 2007 18:48:43 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJN0000SJL5OKC0@brm-avmta-1.central.sun.com>; Thu, 14 Jun 2007 18:48:42 -0600 (MDT) Received: from geralyn.sfbay.sun.com (geralyn.SFBay.Sun.COM [129.146.226.228]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5F0mepU015945; Thu, 14 Jun 2007 17:48:41 -0700 (PDT) Received: from geralyn.sfbay.sun.com (localhost [127.0.0.1]) by geralyn.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l5F0meMu010465; Thu, 14 Jun 2007 17:48:40 -0700 (PDT) Received: (from sherrym@localhost) by geralyn.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l5F0meKj010464; Thu, 14 Jun 2007 17:48:40 -0700 (PDT) Date: Thu, 14 Jun 2007 17:48:40 -0700 From: Sherry Moore Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <1181867003.11308.107.camel@thunk> To: Bill Sommerfeld Cc: Bart Smaalders , PSARC-EXT@sun.com, Sherry Moore Message-id: <20070615004840.GP9695@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> <1181867003.11308.107.camel@thunk> X-Authentication-warning: geralyn.sfbay.sun.com: sherrym set sender to sherry.moore@sun.com using -f User-Agent: Mutt/1.4.1i Status: RO Content-Length: 958 > Do we know for sure whether AMD processors support a similar facility > using the same interface? AMD processors currently do not support microcode update by the OS. I am actively pushing AMD for this capability on future AMD processors. Hopefully I could influence the interface design. However I do anticipate additional work when the feature does become available. > > > 5. Reference Documents: > > > > Intel 64 and IA-32 Architectures Software Developer's Manual > > Section 9-11 "Microcode Update Facilities". > > > > http://jurassic-x4600/~sherrym/projects/microcode/microcode.txt > > http://jurassic-x4600/~sherrym/projects/microcode/ucodeadm.man.txt > > it's best to copy files like this into the case directory, both so > they're archived for posterity and also (for open cases) they become > visible to external reviewers. > > I'd do it but I want to hear the author's ok first.. Please copy the files for me. Thank you. Sherry From sommerfeld@sun.com Thu Jun 14 18:46:30 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5F1kUNr012118 for ; Thu, 14 Jun 2007 18:46:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5F1iqeD018662; Fri, 15 Jun 2007 02:44:55 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJN00L1DM6SKX00@brm-avmta-1.central.sun.com>; Thu, 14 Jun 2007 19:44:52 -0600 (MDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJN000FLM6SOKF0@brm-avmta-1.central.sun.com>; Thu, 14 Jun 2007 19:44:52 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5F1imC2005862; Thu, 14 Jun 2007 21:44:48 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5F1immX014416; Thu, 14 Jun 2007 21:44:48 -0400 (EDT) Date: Thu, 14 Jun 2007 21:44:46 -0400 From: Bill Sommerfeld Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <20070615004840.GP9695@sun.com> To: Sherry Moore Cc: Bart Smaalders , PSARC-EXT@sun.com Message-id: <1181871886.11308.136.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> <1181867003.11308.107.camel@thunk> <20070615004840.GP9695@sun.com> Status: RO Content-Length: 1007 On Thu, 2007-06-14 at 17:48 -0700, Sherry Moore wrote: > > Do we know for sure whether AMD processors support a similar facility > > using the same interface? > > AMD processors currently do not support microcode update by the OS. I > am actively pushing AMD for this capability on future AMD processors. > Hopefully I could influence the interface design. However I do > anticipate additional work when the feature does become available. The name chosen for the command implies that you're setting precedent that we will enhance the current command for other processors rather than introduce a new command for different CPU families. I think this is a good thing -- if a different CPU needs additional parameters beyond a file containing the microcode "blob" are needed we can extend the CLI with more option flags. One more question (verging on code review...): Is this needed so early in boot that your new /platform/i86pc/ucode directory needs to be added to the boot archive? - Bill From bart.smaalders@sun.com Thu Jun 14 19:00:40 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5F20dxo012763 for ; Thu, 14 Jun 2007 19:00:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5F1wmN8020939; Fri, 15 Jun 2007 02:59:04 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJN00701MUEPK00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Jun 2007 18:59:02 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJN00A2RMUDABD0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Jun 2007 18:59:02 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5F1x1mn001220; Thu, 14 Jun 2007 18:59:01 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l5F1x1H5022881; Thu, 14 Jun 2007 18:59:01 -0700 (PDT) Date: Thu, 14 Jun 2007 18:57:08 -0700 From: Bart Smaalders Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <1181871886.11308.136.camel@thunk> To: Bill Sommerfeld Cc: Sherry Moore , PSARC-EXT@sun.com Message-id: <4671F1F4.8010009@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> <1181867003.11308.107.camel@thunk> <20070615004840.GP9695@sun.com> <1181871886.11308.136.camel@thunk> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Status: RO Content-Length: 1914 Bill Sommerfeld wrote: > On Thu, 2007-06-14 at 17:48 -0700, Sherry Moore wrote: >>> Do we know for sure whether AMD processors support a similar facility >>> using the same interface? >> AMD processors currently do not support microcode update by the OS. I >> am actively pushing AMD for this capability on future AMD processors. >> Hopefully I could influence the interface design. However I do >> anticipate additional work when the feature does become available. > > The name chosen for the command implies that you're setting precedent > that we will enhance the current command for other processors rather > than introduce a new command for different CPU families. > > I think this is a good thing -- if a different CPU needs additional > parameters beyond a file containing the microcode "blob" are needed we > can extend the CLI with more option flags. > > One more question (verging on code review...): Is this needed so early > in boot that your new /platform/i86pc/ucode directory needs to be added > to the boot archive? From the one pager: 3.4. Competitive Analysis: Linux has a driver for updating microcode once the system is up and running. We will provide not only the ability to work around errata once the system is completely up and running, but also the ability to perform microcode update at boot time. Both Intel and AMD stated that microcode updates and errata workarounds should be performed as early as possible during boot. By placing the microcode into the boot archive, it is possible to update the microcode before the processor becomes actively used in mp_startup. Doing the update early doesn't matter in most cases, but there like likely be situations where Solaris can update the microcode where other operating systems needs a BIOS patch. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From carlsonj@phorcys.east.sun.com Fri Jun 15 04:08:14 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5FB8Dut022174 for ; Fri, 15 Jun 2007 04:08:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5FB6Xqe014403; Fri, 15 Jun 2007 12:06:36 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJO00B03C70YH00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jun 2007 04:06:36 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJO00KAMC6Z0JF0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jun 2007 04:06:36 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5FB6Zdt019324; Fri, 15 Jun 2007 07:06:35 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5FB6Znf019321; Fri, 15 Jun 2007 07:06:35 -0400 (EDT) Date: Fri, 15 Jun 2007 07:06:35 -0400 From: James Carlson Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <4671C682.5050402@Sun.COM> To: Bart Smaalders Cc: PSARC-EXT@sun.com Message-id: <18034.29371.376422.227521@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> Status: RO Content-Length: 1059 Bart Smaalders writes: > I'm sponsoring the attached fast track for Sherry Moore. The requested > release boundary is patch/micro, and the case times out on 6/20/2007. A few minor questions: > 4.5.2 Driver ucode_drv: Uncommitted Why not Project Private? I'm curious about who else might want or need to use the driver itself. > UCODE_GET_VERSION: report microcode version > UCODE_UPDATE: update microcode For the version, is that just an ASCII text string? I'll assume that it is, that it's controlled by the vendor, and that we provide some "goodly" amount of room in the ioctl interface. (This is much less important for the ioctl if the driver is made private.) > The driver will be installed as /devices/pseudo/ucode. Without a /dev link? The layout of /devices is a devfs(7FS) implementation artifact. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sherry.moore@sun.com Fri Jun 15 09:30:48 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5FGUl0u029376 for ; Fri, 15 Jun 2007 09:30:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l5FGT8CA011971 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Sat, 16 Jun 2007 00:29:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJO00D0FR4O6F00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 15 Jun 2007 09:29:12 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJO0086NR4NTDA0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 15 Jun 2007 09:29:11 -0700 (PDT) Received: from geralyn.sfbay.sun.com (geralyn.SFBay.Sun.COM [129.146.226.228]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l5FGT9IS022605; Fri, 15 Jun 2007 09:29:09 -0700 (PDT) Received: from geralyn.sfbay.sun.com (localhost [127.0.0.1]) by geralyn.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l5FGT9r9010898; Fri, 15 Jun 2007 09:29:09 -0700 (PDT) Received: (from sherrym@localhost) by geralyn.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l5FGT9lt010897; Fri, 15 Jun 2007 09:29:09 -0700 (PDT) Date: Fri, 15 Jun 2007 09:29:09 -0700 From: Sherry Moore Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <18034.29371.376422.227521@gargle.gargle.HOWL> To: James Carlson Cc: Bart Smaalders , PSARC-EXT@sun.com Message-id: <20070615162909.GR9695@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> <18034.29371.376422.227521@gargle.gargle.HOWL> X-Authentication-warning: geralyn.sfbay.sun.com: sherrym set sender to sherry.moore@sun.com using -f User-Agent: Mutt/1.4.1i Status: RO Content-Length: 1121 > > 4.5.2 Driver ucode_drv: Uncommitted > > Why not Project Private? I'm curious about who else might want or > need to use the driver itself. I don't anticipate anyone else to use the driver. I agree that "Project Private" is more appropriate. I chose "Uncommitted" as it's not very clear to me what "customer-visible" entails. > > UCODE_GET_VERSION: report microcode version > > UCODE_UPDATE: update microcode > > For the version, is that just an ASCII text string? I'll assume that > it is, that it's controlled by the vendor, and that we provide some > "goodly" amount of room in the ioctl interface. (This is much less > important for the ioctl if the driver is made private.) The version is a hex number controlled by the vendor. > > The driver will be installed as /devices/pseudo/ucode. > > Without a /dev link? The layout of /devices is a devfs(7FS) > implementation artifact. There will be a link from /dev to /devices. It will look like this: # ls -l /dev/ucode lrwxrwxrwx 1 root root 31 May 16 17:54 /dev/ucode -> ../devices/pseudo/ucode@0:ucode Thanks, Sherry From carlsonj@phorcys.east.sun.com Fri Jun 15 09:43:16 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5FGhGJB029570 for ; Fri, 15 Jun 2007 09:43:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5FGfEPM025987; Fri, 15 Jun 2007 10:41:14 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJO00F05RPISP00@brm-avmta-1.central.sun.com>; Fri, 15 Jun 2007 10:41:42 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJO0062WRPHXJC0@brm-avmta-1.central.sun.com>; Fri, 15 Jun 2007 10:41:42 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5FGff9w020246; Fri, 15 Jun 2007 12:41:41 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5FGffMN020243; Fri, 15 Jun 2007 12:41:41 -0400 (EDT) Date: Fri, 15 Jun 2007 12:41:41 -0400 From: James Carlson Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <20070615162909.GR9695@sun.com> To: Sherry Moore Cc: Bart Smaalders , PSARC-EXT@sun.com Message-id: <18034.49477.613226.356404@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> <18034.29371.376422.227521@gargle.gargle.HOWL> <20070615162909.GR9695@sun.com> Status: RO Content-Length: 2070 Sherry Moore writes: > > > 4.5.2 Driver ucode_drv: Uncommitted > > > > Why not Project Private? I'm curious about who else might want or > > need to use the driver itself. > > I don't anticipate anyone else to use the driver. I agree that > "Project Private" is more appropriate. I chose "Uncommitted" as it's > not very clear to me what "customer-visible" entails. For Uncommitted, we might have a man page with stability warnings on it, or we might have a white paper or some other less-formal documentation. "Uncommitted" is one of the so-called "Public" stability levels, which means that we intentionally ship at least some form of documentation for it, and we expect some users (at their own risk) will use it. The fact that the node exists and is visible in the file system is an implementation detail. (Similarly, undocumented daemons and header files are not public interfaces. The fact that you can "see" them doesn't make them things you can safely use.) > > > UCODE_GET_VERSION: report microcode version > > > UCODE_UPDATE: update microcode > > > > For the version, is that just an ASCII text string? I'll assume that > > it is, that it's controlled by the vendor, and that we provide some > > "goodly" amount of room in the ioctl interface. (This is much less > > important for the ioctl if the driver is made private.) > > The version is a hex number controlled by the vendor. Hex? OK. (I'm sort of curious how that's reported, but if this is now Project Private, it doesn't really matter.) > > Without a /dev link? The layout of /devices is a devfs(7FS) > > implementation artifact. > > There will be a link from /dev to /devices. It will look like this: > > # ls -l /dev/ucode > lrwxrwxrwx 1 root root 31 May 16 17:54 /dev/ucode -> ../devices/pseudo/ucode@0:ucode OK; thanks. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Reed@sun.com Fri Jun 15 21:31:40 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5G4Vdta019369 for ; Fri, 15 Jun 2007 21:31:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l5G4U20K027468 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Sat, 16 Jun 2007 12:30:05 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJP00B0TOI2WU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 15 Jun 2007 21:30:02 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJP0091UOHW8G10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 15 Jun 2007 21:29:57 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5G4TuUU026159 for ; Sat, 16 Jun 2007 04:29:56 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJP00501O5T6B00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Sat, 16 Jun 2007 12:29:56 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJP00DZXOHU9423@mail-apac.sun.com>; Sat, 16 Jun 2007 12:29:56 +0800 (SGT) Date: Fri, 15 Jun 2007 21:29:54 -0700 From: Darren.Reed@sun.com Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <4671C682.5050402@Sun.COM> Sender: Darren.Reed@sun.com To: Sherry.Moore@sun.com Cc: PSARC-EXT@sun.com Message-id: <46736742.7050200@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 426 ... > 4.12. Dependencies: > > This project has dependency on the Intel microcode format as > described in Intel 64 and IA-32 Architectures Software > Developer's Manual Section 9-11 "Microcode Update Facilities". > > Are you aware of anything in this dependency that might prohibit the deliverables of this project being able to function with both new and old formats of microcode at some point in the future? Darren From sherry.moore@sun.com Sat Jun 16 11:14:40 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5GIEeSf009698 for ; Sat, 16 Jun 2007 11:14:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5GICWdf015079; Sat, 16 Jun 2007 12:12:34 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJQ0060BQLQ5Z00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 16 Jun 2007 11:13:02 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJQ000FYQLPRT10@nwk-avmta-1.sfbay.Sun.COM>; Sat, 16 Jun 2007 11:13:01 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5GID1MZ786437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Jun 2007 11:13:01 -0700 (PDT) Received: (from sherrym@localhost) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id l5GID1aX786436; Sat, 16 Jun 2007 11:13:01 -0700 (PDT) Date: Sat, 16 Jun 2007 11:13:01 -0700 From: Sherry Moore Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <46736742.7050200@Sun.COM> To: Darren.Reed@sun.com Cc: sherry.moore@sun.com, PSARC-EXT@sun.com Message-id: <20070616181301.GA786098@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> <46736742.7050200@Sun.COM> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: sherrym set sender to sherry.moore@sun.com using -f User-Agent: Mutt/1.4.1i Status: RO Content-Length: 789 > > 4.12. Dependencies: > > > > This project has dependency on the Intel microcode format as > > described in Intel 64 and IA-32 Architectures Software > > Developer's Manual Section 9-11 "Microcode Update Facilities". > > > Are you aware of anything in this dependency that might > prohibit the deliverables of this project being able to > function with both new and old formats of microcode > at some point in the future? There are explicit checks for the format version in the code, as a result the deliverables of this project will not work with new formats of the microcode. The format processing portion of the project will need to be extended should the new format become a reality. At this point Intel has no plans to release microcode in a different format. Thanks, Sherry From Michael.Hunter@sun.com Mon Jun 18 03:04:49 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IA4n3K006008 for ; Mon, 18 Jun 2007 03:04:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5IA3Boo004202; Mon, 18 Jun 2007 03:03:12 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJT00805T9AEF00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 18 Jun 2007 03:03:10 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJT00DJAT9ARUC0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 18 Jun 2007 03:03:10 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l5IA3Aew014413; Mon, 18 Jun 2007 03:03:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JJT00801T7J3S00@fe-sfbay-10.sun.com> (original mail from Michael.Hunter@Sun.COM); Mon, 18 Jun 2007 03:03:10 -0700 (PDT) Received: from sun.com ([10.7.251.174]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJT0017WT997B40@fe-sfbay-10.sun.com>; Mon, 18 Jun 2007 03:03:10 -0700 (PDT) Date: Mon, 18 Jun 2007 03:03:09 -0700 From: Michael Hunter Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <4671C682.5050402@Sun.COM> Sender: Michael.Hunter@sun.com To: Bart Smaalders Cc: PSARC-EXT@sun.com Message-id: <20070618030309.00000827@localhost> Organization: SMI MIME-version: 1.0 X-Mailer: Claws Mail 2.9.2-csw (GTK+ 2.10.11; i386-pc-solaris2.8) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> Status: RO Content-Length: 956 On Thu, 14 Jun 2007 15:51:46 -0700 Bart Smaalders wrote: > > > I'm sponsoring the attached fast track for Sherry Moore. The requested > release boundary is patch/micro, and the case times out on 6/20/2007. It seems like the extra layer of authenticity that 2007/355 provides by providing the updates via signed modules might to of value to our customers. Eventhough I believe in the almost 10 years that intel processor updates have been available there havn't been any trojan horses just obfusacation of mechanism, the use of what has to be known encryption keys by this point, and embedded checksums can't be much of a barrier to create such. Additionally allowing these to be loaded early in boot could make a simple denial of service trojan horse (one that just loaded a bogus update intended to brick the machine) that much more powerful and harder to diagnose. mph From bart.smaalders@sun.com Mon Jun 18 09:44:18 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IGiI1e014020 for ; Mon, 18 Jun 2007 09:44:18 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5IGgfCA026985 for <@newsunmail1brm.central.sun.com:PSARC-EXT@Sun.COM>; Mon, 18 Jun 2007 09:42:42 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU00907BR5TC00@brm-avmta-1.central.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Mon, 18 Jun 2007 10:42:41 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU0064GBQWDD50@brm-avmta-1.central.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Mon, 18 Jun 2007 10:42:32 -0600 (MDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5IGgWt3021468; Mon, 18 Jun 2007 09:42:32 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l5IGgWrC008856; Mon, 18 Jun 2007 09:42:32 -0700 (PDT) Date: Mon, 18 Jun 2007 09:40:34 -0700 From: Bart Smaalders Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <20070618030309.00000827@localhost> To: Michael Hunter Cc: PSARC-EXT@sun.com Message-id: <4676B582.500@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> <20070618030309.00000827@localhost> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Status: RO Content-Length: 2005 Michael Hunter wrote: > On Thu, 14 Jun 2007 15:51:46 -0700 > Bart Smaalders wrote: > >> >> >> I'm sponsoring the attached fast track for Sherry Moore. The requested >> release boundary is patch/micro, and the case times out on 6/20/2007. > > It seems like the extra layer of authenticity that 2007/355 provides by > providing the updates via signed modules might to of value to our > customers. Eventhough I believe in the almost 10 years that intel > processor updates have been available there havn't been any trojan > horses just obfusacation of mechanism, the use of what has to be known > encryption keys by this point, and embedded checksums can't be much of > a barrier to create such. Additionally allowing these to be loaded > early in boot could make a simple denial of service trojan horse (one > that just loaded a bogus update intended to brick the machine) that > much more powerful and harder to diagnose. > > mph On the other hand, encapsulating Intel firmware inside Sun signed modules has the following real disadvantages: 1) customers must get patch from Sun to upgrade firmware; they cannot install firmware released by Intel. 2) Sun needs to release 2 versions of module - 32 and 64 bit, currently doubling impact on boot archive size. Sun signs their packages and patches; if the customer just gets his updates through our normal patch stream he will get the same protection as you're suggesting. If the customer wishes or needs to get the latest immediately from Intel (typical during development or bringup), he can do so easily, using the same protection mechanisms Intel has found sufficient so far. Unless we have some actual data indicating that additional levels of encryption/valiudation for the microcode is needed, I'm inclined to leave this as originally designed. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From sherry.moore@sun.com Mon Jun 18 09:45:10 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IGjAZH014039 for ; Mon, 18 Jun 2007 09:45:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5IGhYp2027217 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 18 Jun 2007 09:43:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU0051DBSMKB00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 18 Jun 2007 09:43:34 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU00KEDBSLNEF0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 18 Jun 2007 09:43:33 -0700 (PDT) Received: from geralyn.sfbay.sun.com (geralyn.SFBay.Sun.COM [129.146.226.228]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5IGhWbT024103; Mon, 18 Jun 2007 09:43:32 -0700 (PDT) Received: from geralyn.sfbay.sun.com (localhost [127.0.0.1]) by geralyn.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l5IGhWlr013183; Mon, 18 Jun 2007 09:43:32 -0700 (PDT) Received: (from sherrym@localhost) by geralyn.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l5IGhWqc013182; Mon, 18 Jun 2007 09:43:32 -0700 (PDT) Date: Mon, 18 Jun 2007 09:43:32 -0700 From: Sherry Moore Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <20070618030309.00000827@localhost> To: Michael Hunter Cc: Bart Smaalders , PSARC-EXT@sun.com Message-id: <20070618164332.GB12473@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> <20070618030309.00000827@localhost> X-Authentication-warning: geralyn.sfbay.sun.com: sherrym set sender to sherry.moore@sun.com using -f User-Agent: Mutt/1.4.1i Status: RO Content-Length: 2405 > It seems like the extra layer of authenticity that 2007/355 provides by > providing the updates via signed modules might to of value to our > customers. Eventhough I believe in the almost 10 years that intel > processor updates have been available there havn't been any trojan > horses just obfusacation of mechanism, the use of what has to be known > encryption keys by this point, and embedded checksums can't be much of > a barrier to create such. Additionally allowing these to be loaded > early in boot could make a simple denial of service trojan horse (one > that just loaded a bogus update intended to brick the machine) that > much more powerful and harder to diagnose. The possibility of malicious/bad microcode bricking a system has indeed been one of our biggest concerns. We have been talking with folks at Intel and below is what they can guarantee: ============================================================================ From rajesh.shah@intel.com Tue May 22 17:41:39 2007 - Intel processors have encryption/decryption in hardware to guarantee that they only execute microcode released from Intel intended for them. - If you force feed good (i.e. original Intel) microcode to the wrong CPU (wrong family, model, stepping...), it will ignore the update. If you try to feed bad (malicious/hand-crafted) ucode to a CPU, it will ignore it. The actual encryption scheme we use internally may change over time, but of course the attempt is to make it as hard to crack as possible. ============================================================================ The microcode update applied by the OS does not persist through reboot or power-cycle. If in the most unfortunate event that a bad microcode bricks the system, customer can recover by booting to failsafe mode, removing /platform/i86pc/ucode, then reboot. In any case, the premise of PSARC 2007/355 is that Most of other main-stream OSes provide interfaces to access firmware in raw-data format. But the shortage of the raw-data format is that authentication check is not available. Therefore, we prefer to wrap the raw-data format firmware image in a kernel module so that we can sign and verify it by elfsign. With processor microcode the data portion is actually an encrypted segment to be decrypted only by the processor so authentication is enforced by hardware. Thanks, Sherry From glenn.skinner@sun.com Mon Jun 18 09:52:08 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IGq7Yk014219 for ; Mon, 18 Jun 2007 09:52:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5IGoQGP013314 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 18 Jun 2007 17:50:31 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU00505C45WI00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 18 Jun 2007 09:50:29 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU005JDC44V400@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 18 Jun 2007 09:50:28 -0700 (PDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l5IGoSKI016917; Mon, 18 Jun 2007 09:50:28 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id l5IGdsKf016260; Mon, 18 Jun 2007 09:39:54 -0700 (PDT) Date: Mon, 18 Jun 2007 09:39:54 -0700 (PDT) From: Glenn Skinner Subject: Re: 2007/349 [Intel Microcode Update Support] To: PSARC-EXT@sun.com, bart.smaalders@sun.com Reply-to: Glenn Skinner Message-id: <200706181639.l5IGdsKf016260@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: ZuScdNoMsewxdoAPxxh1Ag== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1518 Date: Thu, 14 Jun 2007 15:51:46 -0700 From: Bart Smaalders Subject: PSARC/2007/349 Intel Microcode Update Support Extracting from the proposal: A new command ucodeadm(1M) is introduced to report processor microcode revision, install microcode files on a target system, and update microcode on a live system. # ucodeadm -h usage: ucodeadm -v Shows running microcode version. ucodeadm -u microcode-text-file Updates microcode to the latest matching version found in microcode-text-file. ucodeadm -i [-R path] microcode-text-file Installs microcode on the file system to be used during subsequent boot. ucodeadm will be installed in /usr/sbin/. Text for ucodeadm man page is attached as ucodeadm.man.txt. The -v option can be performed by a non-privileged user. The -i option requires privilege to write to the destination. The -u option requires privilege secpolicy_ucode_update(), which is currently PRIV_ALL. The privilege checking will be performed by the driver. User with "Maintenance and Repair" profile will be allowed to execute "/usr/sbin/ucodeadm -u" to update microcode. What privilege does the -i subcommand require? How does it compare to the secpolicy_ucode_update() privilege required for the -u subcommand? Presumably, the two subcommands require identical privilege, but it's best to be explicit. -- Glenn From sherry.moore@sun.com Mon Jun 18 09:56:21 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IGuKGI014623 for ; Mon, 18 Jun 2007 09:56:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l5IGsScB025891 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 19 Jun 2007 00:54:44 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU00605CB61U00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 18 Jun 2007 09:54:42 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU005DRCB5V420@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 18 Jun 2007 09:54:41 -0700 (PDT) Received: from geralyn.sfbay.sun.com (geralyn.SFBay.Sun.COM [129.146.226.228]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5IGsevB029716; Mon, 18 Jun 2007 09:54:40 -0700 (PDT) Received: from geralyn.sfbay.sun.com (localhost [127.0.0.1]) by geralyn.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l5IGse2r013200; Mon, 18 Jun 2007 09:54:40 -0700 (PDT) Received: (from sherrym@localhost) by geralyn.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l5IGseqj013199; Mon, 18 Jun 2007 09:54:40 -0700 (PDT) Date: Mon, 18 Jun 2007 09:54:40 -0700 From: Sherry Moore Subject: Re: 2007/349 [Intel Microcode Update Support] In-reply-to: <200706181639.l5IGdsKf016260@ivrel.sfbay.sun.com> To: Glenn Skinner Cc: PSARC-EXT@sun.com, bart.smaalders@sun.com Message-id: <20070618165440.GC12473@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200706181639.l5IGdsKf016260@ivrel.sfbay.sun.com> X-Authentication-warning: geralyn.sfbay.sun.com: sherrym set sender to sherry.moore@sun.com using -f User-Agent: Mutt/1.4.1i Status: RO Content-Length: 751 > The -i option requires privilege to write to the destination. > > The -u option requires privilege secpolicy_ucode_update(), > which is currently PRIV_ALL. The privilege checking will be > performed by the driver. User with "Maintenance and Repair" > profile will be allowed to execute "/usr/sbin/ucodeadm -u" to > update microcode. > > What privilege does the -i subcommand require? How does it compare to > the secpolicy_ucode_update() privilege required for the -u subcommand? > Presumably, the two subcommands require identical privilege, but it's > best to be explicit. Actually I meant to say The -i option requires write permission to the destination. It does not require secpolicy_ucode_update() privilege. Thanks, Sherry From glenn.skinner@sun.com Mon Jun 18 11:01:41 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5II1fsj017207 for ; Mon, 18 Jun 2007 11:01:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5II029u022519 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 18 Jun 2007 11:00:05 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU0050VFC4A200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 18 Jun 2007 11:00:04 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU0009DFC19440@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 18 Jun 2007 11:00:01 -0700 (PDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5II00VS021417; Mon, 18 Jun 2007 11:00:00 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id l5IHnRPB016453; Mon, 18 Jun 2007 10:49:27 -0700 (PDT) Date: Mon, 18 Jun 2007 10:49:27 -0700 (PDT) From: Glenn Skinner Subject: Re: 2007/349 [Intel Microcode Update Support] To: sherry.moore@sun.com Cc: PSARC-EXT@sun.com, bart.smaalders@sun.com Reply-to: Glenn Skinner Message-id: <200706181749.l5IHnRPB016453@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: kjkGfy9a+nPauW1pfzck/w== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1171 Date: Mon, 18 Jun 2007 09:54:40 -0700 From: Sherry Moore Subject: Re: 2007/349 [Intel Microcode Update Support] > The -i option requires privilege to write to the destination. > > The -u option requires privilege secpolicy_ucode_update(), > which is currently PRIV_ALL. The privilege checking will be > performed by the driver. User with "Maintenance and Repair" > profile will be allowed to execute "/usr/sbin/ucodeadm -u" to > update microcode. > > What privilege does the -i subcommand require? How does it > compare to the secpolicy_ucode_update() privilege required for > the -u subcommand? Presumably, the two subcommands require > identical privilege, but it's best to be explicit. Actually I meant to say The -i option requires write permission to the destination. It does not require secpolicy_ucode_update() privilege. Does that create a way for a user with privilege less than secpolicy_ucode_update() to arrange to update microcode by writing it to the location from which it will be read on a subsequent boot and then rebooting? -- Glenn From sherry.moore@sun.com Mon Jun 18 11:12:06 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IIC5Ax017827 for ; Mon, 18 Jun 2007 11:12:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5IIARmn009669 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 18 Jun 2007 19:10:28 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU00909FTFDF00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 18 Jun 2007 11:10:27 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU007JMFTFB640@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 18 Jun 2007 11:10:27 -0700 (PDT) Received: from geralyn.sfbay.sun.com (geralyn.SFBay.Sun.COM [129.146.226.228]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l5IIAQKa009446; Mon, 18 Jun 2007 11:10:26 -0700 (PDT) Received: from geralyn.sfbay.sun.com (localhost [127.0.0.1]) by geralyn.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l5IIAQIR013361; Mon, 18 Jun 2007 11:10:26 -0700 (PDT) Received: (from sherrym@localhost) by geralyn.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l5IIAQRi013360; Mon, 18 Jun 2007 11:10:26 -0700 (PDT) Date: Mon, 18 Jun 2007 11:10:26 -0700 From: Sherry Moore Subject: Re: 2007/349 [Intel Microcode Update Support] In-reply-to: <200706181749.l5IHnRPB016453@ivrel.sfbay.sun.com> To: Glenn Skinner Cc: sherry.moore@sun.com, PSARC-EXT@sun.com, bart.smaalders@sun.com Message-id: <20070618181025.GF12473@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200706181749.l5IHnRPB016453@ivrel.sfbay.sun.com> X-Authentication-warning: geralyn.sfbay.sun.com: sherrym set sender to sherry.moore@sun.com using -f User-Agent: Mutt/1.4.1i Status: RO Content-Length: 738 > Actually I meant to say > > The -i option requires write permission to the destination. > > It does not require secpolicy_ucode_update() privilege. > > Does that create a way for a user with privilege less than > secpolicy_ucode_update() to arrange to update microcode by writing it > to the location from which it will be read on a subsequent boot and > then rebooting? > > -- Glenn Yes. If a system allows a user with privilege less than secpolicy_ucode_update() to write to /platform/i86pc/ucode, which is of the following mode, d none platform/i86pc/ucode 755 root sys then this user will be able to arrange microcode update by writing it to the location to be used on subsequent boot. Thanks, Sherry From casper@holland.sun.com Mon Jun 18 11:16:27 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IIGR7I018027 for ; Mon, 18 Jun 2007 11:16:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5IIEm5u019758; Mon, 18 Jun 2007 11:14:51 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU0090LG0QIS00@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Jun 2007 11:14:50 -0700 (PDT) Received: from sr1-eaft06-01.holland.sun.com ([129.159.237.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU00704G0PB650@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Jun 2007 11:14:50 -0700 (PDT) Received: from holland (room101 [129.159.130.93]) by sr1-eaft06-01.holland.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IIEnpR021242; Mon, 18 Jun 2007 20:14:49 +0200 (MEST) Date: Mon, 18 Jun 2007 20:14:48 +0200 From: Casper.Dik@sun.com Subject: Re: 2007/349 [Intel Microcode Update Support] In-reply-to: <20070618181025.GF12473@sun.com> Sender: casper@holland.sun.com To: Sherry Moore Cc: Glenn Skinner , PSARC-EXT@sun.com, bart.smaalders@sun.com Message-id: <200706181814.l5IIEnpR021242@sr1-eaft06-01.holland.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706181749.l5IHnRPB016453@ivrel.sfbay.sun.com> <20070618181025.GF12473@sun.com> Status: RO Content-Length: 950 >> Actually I meant to say >> >> The -i option requires write permission to the destination. >> >> It does not require secpolicy_ucode_update() privilege. >> >> Does that create a way for a user with privilege less than >> secpolicy_ucode_update() to arrange to update microcode by writing it >> to the location from which it will be read on a subsequent boot and >> then rebooting? >> >> -- Glenn > >Yes. If a system allows a user with privilege less than >secpolicy_ucode_update() to write to /platform/i86pc/ucode, which is of >the following mode, > > d none platform/i86pc/ucode 755 root sys > >then this user will be able to arrange microcode update by writing it >to the location to be used on subsequent boot. But such a location would normally either require all privileges or root; stronger protections are currently not on offer. And since the microcode is signed, the only risk is perhaps downgrading? Casper From sommerfeld@sun.com Mon Jun 18 11:40:37 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IIebbg018416 for ; Mon, 18 Jun 2007 11:40:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5IId2c3026123; Mon, 18 Jun 2007 11:39:02 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU00803H51QX00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 18 Jun 2007 11:39:01 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU000E4H509160@nwk-avmta-1.sfbay.Sun.COM>; Mon, 18 Jun 2007 11:39:01 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5IIcvbV011135; Mon, 18 Jun 2007 14:38:57 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IIcvbY000077; Mon, 18 Jun 2007 14:38:57 -0400 (EDT) Date: Mon, 18 Jun 2007 14:38:55 -0400 From: Bill Sommerfeld Subject: Re: 2007/349 [Intel Microcode Update Support] In-reply-to: <200706181814.l5IIEnpR021242@sr1-eaft06-01.holland.sun.com> To: Casper.Dik@sun.com Cc: Sherry Moore , Glenn Skinner , PSARC-EXT@sun.com Message-id: <1182191935.28165.15.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706181749.l5IHnRPB016453@ivrel.sfbay.sun.com> <20070618181025.GF12473@sun.com> <200706181814.l5IIEnpR021242@sr1-eaft06-01.holland.sun.com> Status: RO Content-Length: 571 On Mon, 2007-06-18 at 20:14 +0200, Casper.Dik@sun.com wrote: > And since the microcode is signed, the only risk is perhaps downgrading? If the reason for the firmware upgrade is to fix a security hole, preventing downgrades is important. Though there's an additional risk -- that the undocumented signature validation mechanism for the firmware upgrade blob is reverse engineered and found to be weak. I find it worth noting that the structures defined in this case include 32-bit checksums. I really hope that's not the only "signature" involved... - Bill From Nicolas.Williams@sun.com Mon Jun 18 11:42:54 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IIgrHq018561 for ; Mon, 18 Jun 2007 11:42:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l5IIes9E000393; Tue, 19 Jun 2007 02:41:11 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU00H0BH8N8U00@brm-avmta-1.central.sun.com>; Mon, 18 Jun 2007 12:41:11 -0600 (MDT) Received: from localhost.Central.Sun.COM ([129.153.128.213]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU0061VH8MDMC0@brm-avmta-1.central.sun.com>; Mon, 18 Jun 2007 12:41:10 -0600 (MDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l5IIeEMN024519; Mon, 18 Jun 2007 13:40:14 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l5IIeDjk024518; Mon, 18 Jun 2007 13:40:13 -0500 (CDT) Date: Mon, 18 Jun 2007 13:40:13 -0500 From: Nicolas Williams Subject: Re: 2007/349 [Intel Microcode Update Support] In-reply-to: <1182191935.28165.15.camel@thunk> To: Bill Sommerfeld Cc: Casper.Dik@sun.com, Sherry Moore , Glenn Skinner , PSARC-EXT@sun.com Message-id: <20070618184013.GH24098@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200706181749.l5IHnRPB016453@ivrel.sfbay.sun.com> <20070618181025.GF12473@sun.com> <200706181814.l5IIEnpR021242@sr1-eaft06-01.holland.sun.com> <1182191935.28165.15.camel@thunk> X-Authentication-warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 495 On Mon, Jun 18, 2007 at 02:38:55PM -0400, Bill Sommerfeld wrote: > Though there's an additional risk -- that the undocumented signature > validation mechanism for the firmware upgrade blob is reverse engineered > and found to be weak. I find it worth noting that the structures > defined in this case include 32-bit checksums. I really hope that's not > the only "signature" involved... Are the algorithms used by Intel public? If not then that's an additional reason to do our own signing. From sommerfeld@Sun.COM Mon Jun 18 12:27:17 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IJRHNx020054 for ; Mon, 18 Jun 2007 12:27:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5IJP97S010244; Mon, 18 Jun 2007 13:25:10 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU00J03JASU100@brm-avmta-1.central.sun.com>; Mon, 18 Jun 2007 13:25:40 -0600 (MDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU00ITMJARSJ20@brm-avmta-1.central.sun.com>; Mon, 18 Jun 2007 13:25:39 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5IJPaH0027494; Mon, 18 Jun 2007 15:25:36 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5IJPa8m000300; Mon, 18 Jun 2007 15:25:36 -0400 (EDT) Date: Mon, 18 Jun 2007 15:25:34 -0400 From: Bill Sommerfeld Subject: Re: 2007/349 [Intel Microcode Update Support] In-reply-to: <20070618184013.GH24098@Sun.COM> To: Nicolas Williams Cc: Casper.Dik@Sun.COM, Sherry Moore , Glenn Skinner , PSARC-EXT@Sun.COM Message-id: <1182194734.28165.28.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706181749.l5IHnRPB016453@ivrel.sfbay.sun.com> <20070618181025.GF12473@sun.com> <200706181814.l5IIEnpR021242@sr1-eaft06-01.holland.sun.com> <1182191935.28165.15.camel@thunk> <20070618184013.GH24098@Sun.COM> Status: RO Content-Length: 1060 On Mon, 2007-06-18 at 13:40 -0500, Nicolas Williams wrote: > Are the algorithms used by Intel public? If not then that's an > additional reason to do our own signing. They're not. Starting from: http://developer.intel.com/products/processor/manuals/index.htm I found: "Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide" see section 9.11 of: http://developer.intel.com/design/processor/manuals/253668.pdf assuming I'm reading this correctly, intel recommends that (a) software using this interface verify that the microcode blob checksums correctly (using a sum of the blob interpreted as an array of 32-bit integers) before attempting the load, and (b) software verify that the the microcode blob is for the CPU that's running. The document also states that the CPU will do additional tests before accepting the blob but says nothing about what they are or how strong they are. BTW, to make it easier to find, I put a copy of this PDF into the case directory as "ia32-sdm-3A.pdf". - Bill From Michael.Hunter@sun.com Mon Jun 18 14:30:14 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5ILUEio023613 for ; Mon, 18 Jun 2007 14:30:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5ILSP76015544; Mon, 18 Jun 2007 22:28:36 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU00I03OZNG300@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Jun 2007 14:28:35 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU00G0ZOZM2B30@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Jun 2007 14:28:34 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l5ILSYWY009078; Mon, 18 Jun 2007 14:28:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JJU00K01OMK8100@fe-sfbay-09.sun.com> (original mail from Michael.Hunter@Sun.COM); Mon, 18 Jun 2007 14:28:34 -0700 (PDT) Received: from sun.com ([10.7.251.174]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJU00E8KOZGOR60@fe-sfbay-09.sun.com>; Mon, 18 Jun 2007 14:28:28 -0700 (PDT) Date: Mon, 18 Jun 2007 14:28:28 -0700 From: Michael Hunter Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <20070618164332.GB12473@sun.com> Sender: Michael.Hunter@sun.com To: Sherry Moore Cc: Bart Smaalders , PSARC-EXT@sun.com Message-id: <20070618142828.00004930@localhost> Organization: SMI MIME-version: 1.0 X-Mailer: Claws Mail 2.9.2-csw (GTK+ 2.10.11; i386-pc-solaris2.8) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> <20070618030309.00000827@localhost> <20070618164332.GB12473@sun.com> Status: RO Content-Length: 1149 On Mon, 18 Jun 2007 09:43:32 -0700 Sherry Moore wrote: [...] > - If you force feed good (i.e. original Intel) microcode to the wrong > CPU (wrong family, model, stepping...), it will ignore the update. If > you try to feed bad (malicious/hand-crafted) ucode to a CPU, it will > ignore it. The actual encryption scheme we use internally may change > over time, but of course the attempt is to make it as hard to crack > as possible. [...] This was the part I was missing. I knew there was encryption on the data part but I thought that was undone before feeding to the processor. If its done afterwards that sounds better. Its smacks of security by obscurity that we have to take them at their word that it will be "as hard to crack as possible" with no chance for a community wide analysis but it does mediate the concern some and (fwiw) might transfer the blame if the protection was broken and used in a malicious manner. That together with the fact that the only time they would be doing this with suspect ucode would be if they needed a microcode update inbetween OS updates seems reasonable to me. mph From Nicolas.Williams@sun.com Mon Jun 18 14:38:35 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5ILcZ3G023718 for ; Mon, 18 Jun 2007 14:38:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5ILatMx017992; Mon, 18 Jun 2007 22:36:57 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU00503PDJAR00@brm-avmta-1.central.sun.com>; Mon, 18 Jun 2007 15:36:55 -0600 (MDT) Received: from localhost.Central.Sun.COM ([129.153.128.213]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU0007XPDIL880@brm-avmta-1.central.sun.com>; Mon, 18 Jun 2007 15:36:55 -0600 (MDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l5ILZwVI024678; Mon, 18 Jun 2007 16:35:58 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l5ILZwHX024677; Mon, 18 Jun 2007 16:35:58 -0500 (CDT) Date: Mon, 18 Jun 2007 16:35:58 -0500 From: Nicolas Williams Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <20070618142828.00004930@localhost> To: Michael Hunter Cc: Sherry Moore , Bart Smaalders , PSARC-EXT@sun.com Message-id: <20070618213557.GO24098@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> <20070618030309.00000827@localhost> <20070618164332.GB12473@sun.com> <20070618142828.00004930@localhost> X-Authentication-warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1385 On Mon, Jun 18, 2007 at 02:28:28PM -0700, Michael Hunter wrote: > This was the part I was missing. I knew there was encryption on the > data part but I thought that was undone before feeding to the > processor. If its done afterwards that sounds better. Its smacks of > security by obscurity that we have to take them at their word that it > will be "as hard to crack as possible" with no chance for a community > wide analysis but it does mediate the concern some and (fwiw) might > transfer the blame if the protection was broken and used in a malicious > manner. That together with the fact that the only time they would be > doing this with suspect ucode would be if they needed a microcode > update inbetween OS updates seems reasonable to me. Is there security value in Intel's encrypting this data? IMO, not much. I suspect that's there only for protecting Intel's trade secrets, not for security. For Intel's customers the security value should come from the cryptographic integrity protection scheme used by Intel, but we have no details, therefore can't form an opinion as to how good that is. I think providing additional security here through signing files would be good, but I'm not sure that the ARC cares or should care to force the matter, particularly if adding this module to the boot archive has significantly negative impact on boot archive size. Nico -- From Sherry.Moore@Sun.COM Mon Jun 18 14:39:33 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5ILdXkH023733 for ; Mon, 18 Jun 2007 14:39:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5ILbuWo005111; Mon, 18 Jun 2007 14:37:57 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJU0050VPF8FT00@brm-avmta-1.central.sun.com>; Mon, 18 Jun 2007 15:37:56 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU000BDPF7L880@brm-avmta-1.central.sun.com>; Mon, 18 Jun 2007 15:37:56 -0600 (MDT) Received: from geralyn.sfbay.sun.com (geralyn.SFBay.Sun.COM [129.146.226.228]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5ILbr7i000809; Mon, 18 Jun 2007 14:37:53 -0700 (PDT) Received: from geralyn.sfbay.sun.com (localhost [127.0.0.1]) by geralyn.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l5ILbrHT013894; Mon, 18 Jun 2007 14:37:53 -0700 (PDT) Received: (from sherrym@localhost) by geralyn.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l5ILbrVB013893; Mon, 18 Jun 2007 14:37:53 -0700 (PDT) Date: Mon, 18 Jun 2007 14:37:53 -0700 From: Sherry Moore Subject: Re: 2007/349 [Intel Microcode Update Support] In-reply-to: <1182194734.28165.28.camel@thunk> To: Bill Sommerfeld Cc: Nicolas Williams , Casper.Dik@Sun.COM, Sherry Moore , Glenn Skinner , PSARC-EXT@Sun.COM Message-id: <20070618213753.GK12473@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200706181749.l5IHnRPB016453@ivrel.sfbay.sun.com> <20070618181025.GF12473@sun.com> <200706181814.l5IIEnpR021242@sr1-eaft06-01.holland.sun.com> <1182191935.28165.15.camel@thunk> <20070618184013.GH24098@Sun.COM> <1182194734.28165.28.camel@thunk> X-Authentication-warning: geralyn.sfbay.sun.com: sherrym set sender to sherry.moore@sun.com using -f User-Agent: Mutt/1.4.1i Status: RO Content-Length: 1599 You are reading the document correctly. The implementation of this project will 1. verify the 32-bit unsigned checksum 2. verify that microcode is intended for the target CPU before attempting to apply the microcode. The checksum algorithm is very weak and I think it is only in place to filter out the most obvious hacks/mistakes. The true and most vigorous authentication is done by hardware. Thanks, Sherry On Mon, Jun 18, 2007 at 03:25:34PM -0400, Bill Sommerfeld wrote: > On Mon, 2007-06-18 at 13:40 -0500, Nicolas Williams wrote: > > Are the algorithms used by Intel public? If not then that's an > > additional reason to do our own signing. > > They're not. Starting from: > http://developer.intel.com/products/processor/manuals/index.htm > > I found: > > "Intel 64 and IA-32 Architectures Software Developer's Manual > Volume 3A: System Programming Guide" > > see section 9.11 of: > > http://developer.intel.com/design/processor/manuals/253668.pdf > > assuming I'm reading this correctly, intel recommends that (a) software > using this interface verify that the microcode blob checksums correctly > (using a sum of the blob interpreted as an array of 32-bit integers) > before attempting the load, and (b) software verify that the the > microcode blob is for the CPU that's running. > > The document also states that the CPU will do additional tests before > accepting the blob but says nothing about what they are or how strong > they are. > > BTW, to make it easier to find, I put a copy of this PDF into the case > directory as "ia32-sdm-3A.pdf". > > - Bill From edward.pilatowicz@sun.com Mon Jun 18 22:41:49 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5J5fnPt000920 for ; Mon, 18 Jun 2007 22:41:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5J5eAFR027974 for <@newsunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Mon, 18 Jun 2007 22:40:13 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJV00G07BR0MG00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 18 Jun 2007 23:40:12 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJV008N4BR04X50@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 18 Jun 2007 23:40:12 -0600 (MDT) Received: from mcescher.eng.sun.com (mcescher.SFBay.Sun.COM [129.146.224.55]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5J5eBKU003655; Mon, 18 Jun 2007 22:40:11 -0700 (PDT) Received: from mcescher.eng.sun.com (localhost [127.0.0.1]) by mcescher.eng.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5J5eAYa923369; Mon, 18 Jun 2007 22:40:10 -0700 (PDT) Received: (from edp@localhost) by mcescher.eng.sun.com (8.14.1+Sun/8.14.1/Submit) id l5J5eA4g923368; Mon, 18 Jun 2007 22:40:10 -0700 (PDT) Date: Mon, 18 Jun 2007 22:40:10 -0700 From: Edward Pilatowicz Subject: Re: PSARC/2007/349 Intel Microcode Update Support In-reply-to: <4676B582.500@Sun.COM> To: Bart Smaalders Cc: Michael Hunter , PSARC-EXT@sun.com Message-id: <20070619054010.GA922884@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <4671C682.5050402@Sun.COM> <20070618030309.00000827@localhost> <4676B582.500@Sun.COM> X-Authentication-warning: mcescher.eng.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 2366 On Mon, Jun 18, 2007 at 09:40:34AM -0700, Bart Smaalders wrote: > Michael Hunter wrote: > >On Thu, 14 Jun 2007 15:51:46 -0700 > >Bart Smaalders wrote: > > > >> > >> > >>I'm sponsoring the attached fast track for Sherry Moore. The requested > >>release boundary is patch/micro, and the case times out on 6/20/2007. > > > >It seems like the extra layer of authenticity that 2007/355 provides by > >providing the updates via signed modules might to of value to our > >customers. Eventhough I believe in the almost 10 years that intel > >processor updates have been available there havn't been any trojan > >horses just obfusacation of mechanism, the use of what has to be known > >encryption keys by this point, and embedded checksums can't be much of > >a barrier to create such. Additionally allowing these to be loaded > >early in boot could make a simple denial of service trojan horse (one > >that just loaded a bogus update intended to brick the machine) that > >much more powerful and harder to diagnose. > > > > mph > > On the other hand, encapsulating Intel firmware inside Sun signed > modules has the following real disadvantages: > > 1) customers must get patch from Sun to upgrade firmware; they cannot > install firmware released by Intel. > 2) Sun needs to release 2 versions of module - 32 and 64 bit, > currently doubling impact on boot archive size. > it's probably worth mentioning that while we would need to release two versions of the module, this really wouldn't double the size of data added to a boot archive since there are seperate boot archives for 32 and 64-bit booting. > Sun signs their packages and patches; if the customer just gets > his updates through our normal patch stream he will get the same > protection as you're suggesting. > > If the customer wishes or needs to get the latest immediately from > Intel (typical during development or bringup), he can do so easily, > using the same protection mechanisms Intel has found sufficient so far. > > Unless we have some actual data indicating that additional levels of > encryption/valiudation for the microcode is needed, I'm inclined to > leave this as originally designed. > > - Bart > > > -- > Bart Smaalders Solaris Kernel Performance > barts@cyber.eng.sun.com http://blogs.sun.com/barts From bart.smaalders@sun.com Wed Jun 20 19:06:50 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5L26nBb016964 for ; Wed, 20 Jun 2007 19:06:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l5L254FQ019759 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@Sun.COM>; Thu, 21 Jun 2007 10:05:10 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJY00803R4J7T00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Wed, 20 Jun 2007 19:05:07 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJY00IZBR4IKR90@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Wed, 20 Jun 2007 19:05:06 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5L256Yx022880 for ; Wed, 20 Jun 2007 19:05:06 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l5L256x7026731 for ; Wed, 20 Jun 2007 19:05:06 -0700 (PDT) Date: Wed, 20 Jun 2007 19:03:08 -0700 From: Bart Smaalders Subject: PSARC 2007/349 Intel Microcode Update Suppor To: PSARC-EXT@sun.com Message-id: <4679DC5C.7020100@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Status: RO Content-Length: 164 This fast track was approved at today's PSARC meeting. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts