From owner-freebsd-arch@freebsd.org Thu Jul 12 18:15:41 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 23CF8102F4F6 for ; Thu, 12 Jul 2018 18:15:41 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6A93B76DC4 for ; Thu, 12 Jul 2018 18:15:40 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id 2E445102F4F0; Thu, 12 Jul 2018 18:15:40 +0000 (UTC) Delivered-To: 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 0A234102F4EF for ; Thu, 12 Jul 2018 18:15:40 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "thawte SHA256 SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62BD976DBC; Thu, 12 Jul 2018 18:15:39 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6CI9wwS021721; Thu, 12 Jul 2018 11:15:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=5xNSKNgSU13fBCS3W/ZaZa8W/Cyde5UhRR4pG+yk41o=; b=YSGL5OB5GuxNa2OUYhwTGmSx9vC/yGGACGflBqjTw0sL4H8xPswlrSPOgql60tWWvHXX CruKlc6dot7mdWlTv04IglwbfxvMDsyQtBgwTCRwv63oOca4LluicHw2vQt9tPGHZEtR smvCkPyL3/QU/3tyfW24kpL1bwLNesR/bG3jMJVXo3cusEfmI+rRRC/6u19A7Jjel16G SwKw1C/wc2MPPYtaE7u8lasIsQeanNwe+iOabi6YZ+kieFgA3ZRGmk/vS5fXgvAKPIiW ej99IT3EXp41srchRpBxst5xM+kcCDfZ/y4JFgW/3ExqQqW39at8Bb+Gizz3RdW2xutq AQ== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp0055.outbound.protection.outlook.com [216.32.181.55]) by mx0b-00273201.pphosted.com with ESMTP id 2k6an387ax-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Jul 2018 11:15:38 -0700 Received: from DM5PR05CA0060.namprd05.prod.outlook.com (2603:10b6:4:39::49) by DM5PR05MB3178.namprd05.prod.outlook.com (2603:10b6:3:c7::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.7; Thu, 12 Jul 2018 18:15:36 +0000 Received: from DM3NAM05FT030.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::203) by DM5PR05CA0060.outlook.office365.com (2603:10b6:4:39::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.952.15 via Frontend Transport; Thu, 12 Jul 2018 18:15:35 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.242.13 as permitted sender) Received: from P-EXFEND-EQX-02.jnpr.net (66.129.242.13) by DM3NAM05FT030.mail.protection.outlook.com (10.152.98.142) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.973.9 via Frontend Transport; Thu, 12 Jul 2018 18:15:35 +0000 Received: from P-EXFEND-EQX-02.jnpr.net (10.104.8.55) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 12 Jul 2018 11:14:34 -0700 Received: from P-EMFE01C-SAC.jnpr.net (172.24.192.43) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.847.32 via Frontend Transport; Thu, 12 Jul 2018 11:14:34 -0700 Received: from p-mailhub01.juniper.net (10.47.226.20) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 12 Jul 2018 11:14:34 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id w6CIEXWR009751; Thu, 12 Jul 2018 11:14:34 -0700 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id E3A2611711; Thu, 12 Jul 2018 11:14:33 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id E343811710; Thu, 12 Jul 2018 11:14:33 -0700 (PDT) To: , "freebsd-arch@freebsd.org" , "Stephen J. Kiernan" , Subject: Re: Veriexec In-Reply-To: <88827.1530660165@kaos.jnpr.net> References: <88827.1530660165@kaos.jnpr.net> Comments: In-reply-to: "Simon J. Gerraty" message dated "Tue, 03 Jul 2018 16:22:45 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6312.1531419273.1@kaos.jnpr.net> Date: Thu, 12 Jul 2018 11:14:33 -0700 Message-ID: <8666.1531419273@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.242.13; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(136003)(376002)(39860400002)(396003)(2980300002)(69234005)(199004)(189003)(55674003)(2810700001)(97756001)(106466001)(6266002)(450100002)(186003)(97736004)(23726003)(7116003)(5660300001)(2906002)(229853002)(476003)(9686003)(53936002)(68736007)(7126003)(305945005)(11346002)(50466002)(221733001)(90966002)(69596002)(8676002)(8936002)(55016002)(117636001)(3480700004)(14444005)(50226002)(336012)(446003)(356003)(81166006)(86362001)(478600001)(110136005)(47776003)(76506005)(26005)(46406003)(105596002)(26826003)(486006)(77096007)(97876018)(16586007)(53416004)(6246003)(1941001)(7696005)(81156014)(126002)(316002)(76176011)(2101003)(42262002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3178; H:P-EXFEND-EQX-02.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT030; 1:H6lsD8NC3DOGepLJtzqP0F09+uHLdCuAwHgVUhhm2s1ta0f39vTmZw4TaxjioFc1lxn6/LyXdk1pmJNUMFyusQVYxEMpHGSusKSNy/U2wmbGAnDyrIjDOE/I6OIGKyJ4 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7455ed38-127c-4672-9f55-08d5e82376cc X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060); SRVR:DM5PR05MB3178; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3178; 3:3eaSLXM4P5Ktps2EhMRyPwyXnL84gZ583l5io/1eurb3DBOH5iSwJLUUBsOEQjTS1ErxGWp7ZIefx/HA71OAs2pb5Xp+Rr4Qq4T1H6iuEK+jRh14dEVy9Y89uuEf5aKppFhks1EcqHJ484Me33aNUUfkmfXnicUL6F0WZB93PZ7yu4xjEwIxpNW85JYc0DSYXrcTtqsLLTdvbQF/bvQVTsAfxgnXzKvjCfj/EzOYuf4xIHuc3EwRHGPsAsYFVndqq+Z5TFX4kgB65O9E+f1ng/S0agLKr6rHMcpb5TSZAfhizADXP0kNq0TQ+Eg/MO+aocp3Ur79TmxDCBCRzvNIn9m7WglP8rhPpbxsu6a0U/g=; 25:Z2FqDS4dWz4bPF4pvyhy67IZpzvZuhe5El0PVQPAdVf7pwBtqk9augmv7xVdqO0ih28NlOAiS+DKV5vL6roK6w7ujFwRWeMC6crpmqqkoN9MJDR+2BehNNS6swpO3BK55qzlFSLGRPYTY9Ko0aXwMUNPq8w7slFdE6diJyTzEAAjjiWQewXBfWyvkyn8tiZS5hpf65CcsQMBeQTyv+qWTk9P6df9vp1m0cYD8LcALCyBTLmqKrjq5jfT/XeSkRioTqV1kky0068Bh07VH/EXwmWDwRsDzfAgv8C8ZpTdkBweJVGmDy86QJY4Io4LC9e8I5vK+P44Ah5Thz7YaQuttw== X-MS-TrafficTypeDiagnostic: DM5PR05MB3178: X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3178; 31:Hc1O6LVDneEfvALVWWG779zitkpFvKGd4RU3DQzRmMRQv1M5dk6N5tnEleJOKWSXiDrXv+NFlT89KiA3/mYXy+IW50V1dFSVx2KYGLdzboUOO0GFXrw6CWL/bfLdWAqZhDgWB6bwakvBjF0pEcs3Dg3N0C+ptWi1WnVvLYLCC5iIPhEXbpvcMsjhOgRwqt7K9BiI8UXSrNrM17s9icaUjTe1R1GO2RpnFb5jE66g0tQ=; 20:1Umhuhl2PIWOJGFcCPDRWVc6CRswTVLDV97o+3cSVQecz+N5ZWQEwakyjFsEg1lzJA/rKSDmtdsQX+zk5HKNwUIN1veFXQuGHNMoaVlvCQZ1yLMXgFY14uPUROu79eFtFiIeENPx97odw8fcNt7jNeRWJTL4nXXavfo0gKzNXK4dgpIi4PjZg7lPhCQvGm/UtZX4gM9dZs3nUaeY/w0rQteBHtDuNCBRy1Nd7KIqLUjigbvvH/ddabpA5cHNRsyXZzDUwAN4daQnJoplUHRT+xn0WAU4+urxKAa4nhQvQgmMiz01OW8ZZ9uEbniOdMmGz2iNgK/+ccrUBfP9rYeg+ndH71IRBtOEnKTaB2SeXO+nfZwxK0UxlPlzDSlCU4hiVuA9i/ce7PtHVjbNSJUgE4cujmEVLEvyOv5g54J99ji6zQN5PBnXLz2wb76Gys4SzPsUkLzSdEBeC0JBXnzpmRGo5jCaTUlH14BHqD55Ag157s9onwdMBbP7Vb2Dtc6s X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93003095)(10201501046)(3002001)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DM5PR05MB3178; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3178; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3178; 4:M6UENrwU0oIs4VUesFW8/MAl2icdGC6yt1ph+Th+Ee+Ne5js5MF8MBzZ3yuiSOgZbpaCaVmCOumiQpnZTqZgRUzc/YkaTM6kc6aZQNzSucZ6WsTXtYEMRxj4UxMQaqR0n0OE1YLML+lH8wWrYmxEz3yRda1tEwPkabVgHrtmEg/naMQ70ua/j3roQgNp0RTnO7D1VKZkhPHdNGj0m2z63zgSJZpOJAjSLaU0CL2QQbPwQ8XHFdaLnCuHHulLHf8MqKt/k9d+xP8MVVvhCmqWpwPceRixoPC/pvcyuGxNljmby15vJUBPveoFiAmpl2NH X-Forefront-PRVS: 0731AA2DE6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB3178; 23:ZZyLmveX1htnRI9s4cH3WcxOAssUEintPyK5t3QML?= =?us-ascii?Q?bQ8lwu18HIDRJJpA5ckVvWsk4cI5dRSRTshXpWen5qVTseXrVcQPzBblMGsn?= =?us-ascii?Q?46uYaFhHDZZMz3gaJBt8aF8g1BSG6t1xK+hBz9ZFkVt6Eqofrpx+sUhS6dZ6?= =?us-ascii?Q?gxovKCA6eCYL1OSy5RRdzshhQu70PMWi9HM7kfQwTHcVNFq7XPrkd/wOf1py?= =?us-ascii?Q?k0IqEOf1fvThl68ZKtixonalMovr9xrEZPHPAqAubrDsVgAFvcU71XJ6MMk0?= =?us-ascii?Q?TvhGyMYoVwAY+ErkMVXp9TkzJGZMcZP2+AJve6kiVnOwhH421A90Q0UvFmJI?= =?us-ascii?Q?a+d7L2BsmGnWy2OplWmIDXCvLnAz5p1CpYRudAxeXpIMVGcIygg/MWhdaeW5?= =?us-ascii?Q?ZzhMfVuD0dJtBNLRv/tN6INzKN80itlBe9PkyIzchcFtP0mtdHioQRrcycr9?= =?us-ascii?Q?PDEztDgUJzBItTZfy//i0Qf/O1JMOPpYo3YLQ9SqQk2h6OEQHCGSF+lzUdXi?= =?us-ascii?Q?PEk1yKsusadUaBemG1nKiVIDhIByvslpL/LbTl1TdhGolUO7/RkG/QBy8uag?= =?us-ascii?Q?ffB4WBUEPjmVDB/A1HxV9/eR1nRxxP9x+PKVGYF+RD8uYhy66xASH3MfcRup?= =?us-ascii?Q?NfHqSafEIJbq5NivgKMR6RAEODHGYkFLUKt6bxsCxc8SjRjjzb4JsGo/VahK?= =?us-ascii?Q?kUtY0+Z/yUOc1RzltBdCfy6wRcsYIec0UjECy5u/WWjbexHtM950lB8YITJD?= =?us-ascii?Q?SF/5bzrAW1jbZTeb5sg8gYf9sM0NRfS3zm3MpLz3UvCLnZiLeBMzF9eq+q4p?= =?us-ascii?Q?Qt4+14/1biXkqSho5gWWepGjiDzrsTIj737vYS9TnfjxEzi6aE2AS1qA7710?= =?us-ascii?Q?oKA3ZFma6epnx/JJQ+Cd6lw0bFnb7HRf04tJ1d1Px2iiO+PVljJ5UmsZG8W7?= =?us-ascii?Q?MRiCPPbnShK9j8VZWnM7G2ZsUpQ9iVDPzFUa70fasfoAgI9yj6HVnmiQY/65?= =?us-ascii?Q?oqlVv7lYTjcHvVWWlKxfAgaIiNrE8KZ38o6rkxf4C19Z5u2DP1e+F3LimCXt?= =?us-ascii?Q?TVFQMPIS7vxw7JaDCZity0z0SpohJHhhlTxOhv6ZO/sUDftJ90wL7fbYk13B?= =?us-ascii?Q?KINNH268s3aFtPoKAN+1qv2jZumemyZLFsMITBIHaVPOSeuJbRPCkVW49rkZ?= =?us-ascii?Q?IKdLHaVo2kzyIIje03z4G8shr06ld+51sbOg0whnqzzt+DB7ftG/VNX9EW3N?= =?us-ascii?Q?3powi3H4iEvZZESOPufznSa0tk9DucyXK3kMux1Y/VROlkDknfXySPTqepsS?= =?us-ascii?Q?ZIxAb6V8CMTXfFvcRJ2dg3pEh25K03WHANq/3phIoxOVedifK0kdeRbWWo7X?= =?us-ascii?Q?bvE3gLtas/XYTKY/rNJTLXwHu8+Z4oEFOp8gwLy5t1sJbiJVgKfaIHI9dKD1?= =?us-ascii?Q?C4P18xKX6xnmRIPYBn711GG/jWmhQIRUGtWGUSCvFAUI757QpmmuCxglFzOM?= =?us-ascii?Q?p8VSq6bIVAl+NncBVbwcpjDE/LldYzt0KA=3D?= X-Microsoft-Antispam-Message-Info: /5Y3dxltA0BF0KAyjT3QrWL8pAy0RZLwCDUUQ9VWPB4iAq5m7c4eTvDxgUXYkoeBImqpL8DUwpxgvCwYRKiyKhuQiRmlnuoEaVJK5ZkcxWFgqVXJJ54D6Xb4mPHVHBWx3XSbZuFfeJ1C6Ex09+bybWqa75p0Cb686sHVBBZe8QftTxTVPK1ZKqHw4LPoI+Djp2at8xiFYibrm4fxTI7ofTPFuS+Xt+ZZAAU7SDltoynK/THW+viK42/NfwAtwpvb6WpNGTSkE9itkJU18yT3LXWGcKU3AmgIOfBoQsiOlZLnDy8bPb7DbQ0YaLXrhwuWkIQdUY+o/G5GgqAwya28hQ6PlVi4QJfRRZPze9byyvyzEXTP+6GWX9vzeqVbPYepESVnSu/Zqo3W+RC/5hHmxw== X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3178; 6:YUHyrN+q8b/ln5mwtSrsS//IV3YurONnpPXIdAuLIGtXs2QcRmsMGdNjiErCdg+9fIRnPdOV4a0DfTeO3iO/xpf0UZ6aldLlKxVYxzS6mtwg5zee4y2nzXA4G8Xs3CG4id1nZzXvrAu35HkbBgVnUBP8kBEhwThfJmfpcYK1ainHCwp1n7AA23mxO/YFabUKphn6hcAl9BUxuhTYZXJdBjjOpI8OpEVXChEqaDJh4R5mjbyQhnFb/MbKbVIwXDdbObk6re5qxGRYHCLa3jcMirQGxMDxbC2+sN670yTHGKp6ZCf4H0p7w6UDI/yl4yXXP0orabF3SHRp5ySLL9cY2uxT37wB3jJs3VVSXKUhiWhoUPsK/g3ZqQSbQMkDrzEyVFFm5ZlPysVl8grbOAm31ZfBchiLjjn8IC/2EOydSVJaai/dKYrr+k+NlSm2b5VMIADKlZZUDKo7TTBMzBSh1A==; 5:FFqWxChyYhlVsCy8IQ0nadEDGKriqbq9diqy2nQQA3eP5ShRxbOIRw95iKxkhWG0que5XtXl+VTrL7NDa0XVFpQV2J3qPYBGOyl3d8TrOP1+8srzVlL71B+2XIZrS3rJAfzlRSahwHBZWSO1PbUdUwNVYcQrf1hVwoTb1Y9Mq4M=; 24:cRmqhVjN91RhfNNRCOZmIf79m8VbKxBzYnmJIat7yZxKlNt98dv9Zf868tCqXvK1lc8BhUjz+ezRJnB1/O/L00eJ2i6vnswvb1uQeK0D4os= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3178; 7:yY2Ir61B3vYaT/yxSQN4kSLyFws7UgUDrwzQFTz4YXWWparGL6flzsHAoOhni95Cka3Ss7ESvqhrFkUuUCOr5VIZw/k29LwssqpnkTm6Z/kTD6yY/Gwc47s7y5fPhg+BaN9PXZvi7ni1l9igPgRL4WS/nRrYf2RtXkx8h4Z3CFyJ+UFHz++K50E8t91bUhecSrtQRuHKgzdQtS3h8YKnR7E/C2otndd4F058xulwVfBdT6NOL14KMBFswkspNoE8 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2018 18:15:35.5382 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7455ed38-127c-4672-9f55-08d5e82376cc X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.242.13]; Helo=[P-EXFEND-EQX-02.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3178 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-12_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=866 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807120191 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 18:15:41 -0000 Simon J. Gerraty wrote: > I've been working on tweaks to libve to make it suitable for use for a > new loader that can verify the manifest signatures. FYI this is done, and initial testing completed. The manifest parser/lexer are derrived from the one in Junos. The version of mac_veriexec in tree does not yet support storing maclabels so the veriexec util has some ifdef's to deal with that (same as Junos where we have to worry during upgrade about all combinations of new kernel/old util and vice versa.) I deally I'd like to see mac_veriexec up to date, so we can avoid all those ifdef's. Since it relies on the trust store and verification stuff in libve (D16155) I'm not sure there's any point posting diffs until we close on that, and in the meantime steve may find enough time to update mac_veriexec, though as I mentioned before work has an anoying habbit of getting in the way. A follow-on effort might be to allow libve to use either BearSSL (needed for loader due to size), or OpenSSL. --sjg From owner-freebsd-arch@freebsd.org Thu Jul 12 18:31:22 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC4981030FCC for ; Thu, 12 Jul 2018 18:31:21 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B32677806 for ; Thu, 12 Jul 2018 18:31:21 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pg1-x52a.google.com with SMTP id e6-v6so4149825pgv.2 for ; Thu, 12 Jul 2018 11:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=j4g7bIfIkdmc8pkGkfarN90PZbewcT4sSg3C4TAWbqQ=; b=EjuSBOlAc6tH0/bBOJKVkVDDoABaW10r7ke0CI024giPaq49eaeRot+u8CZe+e6qoL zmf/h3+tGTnwA1Zsy3CxbMtF2iRRHxddfC4dZsL/VXO2gFYgoF+YNncCTDbu6EHTohIE jD3HYrZxG6Q3hIJLgPfT3Mt7NRbI+UvPz+q/T8jDGgiglwk7Rl9W8yBersgz8lwIyrjT gEo19Ykko6wi+ETYzQQ+sEDfMdmEEgb9kqDX8E+GEg6cq9cNU7cGksj4t0NsHzeZmIFr CeFKU+roz2CSuo1MMYMXpXT24DidUVF4TQGgooJAmBcNxFKUrhmuC1doCNe4Lt20KvH0 p3Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:subject:message-id :mime-version:content-disposition:user-agent; bh=j4g7bIfIkdmc8pkGkfarN90PZbewcT4sSg3C4TAWbqQ=; b=XpQ5/UodnJC3Y3Ybn2zICNAvdLd5495NbtTw8ZnxA2a6Ixmv8DLyCfpX1kKbgViQ1E 70SZ7Y4gUDdnu6iZW08prm0hvPIoWcIFrLC8rT60SZCg6h/lUwMJsfD4mzpSMJ31Kf7F 5IAJ/MNq80NEsnl1pN1RrQZjdeCgSCo03PoO2aosB0WCBunG4HMoG9efGYuBCfxnvOzv hOhSUGmLpeOV3d7fopH/OmRsRNyF2zUol7m7cXZMGQxi46e1AWClh7i8tslq/woCS2jQ 9zBM9Vyfa4Ydgnuxd5B29L/gUCoryRk1hMdogBU49tjYCp2zYs7PYoP80p4DeGmpUQ2g IT+g== X-Gm-Message-State: AOUpUlFZD8heM1q7Wbnm4DneUJqnBzquFEzmeyL2s+JgwFInm93eQPSH F6xmrUw1kP+mUnIwVsko7JS+6Q== X-Google-Smtp-Source: AAOMgpfdRUgL5xz/D094tYW2e7Qvbq1lN1C09NNLN/ztYX24IJkAy6yH7PG6gGbxOJF41J8bJaNdpw== X-Received: by 2002:a65:5683:: with SMTP id v3-v6mr3037967pgs.176.1531420280019; Thu, 12 Jul 2018 11:31:20 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-107.dsl.bell.ca. [70.52.224.107]) by smtp.gmail.com with ESMTPSA id y9-v6sm18463501pfk.7.2018.07.12.11.31.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 11:31:19 -0700 (PDT) Sender: Mark Johnston Date: Thu, 12 Jul 2018 14:31:16 -0400 From: Mark Johnston To: freebsd-arch@freebsd.org Subject: early x86 microcode loading Message-ID: <20180712183116.GB15892@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 18:31:22 -0000 I've been working on support for early loading of microcode updates and wanted to solicit feedback on the approach before starting to get any code changes reviewed. Currently we support microcode updates via cpuctl(4), where cpucontrol(8) passes microcode blobs to the kernel via an ioctl interface. Updates are distributed by the sysutils/devcpu-data port. The scheme has a few shortcomings: - Microcode updates may introduce new CPU features, but since we load microcode from userland, updates are performed well after the kernel has done CPU feature detection. - Updates need to be reapplied after an ACPI suspend/resume, and there's currently no mechanism to automatically reapply the update after a resume. - Updates aren't applied until userspace starts running, so there exists a window in which the kernel is running without vulnerability mitigations provided by microcode updates. The aim of this work is to instead use the boot loader to load microcode updates into kernel memory, and modify the kernel to apply the updates as the first step in BSP and AP initialization, as well as after an ACPI resume. To configure an update, one would then just need to add the following lines to loader.conf: cpu_ucode_load="YES" cpu_ucode_name="/boot/firmware/microcode.bin" cpu_ucode_type="cpu_ucode" The kernel would then automatically load the update during processor initialization in the subsequent boot-up. A given Intel microcode update applies only to CPUs of a specific tuple, while AMD releases a single update per processor family. My plan is to extend cpucontrol(8) to determine the correct microcode update for the running system, and have the devcpu-data port install the corresponding file to /boot/firmware. The port could then add the following to loader.conf.local: devcpu_data_load="YES" devcpu_data_name="/boot/firmware/" devcpu_data_type="cpu_ucode" Currently, the port doesn't automatically enable microcode updates; one needs to enable the microcode_update rc script after installing the port. I'm not yet sure how this should be integrated with early loading. For example, if "service microcode_update onestart" enables early loading, how should early loading be disabled? Would it be reasonable for the port to automatically enable updates when it is installed? For at least Intel, my intention is to support loading of multiple update files concatenated together, and have the kernel determine the correct update to apply. This is to make it easier to support a cluster of mixed systems which boot from some shared environment; rather than needing to select and configure the correct update for each machine, one can supply all updates as a single file and have each machine select the right one automatically. This would come at the expense of some wasted memory: the combined set of Intel microcode files is currently about 1.8MB in size. A small patch to the loader is needed to guarantee the 16 byte-alignment of the loaded microcode update required by Intel. This will require a bootcode update on GPT-based systems in order for early loading to work reliably. I'm interested in any feedback on the above, and especially any suggestions on how this feature should be integrated with the devcpu-data port. Thanks in advance. From owner-freebsd-arch@freebsd.org Thu Jul 12 19:24:02 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 D8255103A30D for ; Thu, 12 Jul 2018 19:24:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 906A47B27B; Thu, 12 Jul 2018 19:24:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 9256810B45D; Thu, 12 Jul 2018 15:24:01 -0400 (EDT) Subject: Re: early x86 microcode loading To: Mark Johnston , freebsd-arch@freebsd.org References: <20180712183116.GB15892@raichu> From: John Baldwin Message-ID: <6a83fad1-7616-eea5-d86b-83db693a9c73@FreeBSD.org> Date: Thu, 12 Jul 2018 12:24:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180712183116.GB15892@raichu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 12 Jul 2018 15:24:01 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 19:24:03 -0000 On 7/12/18 11:31 AM, Mark Johnston wrote: > I'm interested in any feedback on the above, and especially any > suggestions on how this feature should be integrated with the > devcpu-data port. Thanks in advance. In general this sounds good to me. I'm not quite sure how to manage setting the lines in loader.conf. Using 'service foo start/stop' seems to be a bit of an abuse of what service is used for as opposed to just including a standalone script in the devcpu-data port with a suitable pkg-message. sysrc seems to be a closer analog than service in theory, but shoehorning this into sysrc would seem to be quite ugly and doesn't seem like a good idea to me either. -- John Baldwin From owner-freebsd-arch@freebsd.org Thu Jul 12 19:30:53 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 6E99D103AEE8 for ; Thu, 12 Jul 2018 19:30:53 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (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 D77AF7B81E for ; Thu, 12 Jul 2018 19:30:52 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-ed1-x542.google.com with SMTP id i20-v6so9731805eds.12 for ; Thu, 12 Jul 2018 12:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=9qFDIi+UhsJf+uk7+0Mh5PAiBjJ6egZanzl2QJ20ChQ=; b=bcUZ0nMQ8VwDHEQmAiKYF7tjs27GNT5/TfbzjgueKqMVnR+acb3S4Z6iliAM7qO7Xs mBp/hNV4JMbI6XUyrtz1r/AwGULRnRUWe/+6SM47sC16gTdqez7VE/PVHziRVr+4oRKT VQVZlNkN/UMTbdq5YueuEQyZNHPaAt7XbrEQF/nP7wPK5jPvT1m+fgxo29Oyg2MhR4B5 M9Umb8jCLLbnx8HoXMWFDUydr/7CHxBmcxLaeWxT9MGDAtQSfH89pDgfuCkUGESscrNW HZxeDpHkpUuYqzpEt1usPVzyO3PI6rkS4YNT6iGiglKnVBGVsmno0m3YQULJQmdfA4Ct rtEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=9qFDIi+UhsJf+uk7+0Mh5PAiBjJ6egZanzl2QJ20ChQ=; b=bXpNDQgbtX3an1JsuzXnEl01fh6zcIZt0JmWvQNxh2TcQctdUE1Ifds8pgwahlwfOx 4cr6g0lP7v2XJyWMjdqREMQ42+xQt2IKyaw9PqohPL2GehFI0FovtaGtPpgvrMlmmn2w tgoCjwX6ajhBdfG/SMAgxz+rZEJLxKQA1C4nr/pykW0U513+s+li6PM+HPHB+LEzw6dy uvyq7PuaH9oVV8kovYtO+oYtpsp/u1bVt0Kjlwbf/7xt60tKVqZcDLXHs0vHryus/U6H KQGgOxuL6ca+CWvfD+8iTnVPvwcfwYVNhQLOmm3ix3uqSGkdW4dJlLpiZwCIMZpw0iHS /+rw== X-Gm-Message-State: AOUpUlE0RnmVSkUpnDVHHjR/6as7xLLxdplpI+BOnLKcesX31rDfriE+ N5NU0edEa8uJP75f/xNVDwq9JuplJkc= X-Google-Smtp-Source: AAOMgpe37lEZYB3roTbQYHamJbG4EpvsMIIgVgFYkGbc19FGGVWdmNPbuse44+LHF8IpvyhCWfjuaQ== X-Received: by 2002:a50:940b:: with SMTP id p11-v6mr3850427eda.107.1531423851760; Thu, 12 Jul 2018 12:30:51 -0700 (PDT) Received: from mutt-hbsd ([195.201.16.199]) by smtp.gmail.com with ESMTPSA id b9-v6sm12255735edk.28.2018.07.12.12.30.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 12:30:50 -0700 (PDT) Date: Thu, 12 Jul 2018 15:30:15 -0400 From: Shawn Webb To: Mark Johnston Cc: freebsd-arch@freebsd.org Subject: Re: early x86 microcode loading Message-ID: <20180712193015.kvupmvmusqr3cy4y@mutt-hbsd> References: <20180712183116.GB15892@raichu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5kuy3ysivzs6kzc7" Content-Disposition: inline In-Reply-To: <20180712183116.GB15892@raichu> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 19:30:53 -0000 --5kuy3ysivzs6kzc7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > 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: >=20 > cpu_ucode_load=3D"YES" > cpu_ucode_name=3D"/boot/firmware/microcode.bin" > cpu_ucode_type=3D"cpu_ucode" >=20 > The kernel would then automatically load the update during processor > initialization in the subsequent boot-up. >=20 > 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: >=20 > devcpu_data_load=3D"YES" > devcpu_data_name=3D"/boot/firmware/" > devcpu_data_type=3D"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). Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --5kuy3ysivzs6kzc7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAltHrEMACgkQaoRlj1JF bu7LQA//dVNHx9KaOEl52a4jOE4T7J5QxMPmD+SmDwVsoVcslkKvsPM5yciKrYTm s5CO7aAcNEJWmdpqjht3/IjKSXn3E3t7wr7y9+ca2ABGvuygPEa883R5IjNJD6i/ 4Oq3UPD4R6dOgyvtScm9qM0xKaQVM+CHgbA9YCUG048R3iGh/n7kbwX8g3BMkY2x dSwfR2Q05sArTgalxKreYWtsVTp/8LKnLhG/Un9weRJmwTHyWRTdw2Tq9AvT0uNM Xid0efGat8DDCHyLFCFP3rKwguqqFYNDjAmoxJSwnDxx30zd6JZIUqwwfghMEhuh dEpM6V9bR86YWnHWjXKLkobnVAzt/Bb42neQjxmvIDkzeAZOUOw3127p74zYR1lX Vbyiv9oYVv8Y2n2rT3W3IX6ZEEtqr81wlimLND7MDQLsHNsFO5tKJ2xAah/1njI0 SJ1qoBJwqBJYhKd/zAmPLsD7e3SDFTcH558kNQUCPgJR11lahM46VtMCAZweOB9y 0gbkVetaarY6mrVaIc7SwTacl+BfoD3n726Pr+gjQcxdyHMAPiGQCEuj4QtsOsDj Ab3xQ1FmKSdgK+u/w5PwUbWB0TV+Wbhr3epJ54R4o1WR16lr7RDQYU92TJVJSln0 Xc1WBkxsgDnV7Z23TOGesGDk+1pteXXF7MmDfk77oTdz8YxOl7I= =60x5 -----END PGP SIGNATURE----- --5kuy3ysivzs6kzc7-- From owner-freebsd-arch@freebsd.org Thu Jul 12 19:38:44 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 1DA5C103BD9F for ; Thu, 12 Jul 2018 19:38:44 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC1D57BE51; Thu, 12 Jul 2018 19:38:43 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 4A9185646E; Thu, 12 Jul 2018 14:38:42 -0500 (CDT) Subject: Re: early x86 microcode loading To: John Baldwin , Mark Johnston , freebsd-arch@freebsd.org References: <20180712183116.GB15892@raichu> <6a83fad1-7616-eea5-d86b-83db693a9c73@FreeBSD.org> From: Eric van Gyzen Openpgp: preference=signencrypt Message-ID: Date: Thu, 12 Jul 2018 14:38:41 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <6a83fad1-7616-eea5-d86b-83db693a9c73@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 19:38:44 -0000 On 07/12/2018 14:24, John Baldwin wrote: > On 7/12/18 11:31 AM, Mark Johnston wrote: >> I'm interested in any feedback on the above, and especially any >> suggestions on how this feature should be integrated with the >> devcpu-data port. Thanks in advance. > > In general this sounds good to me. I'm not quite sure how to manage > setting the lines in loader.conf. Using 'service foo start/stop' > seems to be a bit of an abuse of what service is used for as opposed > to just including a standalone script in the devcpu-data port with a > suitable pkg-message. sysrc seems to be a closer analog than service > in theory, but shoehorning this into sysrc would seem to be quite > ugly and doesn't seem like a good idea to me either. I hesitate to suggest this, due to the necessary change in /two/ boot loaders, but... The foo.d approach is very convenient for packages. An activation script installed by the port/package could create a new /boot/loader.conf.d/devcpu-data file containing these lines. A pkg-message would instruct the user to run it. Eric From owner-freebsd-arch@freebsd.org Thu Jul 12 20:52:39 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 0B7421044E93 for ; Thu, 12 Jul 2018 20:52:39 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9550D7FDE3; Thu, 12 Jul 2018 20:52:38 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 92C0A14836; Thu, 12 Jul 2018 20:52:30 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id w6CKqUgK050841 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Jul 2018 20:52:30 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id w6CKqTTk050840; Thu, 12 Jul 2018 20:52:29 GMT (envelope-from phk) To: Mark Johnston cc: freebsd-arch@freebsd.org Subject: Re: early x86 microcode loading In-reply-to: <20180712183116.GB15892@raichu> From: "Poul-Henning Kamp" References: <20180712183116.GB15892@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <50838.1531428749.1@critter.freebsd.dk> Date: Thu, 12 Jul 2018 20:52:29 +0000 Message-ID: <50839.1531428749@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 20:52:39 -0000 -------- In message <20180712183116.GB15892@raichu>, Mark Johnston writes: >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. This is problematic when a diskimage is migrated to a different CPU, only on the second reboot on the new hardware are you certain to have the correct microcode. For images which are resurrected on demand on whatever hardware is available this really problematic. NB: before anybody misunderstands: This is not a problem for guest systems under virtualization - they don't need microcode updates. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Thu Jul 12 21:00:50 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 8232C1045C89 for ; Thu, 12 Jul 2018 21:00:50 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "thawte SHA256 SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0138801C1; Thu, 12 Jul 2018 21:00:49 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6CKrWP9024453; Thu, 12 Jul 2018 14:00:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=vWyqoPC5FwyZKcfj19TlNvCZU+Qnfj/XY+yIBOTccOo=; b=0m7x5A/t4FN+vZ92v/l87dSYlZfxJhuBmPHlDae64atOYfiX9q6Y07TO+XaBnlw3BgtH dkDQIl5V6cvgxKxK98yz/P/Vr2+uwVlmr+/AcFtbxIva9gHL0kdXsIHucMkS/4DRVQx+ MmLwoXotqEDScR8PJpl0j2gg1irkchhj6Ag6QN5Rj8BcEJ5d2dIrjdJXhYRFld+/C7IA YwdLWhNMnnhP6HQfpQqi1U9f7wfzzznuelpo3DqAwR7loHGWFOe5h8XQ3JXlaAHutoMg TrtSgjzlLhb+XFLDnpf0T0oldt4OwVeE7iW77ivZKmmW1h9B3bF8j5gEtidRPCNhEeAq Kw== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0021.outbound.protection.outlook.com [216.32.180.21]) by mx0a-00273201.pphosted.com with ESMTP id 2k6c8b881j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Jul 2018 14:00:48 -0700 Received: from BN6PR05CA0021.namprd05.prod.outlook.com (2603:10b6:405:39::34) by BLUPR05MB611.namprd05.prod.outlook.com (2a01:111:e400:895::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.12; Thu, 12 Jul 2018 21:00:45 +0000 Received: from BY2NAM05FT022.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::202) by BN6PR05CA0021.outlook.office365.com (2603:10b6:405:39::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.952.8 via Frontend Transport; Thu, 12 Jul 2018 21:00:45 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.242.13 as permitted sender) Received: from P-EXFEND-EQX-02.jnpr.net (66.129.242.13) by BY2NAM05FT022.mail.protection.outlook.com (10.152.100.159) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.973.9 via Frontend Transport; Thu, 12 Jul 2018 21:00:44 +0000 Received: from P-EXFEND-EQX-02.jnpr.net (10.104.8.55) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 12 Jul 2018 14:00:41 -0700 Received: from P-EMFE01C-SAC.jnpr.net (172.24.192.43) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.847.32 via Frontend Transport; Thu, 12 Jul 2018 14:00:41 -0700 Received: from p-mailhub01.juniper.net (10.47.226.20) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 12 Jul 2018 14:00:41 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id w6CL0eh7006856; Thu, 12 Jul 2018 14:00:40 -0700 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 6C58D117A1; Thu, 12 Jul 2018 14:00:40 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 6ADBA117A0; Thu, 12 Jul 2018 14:00:40 -0700 (PDT) To: Eric van Gyzen CC: John Baldwin , Mark Johnston , , Subject: Re: early x86 microcode loading In-Reply-To: References: <20180712183116.GB15892@raichu> <6a83fad1-7616-eea5-d86b-83db693a9c73@FreeBSD.org> Comments: In-reply-to: Eric van Gyzen message dated "Thu, 12 Jul 2018 14:38:41 -0500." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <55788.1531429240.1@kaos.jnpr.net> Date: Thu, 12 Jul 2018 14:00:40 -0700 Message-ID: <60227.1531429240@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.242.13; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(396003)(136003)(2980300002)(189003)(199004)(16586007)(46406003)(97876018)(486006)(305945005)(97756001)(50466002)(54906003)(2810700001)(23726003)(55016002)(446003)(126002)(11346002)(117636001)(7126003)(476003)(316002)(229853002)(2906002)(9686003)(76506005)(68736007)(81156014)(478600001)(106466001)(336012)(26826003)(97736004)(5660300001)(186003)(26005)(53936002)(107886003)(14444005)(6246003)(90966002)(6266002)(6916009)(4326008)(77096007)(105596002)(8936002)(81166006)(86362001)(47776003)(50226002)(53416004)(7696005)(76176011)(356003)(69596002)(8676002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB611; H:P-EXFEND-EQX-02.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT022; 1:EPfGaYzmV6TeBDWsQXi+V3fNW9nIbNy04APl7ekvdD4ocjITmvgXjOhtbYGYsqiMzpSx/E3vVHptj77bzS0XsoFMHN68dKpgk9LACX486h2WHU/nMB57ZMB6521O9hYU X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d101ec62-acaa-45c8-867f-08d5e83a88f7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060); SRVR:BLUPR05MB611; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB611; 3:Z7R1sBAsFLV4ouigQRFFTIybtNiT6OLMGMOoBFTEhoEj+YDeY0n6mxEtlPr9yHUgvFO4nV/PIABDbe3YB1f9fqiEB1O+kJXVJkjuN0nnyf1rQzEMYGrDzCwidHMNlrig/qJcWlJyiN5qpGZAg2YXr7mqoy4UFb7C80n6zJpbwgBAHtWZWijaSrLWyPqYm6KrqsxsNesKUNu79lcKny4SKCWS10R62+OcA9eBTLejSp6FMz+451ippxTA6nkV00mcHx2yzxHQuLHHzyeDo8rZtrm/uB8e2QRm2uA2o2Pr/y+RjGLUMr3iS4yiojoxZUHRCsJuTejDxWjutwRor5lMdrvqTEDayQ6C4WVTOZGsj4o=; 25:QOIyMxHrjgbH75DC1CwQc++Z8NBZTCylyjdS5TkQqZuuNVVLWqNmWdhP8ZKAHcWS7UuFbuxTcz3gAHAhM+9exVlIgUVqiqAOGDIOD5a6vi80FdAGLp2x78I05EMh9SsEt/2poT8cte/R9KPDUJ9ggdvzD36wRPF1yMmltS/9WzwhEN9X/n3xUCmvykLnOhtHJQJOcPGt9zlZUWXgEtG80UiuhIAMAGtA0zqk74NM2JImxWagYXSM2QGFWcmNqhBHEBUv1cr2tTxyBDDQjazuV+2KUeuFQD1LYby+bXKOd8HtpRgIwVcOVVqEJZbqo/V8+OUwe5NpDNTVgL4jEzgVQw== X-MS-TrafficTypeDiagnostic: BLUPR05MB611: X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB611; 31:VUHBp8o5emq1klrfYz0CxHc7w0qPk6YeiA7OOHbtaKsbQgG4R1AickL+Htmm60xUWKBWZ1OgYVuq5N+1HHmUAb1pprw2gLwt1L+nDL8KBzVeEZzseIN97kdaz9DggEUjuWE0mJu3srL84PT4GUixgyfXPtwDrRMHMsxhW7j6bDY4Ud/zvUWv7UUwII8/Px4ffvobFUTgij588AvLEMNaswsiLW7+64Z8f2yUREZMa9o=; 20:ZbCwJMi8TAqcI0wGBmJDs1kGFypcENtYG1/4T9K2rhUQNBUCvFU+YaaOzFavpO+qllCl6lbkom/wtGt9ke/ox4y0E7WgnW96/oiTYI16BTCvow2dBYXdxZCn3pgD+3ZkLF/2q7xaFTdzmdOrqu0BAlEsQVqLXUc6hOYOA2sF45q18olQaseSHNZTEu+1YRnb7KkE4+7MMkSiRG4eJHSWtcSY7teYA3QEwJZ6F+pwclEZ25sBVXJ/mPCEU7CoNp0w06c4SqtCwNSVX+qw0W65zbg8KvhoKWI2uWhyM99vyMF9UMEXm2W8P5iyL07MBICdfi82kc4mMB2lFDiLAknZ3qGu8ukP9I5T1PEYkpKg8uRRoHw18v6XJ7XOhr1VzyK/IWiFkcboaNd6czIWLcQxt9hml3ltdSkOwQJMvfHwMG1RmTSIVaQmt0TOwMWuxeqssHSqV8yG+4yNULxm+E5fULogi9tmyHUkWA5yBzaIjNg18qgRuRV+7xiX0rgdqng4 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93003095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BLUPR05MB611; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB611; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB611; 4:+vxYcGEKGKwWU79ZgCaWUXLP9z6wHoec9h/mnKGH3ivZou+iJ3nwSclwS1Pu9MQyZ2TDEdGta0MxpRpodRrNQ3QwAdkplclnrS2VcBX5q34Femudsdet3Bt5++D2ZacO5VWlzVjSyDJYMiGa0dDLQWcSofxtOexv1xBzUeT97ONxazap98K+01+Boc7gvpLNvLhn6pG8HoLHb8PJlxlFP3hxPQ805w7/cUaS6sgZ7OCeyz8UrMhEx2r51RaEAJ7jOEeitao4PTTFSdtYsNA5wg== X-Forefront-PRVS: 0731AA2DE6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB611; 23:wrhlrPiG0cKgy3XKsn0wCneY5MJ9uN1PI3ya9zVT6Z?= =?us-ascii?Q?xj/0mCy1Si00BD6rB6lWh/72UBTKbAg078U+ecjV6CmXp24zrjLRNXRut9Eo?= =?us-ascii?Q?z2u487pRvKXGEv/o1drZjydjbar+Mo2aokIXnJi8aiwpjHGO31sZsWdRTq3l?= =?us-ascii?Q?jD5PWwJqE/b5z4oak5ArzQvMZrLryKRR1cr41uA2nq85eF5mGyUMk+ntQeRO?= =?us-ascii?Q?WIQNt1hHtVomN5QeLGpk9evr635jGP3Lv5MQxaqGP97LaVCcByWpKesK8s9O?= =?us-ascii?Q?+eMkr/yRctmNs0Hdc/fVvr7zsqwKThadn3gWVA+KghOxsy1IYnneweFZV2jl?= =?us-ascii?Q?7+Xp9UKSIkVsDIoVKC4RIZWnIQZ5Lqv0xTOuX7q+poXvFoWrlWhmZaHGR7DX?= =?us-ascii?Q?3QHKzzkPqwKIoA9RdZ1I41A7sLXgoClsMMiWXebqIQoI+o9U0VYB3o22W2DT?= =?us-ascii?Q?ztcdVZhgFmhfmGe+88eNORAoPa5CASFy0Wl3nvaS763YRzdrKtpQHIXlXZcq?= =?us-ascii?Q?UuCk1cCm0N7fTi1qZD7GCNIkLeUGfwCcT4G0PG1fAyAowmowcbQXFQi9TffA?= =?us-ascii?Q?79erkYyGvxRbew8DPZ8BClUdGUktb7hH4JvRm3tq4GgedLGfwLKYXBSs3qJF?= =?us-ascii?Q?73k6MoyBHxqIRc/RDh8Z83RVrj7ID7dQS34VFwe0qWxXWVjNc2iLzGZ/OiOO?= =?us-ascii?Q?Gp6pfoMCiA9scNDhiqqEsMmNzpqAkxFoDzwQWdMm8XqjBpFkXWwwNwmIY4oq?= =?us-ascii?Q?/olhUHjHan8x5Uj+Fhg3pwWley66cglPb2TQOv4L2F5GWHcCBlBs8fEyzf/p?= =?us-ascii?Q?kHPnWV1FVb3oeqKW4HFxA03wTRGusIoXYPswQBVrA61NomNkJvfeTqnnOvua?= =?us-ascii?Q?KRYTwg86+D+y7ym6JvQoe6Q+8phIVti9qX/yO/RB2KkXg5unkIVDlcoF8dH7?= =?us-ascii?Q?6GoA5zpP8dxvHIywaFo1Z9texA7HS1MKlsloYgtfYSn6ag5JJP04u5vXdcgA?= =?us-ascii?Q?++jrVmPV1sWDIeLj0dmM0xhYoCgA1JCK7IF4GZFVRBY+UOrdUJtvBhbsU8Pk?= =?us-ascii?Q?jq8No7wJm4oh1dIXV8HW0cREMP7nk5B1Q5CV51KcaneKkla5XmEnyAWcb4wG?= =?us-ascii?Q?QJbcgfXNO92CanyvM9qyYifbVBMdBelE7dAGwjbYfNOz04HlBPcDlAWoxR1p?= =?us-ascii?Q?P/NqhXg9RsTMNjkPn00yBCaSMxJA1kYwsYojaGScGTx8qzizz3RFyB9U1Q4q?= =?us-ascii?Q?0NBLO1G6azO5nYytqM06c+kALDka9kMWJRaC7yZuCUcamt6KDX0ocjAbSOeF?= =?us-ascii?Q?DmZRANLMAISDYkgbGhS8kOFU5ekNLhyebZFFR5SyZesPTgqn6UPmRdb0cZ+5?= =?us-ascii?Q?Qr2QJdrYFeTZV5gffF5QzrOhg=3D?= X-Microsoft-Antispam-Message-Info: OsZvsvgu2d68d4z206wi3j1tuzZ/B5invx66eYFsHH60v9/c7FOoLMXXJwSYM88ElKDUQt1IL5aWkiF/HCdossOGF3avTL2JJiDVaC9gSNAzJywRnB1jOoSZl5VxhY3CMgzbGnviuXdF1hX0U3icsKZvkYGjin4EEXDrPminNv14z3q2CWckhU8phkHhh9s/MUBnZbGeAF/giZHKgE5Yy11lfBKSlxSkGChaTFoowGaMAwj7hSIVtkWzQ7pcMlIkOp2K3UEpuRSPD76CpVIC1+PRsVTNPYguz+16z+Z8QZRwVFvgrV1kfzDLA2vE96i+oJtiHHrFVybLd3dWUUfg5x54ugKcVQ2a16ysuQHicT9PJFwrDv28W8Ss8F12URAe6nCFCKJnG9xd58y+8vrHjQ== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB611; 6:cJxoUy0E77eFAmiIZC9+fcUk+mw0wC7IsUmJUP5ViXKkz4y0SFUug3Jaggwo62JCS+GBcKoabulaPv9a6jyLkdEHWZ3Hs1pbWmPqUHbTfn3st7uQxjmynzef3IHn+ixfrHTJkk/77vWfIhs5p9l7GHrnzOtFoFAWAtBHx6n2i8gTOJ72SkE3Xtc6RMWohRgT4CAYzUt3TUtlnY+oxjkOgkrC8DdIs3RMicNiRzXFkIKoHYH+CR3jcGakcR2hynr9u1l3/FUwIDlyrYwCRsuqiC8RlZxpZDc9annXwesA8GmlFvkjRXrraCzB7LxZJMuq4wWKTOzVdlGq+d6YMh+7cjdtqMjs+Nx97cPltnRvI5oUavHkmvSW9jXf3bgFszlzmu5WIovWOJkEfo2Gg11v7Tma1XmsMIDFH12jevrcIZFxDGzzoGF1D3D/ZLKa6YjHk4q+yKbkanfCXJZ+PVR8rA==; 5:9NEy554//didZlhfhSnU9a1W9QpPotHfvHkU/7GGkfysC3CRzV8AG0HIXznezFjQ+DBFOMGMR9h0XUzV391nkG86qZKJxdX3yiw9xXcKutWb6Jrq9qiabNMM6JrAzo3ZHRSWJfZ9uYCSjBbbb2iE54d/AUrEzCIZRICTj09gPA0=; 7:66muED1EENc8wrfX7fPAA6yaZN7X4jq/efUemf+HykFJsVSHzNiZRZ+5AHX5l8ZZ/K5C74WQuEE/ZkRFOlYl6aNfQS7PvfYrqQ62TciC0d/86lCZryrhZ9p+2SPAYtCC4wwlgqFD2G01Nj2+Ussw8MwmhuLTZ/Qlj87xAlTXrj57pU79byIxv04+JpSiJy+SH/3lSII1fEjsDyEd48vvK9KhsdW5N7b1+BFxkbSMYIqtUa9jpL2fGj0YT3awN02f SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2018 21:00:44.5994 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d101ec62-acaa-45c8-867f-08d5e83a88f7 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.242.13]; Helo=[P-EXFEND-EQX-02.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB611 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-12_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=863 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807120220 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 21:00:50 -0000 Eric van Gyzen wrote: > I hesitate to suggest this, due to the necessary change in /two/ boot > loaders, but... The foo.d approach is very convenient for packages. An > activation script installed by the port/package could create a new > /boot/loader.conf.d/devcpu-data file containing these lines. A > pkg-message would instruct the user to run it. The ability for packages to add to the boot env is indeed nice, (we do that in Junos) but a loader.conf.d/ would be problematic for anyone whating verification (at least using my implementation) during boot. Allowing subdirs such that a loader.conf snippet, the module (or whatever) and associated signatures could all co-exist without interference with other packages works nicely. From owner-freebsd-arch@freebsd.org Thu Jul 12 22:46:36 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 4BC50102B170 for ; Thu, 12 Jul 2018 22:46:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (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 C20AC851C8 for ; Thu, 12 Jul 2018 22:46:35 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pl0-x22c.google.com with SMTP id p23-v6so22065plo.6 for ; Thu, 12 Jul 2018 15:46:35 -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=D+yawSjL7OaiDhamNCnofoyaYLgTOLWRgi5xyMYkV/4=; b=ML956Wueg2Qh5Y/wqjFptaRuHl6vGr1LbwijptkGsVqWmADmkh8v5iatxONAxAE8Q6 nTbu9vSBz32RnCVS1ASYxXtOWZ3gGXxigYhnoHVQr092X4Tem5zJSlGYD3ltkLL73PPT RpBNGTtjHpp/0PCKuJCp2kPI7gHBLGhKzJnjOyAqbcvi0w3vx9SDnJZ0LrCeGvsKQoHh 8CDa2oP4mj9RmHpYCwnGcg9ohz6B5DZ1qNngFDcFS1gM1s+xylRz8ANT2yl5RCxwH89k hJCv1opD/yH7dZFz96qywoPzVi/Sbc5mlcWuwIZLG7663jwzMcRItDcO6P0KhssRV4Ru Oa9g== 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=D+yawSjL7OaiDhamNCnofoyaYLgTOLWRgi5xyMYkV/4=; b=J4cF13b6nKw2lu9R6VV3LwVWWe5gXdSx7zkditZTyFUaszqtrgOe2Hncxb4Yuvsx7q OSxVRLrUCqVx3MWPYTooTgOBoMxgbt6buHGpq/DueygRnUJ3P51TqbfUq+3Pw18FrRmI I7eluOPgbTdOkh82gypH8N7DXjsf9bNtvYJpg61OZkrbmPldCA87biB3Pnw33n9JT6Qg efLpotLtqxs0Cp0me9bfaz2ilKXHmedfoxTlsSSPPGjbGV9TKpfnmlGA8u4LViMcWFPk eDTJ4cMxNttjrP2dhQ/ynQ0stkPjXVIO4JvxaFl1RsnVAjdnh571AFR3Ofm9Ktl/SGt8 d6zg== X-Gm-Message-State: AOUpUlFU4AB2kNr1mJBR3KTRrEP6SyycS/Sgq9PHGKT3qHypjZ955kai FcpK9NhKzXT2tlFEtepwhiI= X-Google-Smtp-Source: AAOMgpcvIfhBlfxlohlDcH06mA+DdLC/JYSN1n9fYU5Aww4U8+VDTX4IYQIIfqZQcvvZ/3RzqV1Ieg== X-Received: by 2002:a17:902:28e4:: with SMTP id f91-v6mr187843plb.70.1531435594857; Thu, 12 Jul 2018 15:46:34 -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 16-v6sm18262840pfp.6.2018.07.12.15.46.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 15:46:33 -0700 (PDT) Sender: Mark Johnston Date: Thu, 12 Jul 2018 18:46:31 -0400 From: Mark Johnston To: Poul-Henning Kamp Cc: freebsd-arch@freebsd.org Subject: Re: early x86 microcode loading Message-ID: <20180712224631.GF15892@raichu> References: <20180712183116.GB15892@raichu> <50839.1531428749@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50839.1531428749@critter.freebsd.dk> User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 22:46:36 -0000 On Thu, Jul 12, 2018 at 08:52:29PM +0000, Poul-Henning Kamp wrote: > -------- > In message <20180712183116.GB15892@raichu>, Mark Johnston writes: > > >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. > > This is problematic when a diskimage is migrated to a different CPU, > only on the second reboot on the new hardware are you certain to > have the correct microcode. > > For images which are resurrected on demand on whatever hardware is > available this really problematic. I can think of three ways to address this case: 1a) Always load all of the updates as a single file, and select the correct update during boot. As I pointed out, this wastes some memory (a couple of megabytes currently). On at least amd64 it doesn't look very practical to release the pages backing the update file back to the VM. That is, I don't think we can easily "shed" the preloaded file data once the correct update has been selected and saved. 1b) Have the devcpu-data port operate in one of two modes: either the port selects the update for the current machine, as I outlined in my original mail, or it concatenates all of the updates as in 1a) and the kernel selects the correct update. This way we'd only waste memory if the disk image is to be shared among multiple machines. I'm not sure what the mechanism should be for selecting the mode. 2) Install all updates to a directory under /boot and add code to the loader to perform the selection, and pass only the required microcode file to the kernel. This seems straightforward to me, though I'm not yet sure exactly where in the loader this logic should go. From owner-freebsd-arch@freebsd.org Fri Jul 13 12:51:04 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 4ECD5103B6EB for ; Fri, 13 Jul 2018 12:51:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEAE884BA6; Fri, 13 Jul 2018 12:51:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w6DCotSX067986 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Jul 2018 15:50:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w6DCotSX067986 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w6DCosWh067985; Fri, 13 Jul 2018 15:50:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 13 Jul 2018 15:50:54 +0300 From: Konstantin Belousov To: Mark Johnston Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: Re: early x86 microcode loading Message-ID: <20180713125054.GK5562@kib.kiev.ua> References: <20180712183116.GB15892@raichu> <50839.1531428749@critter.freebsd.dk> <20180712224631.GF15892@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180712224631.GF15892@raichu> User-Agent: Mutt/1.10.0 (2018-05-17) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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 12:51:04 -0000 On Thu, Jul 12, 2018 at 06:46:31PM -0400, Mark Johnston wrote: > On Thu, Jul 12, 2018 at 08:52:29PM +0000, Poul-Henning Kamp wrote: > > -------- > > In message <20180712183116.GB15892@raichu>, Mark Johnston writes: > > > > >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. > > > > This is problematic when a diskimage is migrated to a different CPU, > > only on the second reboot on the new hardware are you certain to > > have the correct microcode. > > > > For images which are resurrected on demand on whatever hardware is > > available this really problematic. > > I can think of three ways to address this case: > > 1a) Always load all of the updates as a single file, and select the > correct update during boot. As I pointed out, this wastes some > memory (a couple of megabytes currently). On at least amd64 it > doesn't look very practical to release the pages backing the > update file back to the VM. That is, I don't think we can easily > "shed" the preloaded file data once the correct update has been > selected and saved. > > 1b) Have the devcpu-data port operate in one of two modes: either the > port selects the update for the current machine, as I outlined in my > original mail, or it concatenates all of the updates as in 1a) and > the kernel selects the correct update. This way we'd only > waste memory if the disk image is to be shared among multiple > machines. I'm not sure what the mechanism should be for selecting > the mode. > > 2) Install all updates to a directory under /boot and add code to the > loader to perform the selection, and pass only the required microcode > file to the kernel. This seems straightforward to me, though I'm not > yet sure exactly where in the loader this logic should go. What is the problem with having the microcode blob unmatched ? The result would be only lack of the update for the CPU. If user cares about having the updated microcode, he would run the required command anew. Or you might add an automatic run of such command on shutdown. From owner-freebsd-arch@freebsd.org Fri Jul 13 16:11:38 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 90084104231B for ; Fri, 13 Jul 2018 16:11:38 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 234B98CC26 for ; Fri, 13 Jul 2018 16:11:38 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id l123-v6so22883853pfl.13 for ; Fri, 13 Jul 2018 09:11:38 -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=V2wbVwWT0tNKyYwLSQGbpLn/AIFrAZOF7262yfoIA3w=; b=edh2fqojIrSsMQcCEGdjcpmjAcp0sxmzIEiiTZ7xp7GJkpqaP9qsdYgus0IrFus/rO iVQeUv/aMPc500ezNTaTKrYVUC7QgfPpxep5KsjnyyO8oEGRONj6nYvocYUqduSlNOIB DVJ2/WigEw1QEBkatcULnNyNiANnnRlzcRFDKpT+VdJBvwYRwrf6Dj9U174wY5gpn3/Y wag1j68n7SakgEVBLvy3UKOUJs+12ICQliCamAATpuRVYIAxwvs/8IlaRRM2HuPCY1mu CluZ1B+2Mo8SOSK7aeT1I2RHclaCX9bLKFvi/6KxV/RRfs2/ni4X3ZNC4ioV0yXZ69Bd 3xlA== 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=V2wbVwWT0tNKyYwLSQGbpLn/AIFrAZOF7262yfoIA3w=; b=CDPTOZTjMuoAmf8HOXTGhkAbv/YmAFTmZx6yTTAres1qCCn8mIJYMAG3RPVIODj5Hn ed1eBXIZrDAFhElcJ05QXHLR8twS2GxGX5ZKvmKzajt3LUPAg2Po02bjo7DX5HAzSZ0e FpkHls1Vc+QcOJOsQMPBvj+6Jzb+FCv5aSDaY/hSfcEeio81oBOKnmc4DOLvmpxrkKxd WQp4DvfbTnAMniDb1pj7V8oBr7IBlhT8g8+9UQWsz+Ial8K0A1vEPuRSNEgiRE43HHls NHZPtCaVXdQBMliGIaOyc+5zKNrtnawo90jxTkuL4vwT0+qdRxzBW6iAcrFoi80Zsdcy 5BTg== X-Gm-Message-State: AOUpUlEW9k74UhoHGfXLnsWzKRbVGbNlDdzGHgDELilwGVYMAZFUOlkt TIwEHforHZAqhM6ieD/awMA= X-Google-Smtp-Source: AAOMgpcR7ooU/mjkc4/9iCn495tpewO4j2P8mITpa3uzM2vm9aogUGrmgAckvySEQhvhYMlNw7coAQ== X-Received: by 2002:a62:1e81:: with SMTP id e123-v6mr7691297pfe.188.1531498297102; Fri, 13 Jul 2018 09:11:37 -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 l4-v6sm27538676pgn.46.2018.07.13.09.11.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jul 2018 09:11:36 -0700 (PDT) Sender: Mark Johnston Date: Fri, 13 Jul 2018 12:11:33 -0400 From: Mark Johnston To: Konstantin Belousov Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: Re: early x86 microcode loading Message-ID: <20180713161133.GC26064@raichu> References: <20180712183116.GB15892@raichu> <50839.1531428749@critter.freebsd.dk> <20180712224631.GF15892@raichu> <20180713125054.GK5562@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180713125054.GK5562@kib.kiev.ua> 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:11:38 -0000 On Fri, Jul 13, 2018 at 03:50:54PM +0300, Konstantin Belousov wrote: > On Thu, Jul 12, 2018 at 06:46:31PM -0400, Mark Johnston wrote: > > On Thu, Jul 12, 2018 at 08:52:29PM +0000, Poul-Henning Kamp wrote: > > > -------- > > > In message <20180712183116.GB15892@raichu>, Mark Johnston writes: > > > > > > >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. > > > > > > This is problematic when a diskimage is migrated to a different CPU, > > > only on the second reboot on the new hardware are you certain to > > > have the correct microcode. > > > > > > For images which are resurrected on demand on whatever hardware is > > > available this really problematic. (To be clear, this case can be handled with my proposal: one would concatenate all of the updates together and load the result, and the kernel would select the correct update and apply it during boot. The issue is with the default behaviour of the devcpu-data port.) > > I can think of three ways to address this case: > > > > 1a) Always load all of the updates as a single file, and select the > > correct update during boot. As I pointed out, this wastes some > > memory (a couple of megabytes currently). On at least amd64 it > > doesn't look very practical to release the pages backing the > > update file back to the VM. That is, I don't think we can easily > > "shed" the preloaded file data once the correct update has been > > selected and saved. > > > > 1b) Have the devcpu-data port operate in one of two modes: either the > > port selects the update for the current machine, as I outlined in my > > original mail, or it concatenates all of the updates as in 1a) and > > the kernel selects the correct update. This way we'd only > > waste memory if the disk image is to be shared among multiple > > machines. I'm not sure what the mechanism should be for selecting > > the mode. > > > > 2) Install all updates to a directory under /boot and add code to the > > loader to perform the selection, and pass only the required microcode > > file to the kernel. This seems straightforward to me, though I'm not > > yet sure exactly where in the loader this logic should go. > > What is the problem with having the microcode blob unmatched ? The > result would be only lack of the update for the CPU. If user cares about > having the updated microcode, he would run the required command anew. > Or you might add an automatic run of such command on shutdown. Given that the trend seems to be for new CPU vulnerabilities to be mitigated by microcode updates, I think we'd want a mechanism that makes a reasonable effort to work reliably once it is configured by the administrator. From this perspective, special cases which require an extra reboot or an extra command invocation at shutdown (what if the system panics?) are undesirable. Perhaps we should indeed declare these special cases as unsupported by devcpu-data, but I would prefer not to do so if possible. 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. From owner-freebsd-arch@freebsd.org Fri Jul 13 23:05:32 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 870E31029989 for ; Fri, 13 Jul 2018 23:05:32 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 24C2F7CC5C; Fri, 13 Jul 2018 23:05:32 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5909B14816; Fri, 13 Jul 2018 23:05:31 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id w6DN5VMH002747 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Jul 2018 23:05:31 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id w6DN5Upf002746; Fri, 13 Jul 2018 23:05:30 GMT (envelope-from phk) To: Mark Johnston cc: freebsd-arch@freebsd.org Subject: Re: early x86 microcode loading In-reply-to: <20180712224631.GF15892@raichu> From: "Poul-Henning Kamp" References: <20180712183116.GB15892@raichu> <50839.1531428749@critter.freebsd.dk> <20180712224631.GF15892@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2744.1531523130.1@critter.freebsd.dk> Date: Fri, 13 Jul 2018 23:05:30 +0000 Message-ID: <2745.1531523130@critter.freebsd.dk> 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 23:05:32 -0000 -------- In message <20180712224631.GF15892@raichu>, Mark Johnston writes: >I can think of three ways to address this case: > >1a) Always load all of the updates as a single file, and select the > correct update during boot. As I pointed out, this wastes some > memory (a couple of megabytes currently). On at least amd64 it > doesn't look very practical to release the pages backing the > update file back to the VM. That is, I don't think we can easily > "shed" the preloaded file data once the correct update has been > selected and saved. Then we should fix that problem, rather than build an elaborate workaround for in each and every subsystem which runs into this. Isn't this the same issue with the splash-screen for instance ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.