From owner-freebsd-arch@freebsd.org Tue Oct 17 12:29:36 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C67DE39222 for ; Tue, 17 Oct 2017 12:29:36 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-2.server.virginmedia.net (know-smtprelay-omc-2.server.virginmedia.net [80.0.253.66]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EA6FE6AC8F for ; Tue, 17 Oct 2017 12:29:34 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.5] ([86.10.211.13]) by know-smtprelay-2-imp with bizsmtp id NcUN1w0020HtmFq01cUNCv; Tue, 17 Oct 2017 13:28:22 +0100 X-Originating-IP: [86.10.211.13] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.1 cv=ELn7qAtC c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=itly7gIdAAAA:8 a=Jxc0uoyidaazl1mZYDAA:9 a=QEXdDO2ut3YA:10 a=e2V9OVFKb8oA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=1RpNR2E4bTkVPcsa2RFZ:22 To: freebsd-arch@freebsd.org References: Subject: Making C++11 a hard requirement for FreeBSD From: Jonathan de Boyne Pollard Message-ID: Date: Tue, 17 Oct 2017 13:28:21 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 12:29:36 -0000 Warner Losh: > I'd like to start a conversation about the viability of making C++11 a hard requirement for bootstrapping FreeBSD [...] It is not, it turns out, what you are talking about; but I am going to jump in to repeat my request from http://jdebp.info./Softwares/nosh/roadmap.html for making it possible to use dynamically linked C++ programs in the bootstrap of FreeBSD. Or, more generally, please ensure that the basic runtime libraries for the various languages compilable by the system compiler live in /lib and not in /usr/lib . If they live in /usr/lib , then dynamically linked programs compiled by the system compiler for those languages are not guaranteed runnable until quite late in the bootstrap, because people might have a separate /usr . For C++ compiled by clang++, this would entail moving libc++.so for example. Unless, that is, you want to follow the TrueOS lead of having /usr in the / dataset ... (-: From owner-freebsd-arch@freebsd.org Tue Oct 17 23:18:26 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CE25E4A0D4 for ; Tue, 17 Oct 2017 23:18:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4A566296C for ; Tue, 17 Oct 2017 23:18:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 46764E4A0D3; Tue, 17 Oct 2017 23:18:26 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45F6BE4A0D2 for ; Tue, 17 Oct 2017 23:18:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 0E7B9296B for ; Tue, 17 Oct 2017 23:18:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id 72so4524772itl.5 for ; Tue, 17 Oct 2017 16:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=7LQhNUvwEpUIo4uwrX3Ioin0xNTgLRvsQVUmm4HQ18A=; b=UILTwaZR/5+yB/Tk+NeYFpHnfw9GgL5EYERHsG28k6R1ErqkqUGZfa4bIzFnufSdAp O78sdQTvZGxhJb2CJibL/Ub9vG2xsG4ubmqL910jE9OzaE3KlBOkRPMJs5avBhxvMntK ubWNkhr4PXRiM7ubOemNY+Mgif1vsj57QFXMXRgre+BI64IqNuR3EYJ2/ST2kBWii/cr G2k4/vegQC9y+IJ/Ym1GXt0Q/uC02W6EOpB7sDqkb0YeSe6wWOLKxWBCY7QpEWOIMhIL rNgcP5j4E6ULCXc+LY+hgEWqvElHfOIjYDjz0z6eZlnRN1oFLTSOA3dwE3kSvjeDPQus wdrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=7LQhNUvwEpUIo4uwrX3Ioin0xNTgLRvsQVUmm4HQ18A=; b=j7NsCPwNtW77d23x/Sz6fJinB7y4eMDNq/BTRkfNSTpz1KOxZCcBDnUB5TIF3ZQxQb alWyrQWPfBx5ELXllC3l/86iqtRnCGS56/PMZ1og+/so9HGVdMgLuOx3BHg2r+VfiTaJ OSg3X0Sc2/rcRHFUOnIcPofmUPKhc5nLkeei+fBdAagtJFAWqu259ioXUHcQ3HjiGwF5 cP5pXFqTmJQoGLwMM+Ukh3U+vqclZ+EXIE/5XnjM1OlMYDwwN2x29hTnTzuz7KhxaP5i ToV5344CV67MzGK26VIpsxAu+YjrrTMrcuAA/rADf3hjndn9+ZYlVZmAAhQKGjsBRAe9 28OA== X-Gm-Message-State: AMCzsaWNr2YMoYf08MpIuctdsCo1JotZ8JAOoDBOEKt/USyRAWAnaLWf +nTcCwfQAkPvTSBMrBK1wHg1DRD0iYBDzq+qAPbrCA== X-Google-Smtp-Source: ABhQp+T+7VQ7k//XAefaMYjabzbkFOcThVW/prpYUfMg7BcY1na3pI28LCTM0649fjWlv5aVDQ79wKmLfxMVZrm+H9Y= X-Received: by 10.36.69.100 with SMTP id y97mr7842096ita.50.1508282304987; Tue, 17 Oct 2017 16:18:24 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Tue, 17 Oct 2017 16:18:24 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:80d3:e7d4:5e40:89b] From: Warner Losh Date: Tue, 17 Oct 2017 17:18:24 -0600 X-Google-Sender-Auth: K8_zzm5GxRmLBmMRURV4tV3NC0Q Message-ID: Subject: boot1.efi future To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 23:18:26 -0000 I'd like to remove boot1.efi. It's no longer relevant. It was a useful hack to get us going, but now it's becoming more of a liability than a win. There's a lot of work that has been put into it so it can understand every filesystem. However, in doing so boot1.efi has morphed into a loader.efi without the scripting interpreter. Let's just kill boot1.efi and load the full-featured loader directly. boot1.efi used to have a role to play. It was a tiny, rarely changing bit of glue in the UEFI world. It is now none of those things. It has become rather large and bloated, and there's work to make it even more so. My proposal is to fix the one bug in loader.efi that would preclude its use as a primary boot loader (it sometimes guesses wrong for currdev and loaddev). Once we've done that, we'll use it where we use boot1.efi today. It would also simplify the load process and make it easier to implement the full EFI Boot Manager protocol from the UEFI specifications. It should also make secure boot easier to bring to market. This dovetails nicely into some of the other changes on-tap for FreeBSD 12. efibootmgr is coming soon (I'm reviewing the code from a coworker now). There's plans to move the FreeBSD boot loader to \efi\FreeBSD\loader-$ARCH.efi when that goes in, since we'll be able to point the LoadOptions to that. There's plans to make the installer create the EFI partition rather than just dd the efifat file we're doing today. Plus, there's work underway to move all the boot block installation stuff to a new script (install-boot) as well as efforts to make images for any bootable system (spin). There's lots of details to get right before we can make the final switch, but I think it's in the interest of the project to do so. Comments? Warner From owner-freebsd-arch@freebsd.org Wed Oct 18 03:16:14 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B139E4DF6E for ; Wed, 18 Oct 2017 03:16:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) 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 7460167DC9 for ; Wed, 18 Oct 2017 03:16:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 730BBE4DF6B; Wed, 18 Oct 2017 03:16:14 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FEDBE4DF6A for ; Wed, 18 Oct 2017 03:16:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 3508267DC8 for ; Wed, 18 Oct 2017 03:16:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id 72so4751662itk.3 for ; Tue, 17 Oct 2017 20:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=s/TI3fvzfPQWL1xNaLS/qKyC+6n9eI9vwdInADuuRTc=; b=QFV7HzE/2/TeZ60RxlywacgaCGH+rYrnNS6jUDy3sVABVV6QdRUTFWf6BkpNufV8y5 MNDf01QJYBza4yRdoeKRErILr0U2FBi2eEm1w4EeaMVYZnQbCpcxCnG72aEx81OmMRWD yQxXGWfzX0x7wJcNjpqFikhGgIvX3b2SoU0EdTWlvJCgm1Uv+TxWd/GGBoyGS6WxNIeU OxRipEvdAtC5qhF6SBo+iZXxRov681XfqxpZXenEeqXZUFUnin7P/FYJkNnLLHFk2uoe aTw9O6TTpbDZ6/aPwfsKA76usmP4CtjQnDS06A1DpCkNPzvn1+TmqTYSUyWUGmTT4WcJ W3dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=s/TI3fvzfPQWL1xNaLS/qKyC+6n9eI9vwdInADuuRTc=; b=DPa2oO7zYjMwWvhe3jeNyJzpgjAp0aQ31s+y9l1c5fecV+dI6bvg6cTgi4XFkIzI6w 6hBzh878XgEMi1axwoh6L7f2j62mDLADZocCR9Uj2CnnE66mJPTnJEYhbb6zfYBzQlex 3irMUGCgX1+2obLFZhmdEMs8E4rSPecBY3AKXxAlKbAqRq4Pwixs23kFJflAtTZNau0Q YBl4vd65SVduSZw6gv56HsBBRdEf2F1ykC63XLX+B1BgnEcg5sCu+gIZh5lVWv8ZFh1y gNdcjmnsvVtiLfIzbOAaYwdTmPJZI9fxRsmEAG3PqAGYXtXj9p1o8AucZ+OwMNB6p51D CRXw== X-Gm-Message-State: AMCzsaV6kktmNKOM6wVF28IwT0LeZWASC4GPpPyTbiYuNaS4E0Gn1Txr bHULwdy4PivkBk4Xj2s+l1GJ4RmO2TIQrRA9YnT9lg== X-Google-Smtp-Source: ABhQp+Tq/3T2umRj0OAKQCObV9mvtdQ6tQHwkgiK/CI7BS1nMr7yEpuaQs6FoQVb1Id6P5ohtdIF7O5gPepTYhiXiK8= X-Received: by 10.36.94.129 with SMTP id h123mr7679014itb.64.1508296573153; Tue, 17 Oct 2017 20:16:13 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Tue, 17 Oct 2017 20:16:12 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:2569:27e9:4f44:7434] In-Reply-To: References: From: Warner Losh Date: Tue, 17 Oct 2017 21:16:12 -0600 X-Google-Sender-Auth: mqpY2gWPMD57anRApg9U7eZMooQ Message-ID: Subject: Re: boot1.efi future To: Julian Elischer Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 03:16:14 -0000 On Tue, Oct 17, 2017 at 8:54 PM, Julian Elischer wrote: > On 18/10/17 7:18 am, Warner Losh wrote: > >> I'd like to remove boot1.efi. It's no longer relevant. It was a useful >> hack >> to get us going, but now it's becoming more of a liability than a win. >> >> There's a lot of work that has been put into it so it can understand every >> filesystem. However, in doing so boot1.efi has morphed into a loader.efi >> without the scripting interpreter. Let's just kill boot1.efi and load the >> full-featured loader directly. >> >> boot1.efi used to have a role to play. It was a tiny, rarely changing bit >> of glue in the UEFI world. It is now none of those things. It has become >> rather large and bloated, and there's work to make it even more so. >> >> My proposal is to fix the one bug in loader.efi that would preclude its >> use >> as a primary boot loader (it sometimes guesses wrong for currdev and >> loaddev). Once we've done that, we'll use it where we use boot1.efi today. >> It would also simplify the load process and make it easier to implement >> the >> full EFI Boot Manager protocol from the UEFI specifications. It should >> also >> make secure boot easier to bring to market. >> >> This dovetails nicely into some of the other changes on-tap for FreeBSD >> 12. >> efibootmgr is coming soon (I'm reviewing the code from a coworker now). >> There's plans to move the FreeBSD boot loader to >> \efi\FreeBSD\loader-$ARCH.efi when that goes in, since we'll be able to >> point the LoadOptions to that. There's plans to make the installer create >> the EFI partition rather than just dd the efifat file we're doing today. >> Plus, there's work underway to move all the boot block installation stuff >> to a new script (install-boot) as well as efforts to make images for any >> bootable system (spin). >> >> There's lots of details to get right before we can make the final switch, >> but I think it's in the interest of the project to do so. >> >> Comments? >> > > I haven't been following the EFI story. > Is there a doc that describes the current FreeBSD EFI boot process? > I wrote one for the EFI Boot Manger stuff. https://docs.google.com/document/d/1aK9IqF-60JPEbUeSAUAkYjF2W_8EnmczFs6RqCT90Jg/edit#heading=h.jdwnfj2sxlfb and nobody objected to it in a timely fashion, so it's the implementation path I set out on... But long story short: We bogusly put boot1.efi into \efi\boot\bootx64.efi and hope for the best (since it's the default for removable media and most BIOSes use it as a default for non-removable media too). If it loads, we search in the vain hope that we might guess which of the /boot/loader.efi's might be out there is the right one and jump to it. From there, the process is much the same as anything else. The above doc changes this to 'we follow the normal EFI boot mgr protocol as amended by the above doc' though the elimination of boot1.efi hasn't made it's way through the above doc. Basically, we pass two device paths in the BootOptions BootXXXX variable. First one is loader.efi (which we'll preferentially put in \efi\freebsd\loader-x64.efi) and the second one is the kernel to load (with the implicit load module path, per today's stuff). boot1.efi complicates things for no benefit. It complicates loading, it complicates guessing where to put stuff to make it happy, it complicates key signing and handoff for secure boot. We should ditch this clever hack as something whose time has come and gone. We'd like to get secure boot in place, and boot1.efi just increases by 1 the number of boot loaders that have to cope with that stuff. boot1.efi has to have all the filesystem support for everything. It has to know about EFI Boot mgr protocol. In short, it's every single thing that /boot/loader.efi must be, but without the FORTH or the flexibility. Warner From owner-freebsd-arch@freebsd.org Wed Oct 18 03:20:54 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14765E4E152 for ; Wed, 18 Oct 2017 03:20:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id F3148680A8 for ; Wed, 18 Oct 2017 03:20:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: by mailman.ysv.freebsd.org (Postfix) id EF76CE4E151; Wed, 18 Oct 2017 03:20:53 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF1E1E4E150 for ; Wed, 18 Oct 2017 03:20:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A9C15680A7 for ; Wed, 18 Oct 2017 03:20:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from Julian-MBP3.local (124-148-79-216.dyn.iinet.net.au [124.148.79.216]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v9I2s9L1015368 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Oct 2017 19:54:13 -0700 (PDT) (envelope-from julian@elischer.org) Subject: Re: boot1.efi future To: Warner Losh , "freebsd-arch@freebsd.org" References: From: Julian Elischer Message-ID: Date: Wed, 18 Oct 2017 10:54:03 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 03:20:54 -0000 On 18/10/17 7:18 am, Warner Losh wrote: > I'd like to remove boot1.efi. It's no longer relevant. It was a useful hack > to get us going, but now it's becoming more of a liability than a win. > > There's a lot of work that has been put into it so it can understand every > filesystem. However, in doing so boot1.efi has morphed into a loader.efi > without the scripting interpreter. Let's just kill boot1.efi and load the > full-featured loader directly. > > boot1.efi used to have a role to play. It was a tiny, rarely changing bit > of glue in the UEFI world. It is now none of those things. It has become > rather large and bloated, and there's work to make it even more so. > > My proposal is to fix the one bug in loader.efi that would preclude its use > as a primary boot loader (it sometimes guesses wrong for currdev and > loaddev). Once we've done that, we'll use it where we use boot1.efi today. > It would also simplify the load process and make it easier to implement the > full EFI Boot Manager protocol from the UEFI specifications. It should also > make secure boot easier to bring to market. > > This dovetails nicely into some of the other changes on-tap for FreeBSD 12. > efibootmgr is coming soon (I'm reviewing the code from a coworker now). > There's plans to move the FreeBSD boot loader to > \efi\FreeBSD\loader-$ARCH.efi when that goes in, since we'll be able to > point the LoadOptions to that. There's plans to make the installer create > the EFI partition rather than just dd the efifat file we're doing today. > Plus, there's work underway to move all the boot block installation stuff > to a new script (install-boot) as well as efforts to make images for any > bootable system (spin). > > There's lots of details to get right before we can make the final switch, > but I think it's in the interest of the project to do so. > > Comments? I haven't been following the EFI story. Is there a doc that describes the current FreeBSD EFI boot process? > > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Wed Oct 18 14:15:21 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 052D4E3A0C3 for ; Wed, 18 Oct 2017 14:15:21 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id CA03B7F11C for ; Wed, 18 Oct 2017 14:15:20 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.43.57] (mobile-166-171-186-136.mycingular.net [166.171.186.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 1848924A8 for ; Wed, 18 Oct 2017 14:15:14 +0000 (UTC) Subject: Re: boot1.efi future To: freebsd-arch@freebsd.org References: From: Eric McCorkle Message-ID: Date: Wed, 18 Oct 2017 10:15:12 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: 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.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 14:15:21 -0000 My $0.02... I'm in agreement. I've been down in this stuff with the ZFS EFI support, and lately the GELI stuff. In both cases, it complicates things quite a bit. With ZFS, it meant I basically had to do everything twice. With GELI, it introduced a number of complications, and GELI probably would have landed over a year ago if it was just loader. Going forward, I want to do some signed kernel/modules stuff, and the existence of boot1 is just going to complicate that as well. An interesting point: back when I briefly took up EFI support as a GSoC project (which I was forced to abandon, unfortunately), the prototype *did* only have loader.efi, which was installed to the ESP. So the plan should work. You'd have to modify loader.efi a bit to alter its device detection logic, but you could probably salvage some code from my boot1 refactor (which is actually modified code I stole from loader.efi anyway). As far as my work goes, this won't cause me any problems, and in fact will simplify things. The GELI stuff mostly modifies loader anyway, and the actual GELI EFI driver works the same in boot1 and loader (by design). For secure boot, getting rid of boot1 avoids having to haul in a bunch more EFI APIs and debug signed image stuff. For other work, I can't say for certain, of course, but I've been working on this stuff for a while now and I can't really think of a use case that makes me say "man, boot1 really solves that problem in a way nothing else can". So in summary, I don't doubt it was a sensible decision at some point, but I'm in agreement that its time has come. On 10/17/2017 19:18, Warner Losh wrote: > I'd like to remove boot1.efi. It's no longer relevant. It was a useful hack > to get us going, but now it's becoming more of a liability than a win. > > There's a lot of work that has been put into it so it can understand every > filesystem. However, in doing so boot1.efi has morphed into a loader.efi > without the scripting interpreter. Let's just kill boot1.efi and load the > full-featured loader directly. > > boot1.efi used to have a role to play. It was a tiny, rarely changing bit > of glue in the UEFI world. It is now none of those things. It has become > rather large and bloated, and there's work to make it even more so. > > My proposal is to fix the one bug in loader.efi that would preclude its use > as a primary boot loader (it sometimes guesses wrong for currdev and > loaddev). Once we've done that, we'll use it where we use boot1.efi today. > It would also simplify the load process and make it easier to implement the > full EFI Boot Manager protocol from the UEFI specifications. It should also > make secure boot easier to bring to market. > > This dovetails nicely into some of the other changes on-tap for FreeBSD 12. > efibootmgr is coming soon (I'm reviewing the code from a coworker now). > There's plans to move the FreeBSD boot loader to > \efi\FreeBSD\loader-$ARCH.efi when that goes in, since we'll be able to > point the LoadOptions to that. There's plans to make the installer create > the EFI partition rather than just dd the efifat file we're doing today. > Plus, there's work underway to move all the boot block installation stuff > to a new script (install-boot) as well as efforts to make images for any > bootable system (spin). > > There's lots of details to get right before we can make the final switch, > but I think it's in the interest of the project to do so. > > Comments? > > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Wed Oct 18 14:26:22 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24BC4E3A5B6 for ; Wed, 18 Oct 2017 14:26:22 +0000 (UTC) (envelope-from kris@ixsystems.com) Received: from mx.ixsystems.com (mx.ixsystems.com [12.229.62.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN ".", Issuer "." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E0C427F86A for ; Wed, 18 Oct 2017 14:26:21 +0000 (UTC) (envelope-from kris@ixsystems.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx.ixsystems.com (Postfix) with ESMTP id 3yHDrY181GzCpch for ; Wed, 18 Oct 2017 07:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems.com; h=content-language:content-transfer-encoding:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject:received :received:received:received:received:received:received; s=dkim; t=1508336768; x=1510151169; bh=1f+jgWOjhkHE3kxDQpE6/WbVpXSfb0pa kkzcX0zpSyE=; b=ba7jRJjFDRySCx12GMieihMnaqWpWsxtOoDnSUrLrerh1kXE 35pLskmtKoW3pJAQxuKuNKSg+q3n5g9R/CSJRtD18V8PdZ6v9U/22fxNinT5Ra3v +qzEPnqDWxu/lhmrHzJfJfVzynYIc0Mog+qwkR6zat7/EuLOyrYWeLiX5+aroZSB KXp8BBLy9ykvWF6p+Zh+ClYk3ZYxtsiz7ygDGwgfLIbm42JtXDy7y6FGwrfYW3LG TKLDL0vgBgsvk/FI3iAQqgZc/5sy1RVjj2O0FfoAAaak9ZMcV3cRBn76ta5WcuBo AjYr4AkkppEFhZfm/+JfbVLvm98lFMlJoMlCdQ== X-Amavis-Modified: Mail body modified (using disclaimer) - mx.ixsystems.com X-Virus-Scanned: Scrollout F1 at ixsystems.com Received: from mx.ixsystems.com ([127.0.0.1]) by localhost (mx.ixsystems.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dbSA4XYKHwce for ; Wed, 18 Oct 2017 07:26:08 -0700 (PDT) Received: from zm01.ixsystems.com (unknown [10.246.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ixsystems.com (Postfix) with ESMTPS id 3yHDrJ3yYXzCqQX for ; Wed, 18 Oct 2017 07:26:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zm01.ixsystems.com (Postfix) with ESMTP id 88A081A11FA for ; Wed, 18 Oct 2017 07:26:08 -0700 (PDT) Received: from zm01.ixsystems.com ([127.0.0.1]) by localhost (zm01.ixsystems.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id X47Ls8niBjs5 for ; Wed, 18 Oct 2017 07:26:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zm01.ixsystems.com (Postfix) with ESMTP id 249DE1A11FB for ; Wed, 18 Oct 2017 07:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at ixsystems.com Received: from zm01.ixsystems.com ([127.0.0.1]) by localhost (zm01.ixsystems.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QR_NtLDcvTsp for ; Wed, 18 Oct 2017 07:26:08 -0700 (PDT) Received: from [10.231.1.89] (unknown [10.231.1.89]) by zm01.ixsystems.com (Postfix) with ESMTPSA id DD5761A11FA for ; Wed, 18 Oct 2017 07:26:07 -0700 (PDT) Subject: Re: boot1.efi future To: freebsd-arch@freebsd.org References: From: Kris Moore Message-ID: Date: Wed, 18 Oct 2017 10:26:05 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 14:26:22 -0000 On 10/18/2017 10:15, Eric McCorkle wrote: > My $0.02... > > I'm in agreement. I've been down in this stuff with the ZFS EFI > support, and lately the GELI stuff. In both cases, it complicates > things quite a bit. With ZFS, it meant I basically had to do everything > twice. With GELI, it introduced a number of complications, and GELI > probably would have landed over a year ago if it was just loader. Going > forward, I want to do some signed kernel/modules stuff, and the > existence of boot1 is just going to complicate that as well. > > An interesting point: back when I briefly took up EFI support as a GSoC > project (which I was forced to abandon, unfortunately), the prototype > *did* only have loader.efi, which was installed to the ESP. So the plan > should work. You'd have to modify loader.efi a bit to alter its device > detection logic, but you could probably salvage some code from my boot1 > refactor (which is actually modified code I stole from loader.efi anyway). > > As far as my work goes, this won't cause me any problems, and in fact > will simplify things. The GELI stuff mostly modifies loader anyway, and > the actual GELI EFI driver works the same in boot1 and loader (by > design). For secure boot, getting rid of boot1 avoids having to haul in > a bunch more EFI APIs and debug signed image stuff. For other work, I > can't say for certain, of course, but I've been working on this stuff > for a while now and I can't really think of a use case that makes me say > "man, boot1 really solves that problem in a way nothing else can". > > So in summary, I don't doubt it was a sensible decision at some point, > but I'm in agreement that its time has come. > > On 10/17/2017 19:18, Warner Losh wrote: >> I'd like to remove boot1.efi. It's no longer relevant. It was a useful hack >> to get us going, but now it's becoming more of a liability than a win. >> >> There's a lot of work that has been put into it so it can understand every >> filesystem. However, in doing so boot1.efi has morphed into a loader.efi >> without the scripting interpreter. Let's just kill boot1.efi and load the >> full-featured loader directly. >> >> boot1.efi used to have a role to play. It was a tiny, rarely changing bit >> of glue in the UEFI world. It is now none of those things. It has become >> rather large and bloated, and there's work to make it even more so. >> >> My proposal is to fix the one bug in loader.efi that would preclude its use >> as a primary boot loader (it sometimes guesses wrong for currdev and >> loaddev). Once we've done that, we'll use it where we use boot1.efi today. >> It would also simplify the load process and make it easier to implement the >> full EFI Boot Manager protocol from the UEFI specifications. It should also >> make secure boot easier to bring to market. >> >> This dovetails nicely into some of the other changes on-tap for FreeBSD 12. >> efibootmgr is coming soon (I'm reviewing the code from a coworker now). >> There's plans to move the FreeBSD boot loader to >> \efi\FreeBSD\loader-$ARCH.efi when that goes in, since we'll be able to >> point the LoadOptions to that. There's plans to make the installer create >> the EFI partition rather than just dd the efifat file we're doing today. >> Plus, there's work underway to move all the boot block installation stuff >> to a new script (install-boot) as well as efforts to make images for any >> bootable system (spin). >> >> There's lots of details to get right before we can make the final switch, >> but I think it's in the interest of the project to do so. >> >> Comments? >> >> Warner >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" +1 here. We still use boot1.efi in TrueOS but if retiring that brings with it the aforementioned improvements, then bring it on! -- Kris Moore Director of Engineering iXsystems Enterprise Storage & Servers Driven By Open Source From owner-freebsd-arch@freebsd.org Wed Oct 18 14:42:39 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74884E3AD51 for ; Wed, 18 Oct 2017 14:42:39 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6139780328 for ; Wed, 18 Oct 2017 14:42:39 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v9IERqel028912 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 18 Oct 2017 07:27:53 -0700 Subject: Re: boot1.efi future To: freebsd-arch@freebsd.org References: From: Nathan Whitehorn Message-ID: <20c83f27-42d3-fd4d-1e4f-adf1b74857ee@freebsd.org> Date: Wed, 18 Oct 2017 07:27:52 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVYE62LvjPseNKHN61T4EF2EXccaXXpfvpZWSqNoQZND2I2YjMraKOaAhPJf56tM5SVCk+A3MFMdz1P+RGcMzUspxPqrNpAsX4k= X-Sonic-ID: C;dix+hhC05xGN2oKfRUfeDw== M;5JXnhhC05xGN2oKfRUfeDw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 14:42:39 -0000 On 10/17/17 16:18, Warner Losh wrote: > I'd like to remove boot1.efi. It's no longer relevant. It was a useful hack > to get us going, but now it's becoming more of a liability than a win. > > There's a lot of work that has been put into it so it can understand every > filesystem. However, in doing so boot1.efi has morphed into a loader.efi > without the scripting interpreter. Let's just kill boot1.efi and load the > full-featured loader directly. > > boot1.efi used to have a role to play. It was a tiny, rarely changing bit > of glue in the UEFI world. It is now none of those things. It has become > rather large and bloated, and there's work to make it even more so. > > My proposal is to fix the one bug in loader.efi that would preclude its use > as a primary boot loader (it sometimes guesses wrong for currdev and > loaddev). Once we've done that, we'll use it where we use boot1.efi today. > It would also simplify the load process and make it easier to implement the > full EFI Boot Manager protocol from the UEFI specifications. It should also > make secure boot easier to bring to market. > > This dovetails nicely into some of the other changes on-tap for FreeBSD 12. > efibootmgr is coming soon (I'm reviewing the code from a coworker now). > There's plans to move the FreeBSD boot loader to > \efi\FreeBSD\loader-$ARCH.efi when that goes in, since we'll be able to > point the LoadOptions to that. There's plans to make the installer create > the EFI partition rather than just dd the efifat file we're doing today. > Plus, there's work underway to move all the boot block installation stuff > to a new script (install-boot) as well as efforts to make images for any > bootable system (spin). > > There's lots of details to get right before we can make the final switch, > but I think it's in the interest of the project to do so. > > Comments? As the guy who wrote boot1.efi in the first place, I think this is a great idea. boot1.efi exists to make the boot flow on EFI more like non-EFI so that loader can live in /boot on filesystems (UFS, ZFS) that EFI doesn't understand, thus preventing the need for a bunch of special logic in make installworld. It has seriously outlived its usefulness. Thanks for doing this! -Nathan From owner-freebsd-arch@freebsd.org Wed Oct 18 14:49:06 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E979BE3AE9F for ; Wed, 18 Oct 2017 14:49:06 +0000 (UTC) (envelope-from lev@FreeBSD.org) 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 CAF8D8057A for ; Wed, 18 Oct 2017 14:49:06 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id C68B1E3AE9E; Wed, 18 Oct 2017 14:49:06 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C61F1E3AE9D for ; Wed, 18 Oct 2017 14:49:06 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 54B9880578; Wed, 18 Oct 2017 14:49:05 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.19.110] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 3D056E2C; Wed, 18 Oct 2017 17:48:59 +0300 (MSK) From: Lev Serebryakov Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot Reply-To: lev@FreeBSD.org To: Warner Losh , Brooks Davis Cc: "freebsd-arch@freebsd.org" References: <20171012165655.GH68389@spindle.one-eyed-alien.net> Organization: FreeBSD Message-ID: Date: Wed, 18 Oct 2017 17:48:47 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iqVh9Q65Rcktr0JRsXLCnGWNU6Ge92eLn" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 14:49:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iqVh9Q65Rcktr0JRsXLCnGWNU6Ge92eLn Content-Type: multipart/mixed; boundary="heFrND3gaq79M0OhSWdRE5x482DlXO8oC"; protected-headers="v1" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Warner Losh , Brooks Davis Cc: "freebsd-arch@freebsd.org" Message-ID: Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot References: <20171012165655.GH68389@spindle.one-eyed-alien.net> In-Reply-To: --heFrND3gaq79M0OhSWdRE5x482DlXO8oC Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12.10.2017 20:37, Warner Losh wrote: >> On Sun, Oct 08, 2017 at 11:45:37PM -0600, Warner Losh wrote: >>> I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. These = are >>> really parts of the boot loader with an unstable API and shouldn't be= >>> installed into the system. It's really a private library to the boot >> loader. >> >> Kicking it out of src/lib will be a good thing. It doesn't make sense= >> to build and install as part of the world and, for good reason, doesn'= t >> follow normal rules. It was a pain to deal with for CHERI and I think= >> we've disabled it entierly. >=20 >=20 > Yes. I've moved it into sys/boot. So now it's possible to hack on it w/= o > crazy gymnastics. The BERI boot loaders do interesting things in the tr= ee, > so I'm not surprised. >=20 > I'm contemplating moving src/sys/boot up to just src/boot (this mirrors= in > some ways what old-school Unix did with src/cmd/standalone and src/mde= c). > It would build, but not install, as part of buildworld. All libraries w= ould > be internal / private to the build. New world can not be build with WITHOUT_CDDL / WITHOUT_ZFS. It fails in "boot1". --=20 // Lev Serebryakov --heFrND3gaq79M0OhSWdRE5x482DlXO8oC-- --iqVh9Q65Rcktr0JRsXLCnGWNU6Ge92eLn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAlnnadhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5 NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c R49NjxAAlciu1haJ1dpJLSpKuIlgjJVJNcsamUxvzchxUXNOf+9CX/ZpdFNAX9ri BeqKDEdT8FhneDjtEJ45X6W/xmV3SkMnxf+XJQUYD9NcrMHWu8BsBhWlamygO6Wv nA3WP3NUOB2wkhLPshAW9N2h5j+rwYxVO6uvaj76OQRrgAt/ttE4B3P0o3drui8Y U8arDeMCkaf1PRZbAYBtxFZjoRFquxrwxcyvnv5rLJnLXz15IwnX/QiJrZqbzTOX aLAoMX2pYRL0Dizw1qkPr8z3rp+3hrnskqx0apHlPXNoWAb/JFyZYBpXnmzrJO1y 87WvvIdL5lFEmShFqGfrn2IrzeXfwbEnhOuIxfcEvsETQ/0QOjfLH4RyuLy/GGg4 eOlHgjzUjp9IG/pRO2L2TR1fwz0H1aKouKQuFkrzzP3r/Z0FzxObpvXK7JgzkCP6 HnzXn/doPqOl/cwRuwdqc5lOgAv100mmNssFwSJtCE0vGpED1Jm1pwzdtzGm68vS q9Lf9wA5+ZUc1vJiavfTn5Md6wRQxGBL/kZFfpvi/L7MGFTS4yHTZilwV8T7mvwM xKyAkvPpty7jqhnQdUeN36ILeFhx9dYLcbLY+wWqFCKbN8Hw9ID0Li/eoqSPhOtB XXGT9Hx7/4zPh7j3FP+Or2KqKlNVzk3TEnoAW5pgdW90Ly4699g= =jJG4 -----END PGP SIGNATURE----- --iqVh9Q65Rcktr0JRsXLCnGWNU6Ge92eLn-- From owner-freebsd-arch@freebsd.org Thu Oct 19 17:03:04 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE905E40D06 for ; Thu, 19 Oct 2017 17:03:04 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id ACDFA7144F for ; Thu, 19 Oct 2017 17:03:04 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id AA9FAE40D05; Thu, 19 Oct 2017 17:03:04 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8845E40D04 for ; Thu, 19 Oct 2017 17:03:04 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0108.outbound.protection.outlook.com [104.47.33.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 517727144D for ; Thu, 19 Oct 2017 17:03:02 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WhDTaBJRKlFjUq2fwlRaCphHJGTzMU6h1imuXE7x5oo=; b=NwLKIY4tezw2fJbWzwh+0hq6lzrFij/ep3JkJN6SEX7luiVn4Ts+eiROaZG9wo2JpCdQofbtV2wNO1L+sgZvr8WVq+67HIKjTamJHTBvLaUAWtNsy5saDodHrU1RjIxL8Di3U4PhXopfvKEpohU5op4UDF0E5SB2/j0ZJVyTUnM= Received: from BLUPR05CA0081.namprd05.prod.outlook.com (10.141.20.51) by BN6PR05MB3602.namprd05.prod.outlook.com (10.174.235.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.2; Thu, 19 Oct 2017 17:03:00 +0000 Received: from BY2NAM05FT029.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::206) by BLUPR05CA0081.outlook.office365.com (2a01:111:e400:855::51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.156.4 via Frontend Transport; Thu, 19 Oct 2017 17:03:00 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; bsdimp.com; dkim=none (message not signed) header.d=none;bsdimp.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT029.mail.protection.outlook.com (10.152.100.166) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.77.16 via Frontend Transport; Thu, 19 Oct 2017 17:02:59 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 19 Oct 2017 10:02:47 -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 v9JH2lV2011774; Thu, 19 Oct 2017 10:02:47 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 5EFAD385568; Thu, 19 Oct 2017 10:02:47 -0700 (PDT) To: Warner Losh CC: "freebsd-arch@freebsd.org" , Subject: Re: boot1.efi future In-Reply-To: References: Comments: In-reply-to: Warner Losh message dated "Tue, 17 Oct 2017 17:18:24 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44306.1508432567.1@kaos.jnpr.net> Date: Thu, 19 Oct 2017 10:02:47 -0700 Message-ID: <44307.1508432567@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(2980300002)(199003)(24454002)(189002)(23726003)(6916009)(97736004)(2950100002)(5660300001)(7126002)(8676002)(305945005)(81166006)(81156014)(356003)(8936002)(229853002)(47776003)(46406003)(50226002)(69596002)(77096006)(7696004)(478600001)(68736007)(2810700001)(53416004)(9686003)(106466001)(107886003)(53936002)(105596002)(54906003)(55016002)(76506005)(316002)(86362001)(117636001)(6266002)(97876018)(6246003)(4326008)(50466002)(189998001)(97756001)(2906002)(16586007)(76176999)(50986999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB3602; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT029; 1:qX92UeBTZ82ZKrUIqsu8TVlcVF0GMiAvm5g7pvbZWw5y3sNsyzRE7T9qAJ7/xlgr7oHIM5yuVqPrb3GE/Kn1TjRhQ3PgUb8hcs2ig5y+NIonsXlak0aCHahDSLinRy6i X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e2ca0164-077c-4a3a-4e70-08d5171340be X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254171)(4534019)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199)(201703131423094); SRVR:BN6PR05MB3602; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3602; 3:kkyvAih7S1jkvsChIeTHTvVY0tWpE3H7/M0LA5ypY94YA4fk9TMu5lYnVKCq+xhIFB6LEwt5CAQVP5HuHFU+qlk7RcfLAEdD8m9ewmZfI+fRa3ncYMe1nNbaY6IR5gfflBgNXqwgm+llh1QUYYZ3nzSUy9VUxu/qa5nwwnRnyqilZcrrfDNebj/fzviYT2mQmtUAz9yY/VWoMFdioOEG+RRcoMKOz/GaVoouhC7myVQn2/gJ0rqgjbdnBacX57XzXRusAjx3brz5RBJAjlugG7MsKZaJkJXVE/PxzCJbBqA1lpy5WhOynR4nkLuQ6+i6efYHNhWwXEJ1sS0kd3a+gcEdTvCqCnlOsfCzsfGlPvI=; 25:o7u3UO7DooIHlfkFS4iRk2OLRiHaMg7dKUJUf2Z4DQqaARQc9mwBbccVKoilNSzEJeWNtS7MTYEBaqYg+5TQVQ7Ky9nV+G8y5VZRuPH1cbQai9rzYoo5ZiL7Z1g4SvRX6KK/aHN/6l90lwKbxwJD7Os1lEc/tIMoNukM1SOjhxGIBYOBOEilMtAXchJqwLq8JGk9TEbulOLhjDcWz/84KA+I6usEFr3xTfE7SKTNTV6XEhcIcbzURp027XlQjqKqvkzRFI9IzLUbesRUQiU0bti4KSCFwUjpnbJBAYIqZdDhvM4oG2tjA+cgU6owV6DO+JZ6YBwWbKDMQpLrri5r6g== X-MS-TrafficTypeDiagnostic: BN6PR05MB3602: X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3602; 31:KTDPN+XAV333U555rQAEWzb79CUdgm69KGSAixnrboogGrIUR23UWirCYfLlwaRUIhSFFwRzU9X8Mmw9iZURDw/qcxQIgS3Rs/yJC6ydwId5u0gMkWHdhbimDly3L+Qe5wuBD2rAVHq3eZiEtagMPpMevTrT/MXhUoqJlbq3ycVRhal4QiTU0egYWjo/TVC9ChA34u2YGTeVhvbHEmybdrsVFwg2L8cGEWqrefKqfig=; 20:eo7PpIYnrenZyAM2rVy9VoFwxuE0Z4KQBBUWkLof/Vb4YuFKGSlmzXz0ZkuXhPPa13cXp7eJjFoBPq3gqyPffCwMoY6dUXZ+Jg1s6fqgvQ0U7SzksEybN/lkq6cTpsPBioLuT8BuJfiaKW4Zv9V7CvOmOv2FavwbHsECUbKRjfmFDF6we9kFJ5EsHHGj9dvZHiyRvGqq36Tr53LKtvlsKRxR8C3YjF8QcxELueChWRjwHELa2K0pc/US/fJZloEY+YUogw0Pf0R15gzbjpy+bCZCkxD+g96sYeOoC8nrU/q630cUXcvjgP043V+WGr/nCwCs4ldPDsmYMOoxPtv2lZ+p5kCjWyN952+hrOZgMY3vLP4fbGD3XZqU9rypVtOpi+WtsmoZrBejSnIK2L5AqiRktc8vN1SiG7+OzLvxrQAao7jxmHeOZa8zQFkbMAvRlSFw71yuifLaaGKsTZoOSXNGjBkBaTatMkVp3nEwhvJ/l4mIi8MGeQ9IfsaXwTwp X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93003095)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR05MB3602; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR05MB3602; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3602; 4:hwKbmt0DyolUecU/hdM7R0MKP8QCuyxebvDOdTR69QujMnSQ0Q8SCL9Hnn2iQEmwAE9e4sqNyWXIr4DAUw+imMKv92C7djNdXxMWYQMziHmyLfAAuyvtLwll5gQX4ZwtJbLvj0Hp1GVDcfvQNcMtzeBTHg6xVPczyfH0zkG9tGs1KLk0e2N95zPnXWwAM6OPZs7TzSzQNp1QMnFP+VLHyu/BYMxe3R44OjGu9/0L//4CUAMUmlEfZ8ZeSIqYlLVe X-Forefront-PRVS: 0465429B7F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR05MB3602; 23:ht5NkJ1AJUH3HgJH9J+Mi0JPh69DDJlpcv0UecL4c?= =?us-ascii?Q?IzvPwAt41ZUQ4FtQjWCZlL0VoXMuGrjiYY3G0DAJk9a7zGWYBkawY9TRY1Xb?= =?us-ascii?Q?Q11OgC+VX1XShJNfA/iLKXSZjAVZCadJW+b9Psu8Q4dnr+rYoOPMSlwgYQH0?= =?us-ascii?Q?HFL/da6jPpxP1D0gb9WiEJRriJ12uo4Sj6uj5QMi743vgt+NdWuTOSjTUfTh?= =?us-ascii?Q?M724ZzNbGq1Tw0RBTg5g8178eKe4A9nHn/AZzz36R3V8Ti+uocXaP2q6IooS?= =?us-ascii?Q?fdFY/tNtkYnKI9PQxvwX99UqHhi2cx5VDCp554U9RNQVJZ4e8xic5DMEjkT1?= =?us-ascii?Q?geHpry7EzOa0OrnubqxE4XmSDPTh6HwKwB6RtckRA1fFsUlw581vjvzplP7w?= =?us-ascii?Q?gDWxtit5c0ZzNNOX5z2hg77iGhFfpr3BdfkvVKiWnZ/jvrIeKCxvmnorbMO0?= =?us-ascii?Q?IIoPyWus3vptiTbbymolgcIHfig6ITIUJkWycFjpnjFkM3LEMsPZvb/KmUS4?= =?us-ascii?Q?w2wzfknrmeae+20g0FDiw6j/svt8IhhwA82uY092HzRe8F+CYmyoDflPkHTf?= =?us-ascii?Q?scllU+XlbZ270FTcx0dKk7KFIvdnlEoNM+FZ+umx05iJAB9qlI2FCRK3m/fX?= =?us-ascii?Q?p+DFpI4DQsc5nb0hD9DiEURyiGrGFOgSwvR5BpBBk5R0doN/kcjXm+OuSnub?= =?us-ascii?Q?YjWNsXakAcets6avY57Scf4jBlaMTFOGi2IeJXibuVF7v+kJkorAQBSI24Ms?= =?us-ascii?Q?UBqbXQe3IkyA+LKqLpoXu306fj3/jbWHVRA8hL1dvSFJWWVOxSLHQWSvyf4m?= =?us-ascii?Q?xTDCarGL197qPj5JmznjB+0539KaZpvLmNKR2RmpVUTSUx9av2i/21MoIbPU?= =?us-ascii?Q?4lhiRkEIIEXMBF27wNIutFzLTfBoM0CDNeBxFb2HSSH+dDzqdueCI26ERou1?= =?us-ascii?Q?+q37VSbV2J9bVuQ5889412G7bxerg4hS/zO+BpbNhePgcWo6uP9pu6gIE0ME?= =?us-ascii?Q?KWzE3eLx8GnPeFRatM1fKhM7aK9r92ncLrhhcw4EHdruMK2GW/SBoKeqpFID?= =?us-ascii?Q?b7vZrAXkFZwOh5YKJYkst+nm5ypFW7WzAgxxP/7B4SqY2EVkdYzQHFwuus2t?= =?us-ascii?Q?ny1hTXZOhkslYnHabk7oH7FPkXz1exrCYXnUe5VgZ5fb4h8KZ7ZfG6sSQm0W?= =?us-ascii?Q?bs0LHqXEZ8Bez5VzTY6Uwelozra/eFbtP5TgsnXrjXzSzeHZLu2b6B9JM9K2?= =?us-ascii?Q?cObMGliMQUic+Ifd80=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3602; 6:QCh9iU2Sdfh9/0QlLBPcbs6TONuTVeEqolGkr72wgW7GKdProCfyHGIQk1A1lf1UItvTXYM0kQ2PwSvXAu84WYQsEqt4awAssLK6GDl/jT/5jFnUM17+EkxXlIsyGY5MKgqie4vTpWzC3QLW98BPZFECvbbaAMG+bj42dHoVR5S+brphOpcRVHZtL+JFnB72axFkDAn5zNFxC8EImvqCJ6oio3aXP1TaKrf5FBl+mwyYHQIn911uyZ39bqeckWSjkvrBBaHscf5PrwD5q2M8GPF31O+exC4F4rohdX7IaVcF5e8qV/IBJd95mcQmyc9IZjzPVp38xx9z6dp26aXqnA==; 5:ZoNyW/tygBGiooo7FUaBm2F2go9mDJNUB4J4Rkgys3hPffKucnqWjYMvSSB54AS3DNPItZEnzWKwnED3rJDgu+rsZ+TbtljqxWVuhnsLo0W/6unHpInR6RVxvytk9GZWL36vYc+4E/nqMHu5dU9DfcJwEHayYwsBS5/Nf7DpwWY=; 24:BNwwS6zmXJAVwEMWfBLfy83aeZhClVlO4eRgfBsbJDKqXD9vlbll5yZeTki9Jw9IhSPpDMLPTf6SEGepo1Gve+rpAxgv09EZ6wqJG1Pi+jg=; 7:3s7nLYKxDBuK2Y+kY3q8o6Mp4EZ7WB+mBwoGJU8bPdKZji4btp3pa/Xc6tv9nA6e5/8f1PC3chmjyzhekApPXuVuNS8KehMJNtLOwp8Ldbx19fSRHILC0x1wemTHWcqAG3vyFGoSZ2BQQek80f+YG/irSMumm0fGTe4fjPHD0eXQM0FirdBCQqjvWiDzYbJ+opqffZuAY1XKeraTCW1O3trr01a4eAL9SngjhzgIVro= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2017 17:02:59.8480 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e2ca0164-077c-4a3a-4e70-08d5171340be X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3602 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:03:05 -0000 Warner Losh wrote: > There's lots of details to get right before we can make the final switch, > but I think it's in the interest of the project to do so. Just one comment that may or may not be relevant depending on the overal plan. I've implemented verification in the freebsd loader, along the lines previously mentioned, for us this pretty much closes the secure-boot gap - loader verifies kernel and its initial rootfs so init and etc/rc. Which then gets us to mac_veriexec. >From that pov the initial boot bits can change as you like without affecting the above. Is that the plan? It only matters I guess in terms of the effort to upstream - assuming there is interest from other embedded vendors. Thanks --sjg From owner-freebsd-arch@freebsd.org Thu Oct 19 17:19:00 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2589FE413A5 for ; Thu, 19 Oct 2017 17:19:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id F3F8771C7E for ; Thu, 19 Oct 2017 17:18:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id EFE8FE413A4; Thu, 19 Oct 2017 17:18:59 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF4F5E413A2 for ; Thu, 19 Oct 2017 17:18:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 B444071C7D for ; Thu, 19 Oct 2017 17:18:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id 134so10602300ioo.0 for ; Thu, 19 Oct 2017 10:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=N5WueNrUqZry9hyiLpMmtBY6Et1eW8yiYA0Sg7J4Rmo=; b=thuS2nSyEHo6KP99mqDURPQDKRgqzTPLtivdzFE3rmiIqn2jZz4rDf+wPgyxHwU38M rHUk7KHmBm1sygnRXkEQ9hzQ17LW99p+JFZgaIC9G2JuAEyYg5jOA2yEjzPpzUTOgEIJ GUkRJxSjqVcrAEc9lxNo0scqbYQVgkz0t8BraIa1iU2cJJOCURdWn1Sf+wIUo8mPPaGe /uTdrvtegkyUa9ah7PHTX+Ol5C52G+dAVMZvn9/V0+uTyfsqlvG2OlssItzKZte64dDx n9dlTHogMaxDBudW1XGJKyAmrJP6QdZ+KF4+IszfZJBRGuIl/rreQjeTIoDUPe1PEK8q /8lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=N5WueNrUqZry9hyiLpMmtBY6Et1eW8yiYA0Sg7J4Rmo=; b=MINnkkNlbrWO9nvAK6stbVc9F8HT/p9dBrmTrE9tj7otCIHS9BOYJrDNGS7Y4XKkZI H8cHn79b7UfjIo27do0Y1ahdhgg9QBDf/iPHy2GoM2N80lNQsG/MP5f6y3y9DSjNElE5 eLJLss9rFtyUimbzosJcwuIKSSpXf4XqaUzsDRoV4Zbq8rYqUONVkSRC3S+PDGsKGTaF 54UkNAPOzhfvy+Ubfjv0W8QTs5qGz0P/45ldmMG6JyEaIyGARuu9BPq9E2/4UrBJyNHw xDB6pTIVxiPm0TI/mEIppW3oTKQ/kTMjO+k2E8Wu2ullDgnxgIoqvnYcD6yJT3UC1aCd CVBQ== X-Gm-Message-State: AMCzsaW0H5EbIrqX2e3T6alr/jkbMKNKiqXqmw7hpwbQ5ip+dCHsATUS 0HeP07TPQzVWse5DY276mVrBZqsJeU/qbkKAOh50Og== X-Google-Smtp-Source: ABhQp+TycT5pNISCNFo4lfJq8RSVPKu0viBKuh6xMSKQ55o8/hi3ewrWc6UdsxWgE3afwQIsMRiEhUgZRUXHhO+85lE= X-Received: by 10.107.81.21 with SMTP id f21mr2641139iob.63.1508433538903; Thu, 19 Oct 2017 10:18:58 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Thu, 19 Oct 2017 10:18:57 -0700 (PDT) X-Originating-IP: [63.145.217.227] Received: by 10.79.57.22 with HTTP; Thu, 19 Oct 2017 10:18:57 -0700 (PDT) In-Reply-To: References: <44307.1508432567@kaos.jnpr.net> From: Warner Losh Date: Thu, 19 Oct 2017 11:18:57 -0600 X-Google-Sender-Auth: 6hbrn6nKKm5iIT2nYR3k_anT954 Message-ID: Subject: Re: boot1.efi future To: Simon Gerraty Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:19:00 -0000 On Oct 19, 2017 10:03 AM, "Simon J. Gerraty" wrote: Warner Losh wrote: > There's lots of details to get right before we can make the final switch, > but I think it's in the interest of the project to do so. Just one comment that may or may not be relevant depending on the overal plan. I've implemented verification in the freebsd loader, along the lines previously mentioned, for us this pretty much closes the secure-boot gap - loader verifies kernel and its initial rootfs so init and etc/rc. Which then gets us to mac_veriexec. >From that pov the initial boot bits can change as you like without affecting the above. Is that the plan? It only matters I guess in terms of the effort to upstream - assuming there is interest from other embedded vendors. Thanks --sjg I'm interested. Can you send me diff for review? Warner From owner-freebsd-arch@freebsd.org Thu Oct 19 18:24:52 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88445E43A5B for ; Thu, 19 Oct 2017 18:24:52 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 44D8276403 for ; Thu, 19 Oct 2017 18:24:52 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id 44062E43A5A; Thu, 19 Oct 2017 18:24:52 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 437DAE43A59 for ; Thu, 19 Oct 2017 18:24:52 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0130.outbound.protection.outlook.com [104.47.34.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D813476402 for ; Thu, 19 Oct 2017 18:24:51 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=A7+znF8H48v5MD2e4Z3auVWZGb9XIYTwlJhBBEA6vus=; b=fjH6gFuXYU2caJJJbeezqxXOwBZxtL9YTlskyzkYOxIjlW0rypD8Y8sYWpg7rMx2bOVvMrGtLG443Zns7xbPtU9sTO3rBFNg9eKxfFeStGZDnlDjvXvhSmDYArRSrPUrxbYYHB7SsYHffdsFLjRRzEYvpNWQIlPLJD3//CcSgCg= Received: from BY1PR0501CA0018.namprd05.prod.outlook.com (10.162.139.28) by CY1PR0501MB2076.namprd05.prod.outlook.com (10.164.3.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.2; Thu, 19 Oct 2017 18:24:50 +0000 Received: from CO1NAM05FT015.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::204) by BY1PR0501CA0018.outlook.office365.com (2a01:111:e400:4821::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.156.3 via Frontend Transport; Thu, 19 Oct 2017 18:24:49 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; bsdimp.com; dkim=none (message not signed) header.d=none;bsdimp.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT015.mail.protection.outlook.com (10.152.96.122) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.156.4 via Frontend Transport; Thu, 19 Oct 2017 18:24:49 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 19 Oct 2017 11:24:48 -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 v9JIOmOc029014; Thu, 19 Oct 2017 11:24:48 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 49178385567; Thu, 19 Oct 2017 11:24:48 -0700 (PDT) To: Warner Losh CC: "freebsd-arch@freebsd.org" , Subject: Re: boot1.efi future In-Reply-To: References: <44307.1508432567@kaos.jnpr.net> Comments: In-reply-to: Warner Losh message dated "Thu, 19 Oct 2017 11:18:57 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <45599.1508437488.1@kaos.jnpr.net> Date: Thu, 19 Oct 2017 11:24:48 -0700 Message-ID: <45600.1508437488@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(2980300002)(24454002)(199003)(189002)(4326008)(53936002)(106466001)(9686003)(23726003)(97876018)(53416004)(47776003)(68736007)(97756001)(8936002)(76506005)(77096006)(50466002)(478600001)(105596002)(55016002)(107886003)(6246003)(6266002)(7126002)(6916009)(2950100002)(54906003)(93886005)(69596002)(305945005)(2810700001)(5660300001)(46406003)(50226002)(2906002)(7696004)(316002)(16586007)(117636001)(189998001)(50986999)(558084003)(81156014)(76176999)(8676002)(86362001)(229853002)(356003)(81166006)(97736004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2076; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT015; 1:ytNZdFC1adI3OF+PWUTOpwQ0PzuKUQyaqLxuj7A/YdNV1gHK5EYhpT0A5QxDRiwalNyBLdf4hcS6qGVF2+CpyR6slf0NsXepZMqsQAot9Cpt/qorJDtZuInvqRibu6j5 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 49a46b60-a0d6-4088-8a10-08d5171eaf05 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254172)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199)(201703131423095); SRVR:CY1PR0501MB2076; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2076; 3:5Z0DRj7xuPMQVQbih3jVFvAHHpNj03N3mMI4d9XgecHkK27a+uaTsxe85+iQql0WOZ+LM16JTo7poj/ATj6DYyLXfRq+1w29IN2BXVLVLGlP8XjVitjlyDAt8czmIx+f5tuveZ+ypaxSZGDoIwhgBXDL+CXYaBWg70mSwwTxsTTIHh9rAccb6P9Uj09J5rMhCoboAGP66+qOSJwOECEIvAtK3oiQeqidaLkTOBBGIFVLPqLfvllx2IvXMM7QKrfzPE+qXO7ix5Uco2Hh9es2Tz0uCzOzxm53/GNi1N25n6PTvkx0JjPUuWTqaO0nhuf9rffVbO4gqVneGosOcTNjAwug5CEo+apcXV8N1mgGais=; 25:gdonALSaLDaSrQJSt3fxAhSbBfedHWXaLEz9jdaQ+HbVze5Px6VNy4tLl5HgsbMipMEHfL20j3J+g6ZwNw2mf2SAiutYCB7DiDssHEZOYInu6hqRQ14ptJlviytiLpg90xv8tiJXgjvUZSQgGDTja6rd8Rw8tqewiA6aCIuENNxMpAA79aAfgzHAgjk3D2An0b/n0BJNwF9ZHSzOYqAgcK0tQ0p37iqxDPdux858/A26DMstYhpXiHqDze+dxyy4rBJPRh5oqAAiL9Ytvl/OwIpCUcqiEb9NzitDuipsSqvAZo0hMn74UsREYUHONAqWEO6hsGhBjFpXRzyMmebAbQ== X-MS-TrafficTypeDiagnostic: CY1PR0501MB2076: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2076; 31:iTR17Q2sgxD8+Ek4miku+G2vGN4ARxfem9OGTmgVFVj5qQHzpf6FwthCdY1nhviDkPST1zobGCtDWwcuvqz3IsTK9t7M8uSl3EhDqvccAnQL7gZKHiqnFF0AfyoQxIsFwd101UFruyAyODSN+qVcuga/x0fOJsFhFdYR7V7FYvhLAANrUpcTVUPy1yN/DOPWbYCVn7dfZxHbZoRhFxtojIU3o75HIlrafjd/smKNKeI=; 20:mzcd7H7ozJkH+BmvT6X92JpeFn2CavsXo1CAUzGehBEucSKLbEYhtCpWK3YNUomSh9K1Xfnc8vjmEXqMPZTnKqcayJ/I2TTP/0mTVnbiWkXHs1zaxO8gfS/zta5kFI8o/s9NdP4v2i/nfBrveRq5q4qbkP8ABQRI+yVMm2QgulVQBElMzLCgtzu8wrDXEml+y8Q8gf4FBSEseI88TsqveVw9r2KWqUTc1N7nL/AR0kDZLAquyEe6u/2Jf0zaxuLSlRUTZFV5SjHNbAKxiaygF3TUlv0qdtPoLl3YYNVS28UPtvPO53NdlrWG1+7UafvudyQhF+rV6ttFbTAXwVRIrQgwKcxYTTeiDh/IEjCW4XC2sm2iBMjIl1oKqwkbmB+L3ibE59a2xs7a1/ZvH4HWAtasjM79b2kThCbkZKd8WJmuRUvqR0EeX4XF5nEKfyz32Lp2tZimlTLxyyteNUZDFyRa6dS0IBI6MJ0hiHYOqFUNZ6rW5qNxhKnC1WIinWrC X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93003095)(3002001)(6055026)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0501MB2076; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0501MB2076; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2076; 4:0+AbMF8ZTKEuE/SpcnMj0XVcr6o9GtXKeGXYTPYLdrdXpyUlVs2Y6TjflVuWkgJ0VJrXjCQVIK/ZEQBrgF7z5HnVqiZSB1YUCOLMs262uf7VNJOAfKSC4ERyRcYtsb89RbXTBciW288n0Ul/GzrYEruUW/utZ3YR/aZdarQmwsFTD2W8wWbg3IX78+PRRO8vUsR5uJQBzlVQ3BMsJ01/6TJMFyJGP4BlwrH4vKxSmxaFJE2Dv5EB6nWaOZKqbHuE X-Forefront-PRVS: 0465429B7F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB2076; 23:hhUp98ms5CJ2HGBLIxUupp7HIEU7bvSOV2H/JfK?= =?us-ascii?Q?AEDzONumfrvkm3JOQnVuB7bznDN45Zv0qbVFLMNmT0SmD35cDeHmjl7Ww2qC?= =?us-ascii?Q?A4toPdSQXZ615CrIoJijN7W90PoUlh00zFps9sdaLO2H/oQbO/h0ISoBwp/H?= =?us-ascii?Q?W//RrFxMacxYQyK5IvVRW059J+b+3p346UGnCVmWnqBRV/OB/Y/JEjVon7Ge?= =?us-ascii?Q?jmEUEFPMrmZvPAWHhY6lEs44krJlTj7RgS10fvl6Zk9gbjqNZHWPUBjRT+du?= =?us-ascii?Q?UDoVTTOK/BkaH0nuYiZWO10Ap9kqHwF5Oy/861JFE3OyRoE21mkGigUQDLfo?= =?us-ascii?Q?+af+oFBgVvI+U8FXPwqxcdh2Xy5FwDGll1n67Vqkt6cK9X6qLSb1HpjexVoR?= =?us-ascii?Q?yCV3qe7rrr5rR3b3aML57UpTYl4TtMZsE+XV6YZ3+qXqP0e3bSzhCQa2fnwV?= =?us-ascii?Q?GwU1ugeRCXLs6NAxd9RF9ipcBGEqFQOM5oqSSn30TjjgOfwzRysjJoQgiI6K?= =?us-ascii?Q?Wqv+EgPw+RWPDQv5QB0/aqWF0YQwz2XpE8gu6ESAzVnEvP5ZBawFZf7OgA5q?= =?us-ascii?Q?fzBFV1lSl8WCpckLqO6I9GsWdNird07gTGdfd5WQvrvomo89XTPfpTGA7gf/?= =?us-ascii?Q?3kIKWK7/YarIoa/6JzaCeq469I/oBn31NlGgVibCYT3BlvAQMTTMedUezxKl?= =?us-ascii?Q?/Gl+v2BwjAM7kCNbTVAapAb+YFwIx19kkkFdR/e9Mev/GPSsczV2ap2yBJb+?= =?us-ascii?Q?Oj1oxWFujtxLU3rQIRO2rEHzalBMfGIg6159/f5vpOC8vL4t0usMBKgRmiec?= =?us-ascii?Q?mEf2P5flbKUcTQKRrWoEyBSB3dgPVf7+2KGqYBv1jS3F+iJ0icgxJi3VHxrT?= =?us-ascii?Q?MiROntc9cS/d1RdSCGmyFUu87JTjWuAnP1zE1bziKAQ55QB+9VcARPN3+cvM?= =?us-ascii?Q?HHYzsryxp6jVtFWiqxzt9JDIyyNlUtpIzo/THqqVAc8Ta0nAq4Ybm5w5FWIS?= =?us-ascii?Q?YTXYazrFjinxnTm/KBR/U3YJ9hB2ioPKa9WL/M4jacGwVrHgLspuqvAv/iib?= =?us-ascii?Q?uNaazBg6wCsBu6IuWM/giHF7exGUdtj9mPNfoA3cd0j1WJBUqeo1n5i3Pdv/?= =?us-ascii?Q?fGF80XVslsaYmrOBeBv3dAX+9VT6Z7081R/SP6QC+QWDmq+lihbOqy0KtVKr?= =?us-ascii?Q?r/+l+HiLSuk3xaFBZtQa7xBAsPL0jyy53riSvXMdHTJu16/YXLHnOriUjCoi?= =?us-ascii?Q?tl2o14cjN3aqnN9D6mrSsROi3HginX8/okz0Zo/j583Tl2/hssy9UG40jHXX?= =?us-ascii?Q?m3vhcDDzGVIdzn++IP3P8i3E=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2076; 6:SurFTizpN1xtCNOm51TeZA2qGSpN+9GWZg5hBGwray1crSG15lgIrJNgPNfkQQGiDpBuwcViLsyN3NU8HWIr+Wx3j77C7VvzYRcHChGZ4XKJAaGaBpnpHC+ZQtMfEZ7mKvsuUJpPJgt4/u+piewN+a11sEd70d9JhYhfguTIMvNXVtXy6AzvuMQjhDKjoCJnpnaAOAqC4VPdSWqNh97NbZNsT5IlY451jED/J1v5BllWpB8Ob9107qeT3v6vHY+ABdzMWjDtMIBHCugMmXka36u9nUtTVBGhExReJ+FUIwjXPp5FSoEgtgiv1R5/V7RUBvq5i4pGARvIklI+T/xlHg==; 5:pYdFAH/kiA/FzVaQmF62FYiNfeeH/TunNi9ssuDNSD07j7S9P140LVuUeatnY038edgXLTGCRx+kPtlTPTUO8I8L3VmIpFR7vm7FNTkt057hTwOFrn2ECI90SZLZtFzNtWkw2kD2RNN2XDAHd6eoXw==; 24:rzBY3GWXMlZTWS1yYQq9gErvqtxlu0TYXzg25GYxsztYhI/a0e7UPe63CpmCGjA3W4Oc18ETM1r3TydgKo4IhJqYAuCBfwWB51m4U2vhTV0=; 7:6ye0dNYD04o816X2NcqmXRXqpJFSZIOxom1osZkCEp06OIFBUyphVFDygvFUN+Gc48jglgnkV6logNOQw85R2t+ErEs3E9sLGqBbIXqW0S1eB2i90fWw7hQB3oI3jYowjUlH8+IYoxBQe2Scljv6KJs+fxS/vAFX/cG9jVz4v7avAmp1966o0/riCKRj9ROWQrbogRyWZk1S3eK+47bwJhaa1YRHYK1MszbYX0fKaJI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2017 18:24:49.2955 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 49a46b60-a0d6-4088-8a10-08d5171eaf05 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2076 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 18:24:52 -0000 Warner Losh wrote: > I'm interested. Can you send me diff for review? Not yet sorry... hopefully in a few weeks when the legal work is done. From owner-freebsd-arch@freebsd.org Fri Oct 20 02:03:29 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F90DE4CB65 for ; Fri, 20 Oct 2017 02:03:29 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 343DD632C3 for ; Fri, 20 Oct 2017 02:03:29 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id A90D32890 for ; Fri, 20 Oct 2017 02:03:28 +0000 (UTC) Subject: Re: boot1.efi future To: freebsd-arch@freebsd.org References: <44307.1508432567@kaos.jnpr.net> From: Eric McCorkle Message-ID: <56a95153-e970-990c-d3f1-453be4da7150@metricspace.net> Date: Thu, 19 Oct 2017 22:03:28 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: 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.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 02:03:29 -0000 On 10/19/2017 13:18, Warner Losh wrote: > On Oct 19, 2017 10:03 AM, "Simon J. Gerraty" wrote: > > Warner Losh wrote: >> There's lots of details to get right before we can make the final switch, >> but I think it's in the interest of the project to do so. > > Just one comment that may or may not be relevant depending on the overal > plan. > > I've implemented verification in the freebsd loader, along the lines > previously mentioned, for us this pretty much closes the secure-boot > gap - loader verifies kernel and its initial rootfs so init and etc/rc. > Which then gets us to mac_veriexec. > > From that pov the initial boot bits can change as you like without > affecting the above. Is that the plan? > > It only matters I guess in terms of the effort to upstream - assuming > there is interest from other embedded vendors. Do I assume correctly that this is based on the NetBSD mac-based verification stuff? ie. Not the public-key crypto stuff I've talked about? From owner-freebsd-arch@freebsd.org Fri Oct 20 05:06:20 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 306B0E4FD84 for ; Fri, 20 Oct 2017 05:06:20 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0119.outbound.protection.outlook.com [104.47.36.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6BD16809F for ; Fri, 20 Oct 2017 05:06:18 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SSpsTOXRU2Fyq0lAzM0FJ2RB/PdDzfLDLrWufUCoqCM=; b=ZLtsmc0ksvtqfavVD8WfP23V59a+of/33I39qws8sl6kzYHoRX3J7cO0OAtwLlrr7XbbyE8dB9tGuJ7e00uY1AoeU0ygHIVlKW2NwIgCbbvU7J3QNrIXqGqNOhHYquRJfKFTWgu4eVsYxmz5GnPXyb3IqLylVmDGo33GbS4cEE8= Received: from BY2PR05CA041.namprd05.prod.outlook.com (10.141.250.31) by DM5PR05MB3612.namprd05.prod.outlook.com (10.174.243.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Fri, 20 Oct 2017 05:06:17 +0000 Received: from DM3NAM05FT047.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::205) by BY2PR05CA041.outlook.office365.com (2a01:111:e400:2c5f::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.156.3 via Frontend Transport; Fri, 20 Oct 2017 05:06:16 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT047.mail.protection.outlook.com (10.152.98.161) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.156.4 via Frontend Transport; Fri, 20 Oct 2017 05:06:16 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 19 Oct 2017 22:05:51 -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 v9K55pNg030014; Thu, 19 Oct 2017 22:05:51 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 63412385567; Thu, 19 Oct 2017 22:05:51 -0700 (PDT) To: Eric McCorkle CC: , Subject: Re: boot1.efi future In-Reply-To: <56a95153-e970-990c-d3f1-453be4da7150@metricspace.net> References: <44307.1508432567@kaos.jnpr.net> <56a95153-e970-990c-d3f1-453be4da7150@metricspace.net> Comments: In-reply-to: Eric McCorkle message dated "Thu, 19 Oct 2017 22:03:28 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <82994.1508475951.1@kaos.jnpr.net> Date: Thu, 19 Oct 2017 22:05:51 -0700 Message-ID: <82995.1508475951@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(2980300002)(199003)(24454002)(189002)(86362001)(68736007)(229853002)(53936002)(6266002)(316002)(54906003)(16586007)(107886003)(6246003)(47776003)(97736004)(50226002)(97756001)(117636001)(93886005)(9686003)(4326008)(55016002)(46406003)(77096006)(76176999)(478600001)(7126002)(2906002)(105596002)(106466001)(189998001)(23726003)(53416004)(97876018)(50466002)(305945005)(69596002)(8936002)(76506005)(5660300001)(81166006)(356003)(81156014)(8676002)(7696004)(6916009)(2810700001)(2950100002)(50986999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3612; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT047; 1:ISiCdkD9UXR3jvqgc+P6+Ukw6eeCcESoG7BBZ4DzJllGbHCwnlG2l/x+KlK1u27hdTRE1YbLkeN71oQoVfdnGMw2i0R7jbkLj8d71ZhodfN6twT/nFPTPQiPS/rKKZVm X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 24048f34-1787-4d4a-4a9c-08d517784b15 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR05MB3612; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3612; 3:R3ImpHWgH9eycjAwil5ec5/zOEFJIY36MlvyIDRWzw6QArJuEv7xi/wjhkP78qQ2shflgnPjXbmXSt/g3GltVoQ1vx4LPqUEVUrizK/JeYJbJ6daplSa7McNH75YRWDGE4jM12PFmyWNZXwPZsptenYdxubIR91Ezx27Er7P4o80syjz/GbBSKXmWx99Gj1l83eu5x1EiVhK9QvWfassWDRnM1+BtuoQMOqjmwOsnqIvOD344zLuzKOzBYraUR3evWQq4VcxtDVU04d6bnFPVsfXR13c9B+ccso1ef1zf563aJDbn2es3HcJt65RKbA9P+pbbEYVpPm9KedFjnX6MWrs5CPWWtrLqbIw/HNDASc=; 25:JQnfbo5SNbcr+m/t5zzz/Mts+Pc1w25dAaXRUfETZU/M0mBd4jkvxcCT9VYXCLJtXvLbwXcHTBosIoOYv6ZQn4zx2wL6qiUpGZpMxu6KNOtWn5Zfl/ZwDtkO7mF2/LfzyQRgFXyJq6tmZK2LrYFXvE3TrvH1HrIHWxFPU8hDJin/CGFxk9gNEHOGicd+BH3EIe355CcDc/xrmNp8feuH4YuLBKQYKimf4NYzQP8dJqJYMVAPv87gfZ8kbfayYlMq3qEa404uOEwWzW2nnb1gDuAIOOdtqh7YBz5Dv7sIzWi8VJIzkX/pLNQfAn3SIdhFSiPKyxRe8suSacwKnob3kg== X-MS-TrafficTypeDiagnostic: DM5PR05MB3612: X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3612; 31:gWFQOIkk65/ilC4DcMAF603RvODEnzbOo+8GyGo9sR9lzkZP31SR/nWBQkkWJvh7dKz3je2QKEXuY+t6cfrSnqG4n2ek/02lqf/xdh9XFIM8SDaAjoTGPh0UFaB81Mzkmx/EeyYf3R+dDAh1ufBSSQYjvles3UKX0DNdh5gPCgmXYBcg8QtHwoCzGYCYhbckueoJIxbdSLRAFv4mYXkCk8OWDqeRSbTvy/PRKHLmw9g=; 20:L7UxkisAIX7XLMgS3yt7vsBzBBcUqN3yEEtXcH+4A7jzN8xUm3QKlx6YuEr/1ovyn9hZy1AklwcueX7CEv++S8M0WbEOVcM90pJeckuIL2SKXLfHRxx+IT0ff6jIUI4wQkrcnKUel2xONk6k7QoI2vbgayUdoYbZKzfe+Xn6fkJv+C5QCU+3Ky9QU9BeQMXO6N4sKsRzgdPM51ZVG583j1PzaJYwVGxLfbS8EHUI5jOURFOwi9WoqsDMnFS4peOztd8ouq15UqzjOMNkYPjsW1kxdBug+lWfLbGQ5oHtJIL43D6nmHFexJ+07j/N18JSEsZacmND+Eg3xJz+6ZP0VxIhNSa7YqHQRxcqE5QWM33jUFavpFdGKpkUV+HSdou1lMBiRgEDfA+3HC3BHHkRUQx9DLwhW/dwyY/f11Z3lXKEaUn1kCTIAO8PNGvMWwkKuFz/1P2dinfHALZnNUVW1OBhkM2/A/DLJiUKKMLlI3PnDcUAle2oHl+KOEzKe1sL X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231020)(3002001)(10201501046)(93006095)(93003095)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR05MB3612; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR05MB3612; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3612; 4:tk2D+UkIZpcL9ey2aQ7pXwCRIKp3907RNa1vQTA8AMjvH3XoeR/JXBKKx70bU5Ztum9OaHXH9HNs7sYwQ+4sPh4zGgjgoy+/1+NnVvpT95DNRAgkASDRpRgV5BcTgVWADnZ+YSwBCdi6NJENiUTkRnuUNL6AI8pWGL71NE5pqgb8UhtUah9g/ZdwJqs0mTdcH/gmnzNzNSg5AetouZHSS6UDCPQ+5ZfcA5UHWBUyTBj5/p7TFF85lmxmXDpbQU27 X-Forefront-PRVS: 0466CA5A45 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB3612; 23:s3LGzF3AUyf4dHZT3G57iXIgNbiWkcjwyTZJLcc5J?= =?us-ascii?Q?vNpoWoBPPYnOuE/Qo0J6+3Ao91Rcvc4CWm4WRbdgc8dx974xuxthI9j+FMCQ?= =?us-ascii?Q?arGroXN64bVIZIJaOQy6VFWKVyU9ar0cO/Ieyph1rEoesO3SV5TJDflrA894?= =?us-ascii?Q?epNYv8SYyoo0wxI6u7zh3XxQvAx+Ta911P6N2yegcrbZ27WiTyCkVb9wb5Do?= =?us-ascii?Q?DdYPksDwr2s7lo6GPRV4rMl3qDPOj420yhcGoQWSp6GcRRwBu7vfSl8ldKxl?= =?us-ascii?Q?bPVf/aR+Sqk9QHPcIIG93GNPpm306U2NZLYWZ59vaNL73056b5ltIlYnXtWP?= =?us-ascii?Q?uuavt4rVk38h+viHrBcjKOmFmA8Z3RQb36C021WRy44DqUqaCvkjAuPQiLnr?= =?us-ascii?Q?WwOLn1S27DdYYhX+nfzznVYbql1qx5TXXqX1s6H2LrC3g9ng6d17c17hZXdx?= =?us-ascii?Q?dWgr+WzNhQJcywWdlTTg2JlRqzG6HUyYp0gKiattgZPTbsIf3sRViSG8O63a?= =?us-ascii?Q?w5FZaXcuRSG90iE6UqAHjYnRxJ9UpKQVvIoxTdmY+gPNlLib7tU4UEklGNci?= =?us-ascii?Q?ENhVsX67o+0xWNQiCXV31VIqtj9IiKx0/JO2vcWloJSGOk96QJTYiVfRrl1A?= =?us-ascii?Q?u+qJjtwyHJjLF2bAWTt/HtJXUg3ryWNCwXx55gAYO2H8AVJtEmYLNWDHJJ1m?= =?us-ascii?Q?oaZ1FSEBgbkqh9u2Qxk01gjfM0X90yloTm12TuWFGOAarnfwLX+y5ICrmcn6?= =?us-ascii?Q?fHoSB+F6u9rwFG1X4Hc7CWD0qWsv5S1PQjFIq6pbBI81l467J9jyJkatBCY2?= =?us-ascii?Q?trb29yFsuZ0qzhv6PhR7PopaVp/vdTSKpsZo84pBRW0EEZTDv2cKAPGQAcJl?= =?us-ascii?Q?BDzzNKcKe+lGbdD6eCrOi9b/VE7ljT1fu7OQrc2qHkf7rOKrXOFQHsxfFGRf?= =?us-ascii?Q?FEjwmngssRoS9R9Q7nagxttaB8ujW2lMminu6HXH9Zp6U/bYtP9VpdMmmx6d?= =?us-ascii?Q?9fQftDNMdCDmfn3e/nlHeWWFDLAo+LsiQzHHSQJqbFVo5VXN0vzRuTIp6d0j?= =?us-ascii?Q?3Ln+k+20ILMM71L7JKgbcUcvNO8Cel0Y78vKyhdqxp8IgQ4hn8+F+hQPP4k1?= =?us-ascii?Q?MXf4ZOxnK9fjuAt6AN+cbEUajZUEM8sG0Ynwx1eYyA2ycE7iLDF2nQxxcaw+?= =?us-ascii?Q?uVaj7ssy/QFBZqdNdqnd+bfS0Jrf/ElEnMsuCYG5KPu1de/IEBxuxJM6Zind?= =?us-ascii?Q?8oWtNZf5Yxsrptsn9/qrDvRTvFAja59rvtXdaJY?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3612; 6:hjVaHvshB6oJ7QAPiL+fAizWh9+Oq+2XqxeW/wJK0X91acdSg2GYiDIqdKotKg20VguoDH/2xB55eY0E8aWu73yuqdy39cb6Q6t6U/VqLvMUuZKU037XUYiCpnErbNf/Hx1K3F3sIJBGnwBGX832QjvfvPufelgXzji03vXIqQ/MJrEyTcBHmBEj9iLmOb7CoOeUEWOZ5+DnK0EioD/iOEhIKLl1oQSsM+T/BOJyN1Rf78GjEneASiOItLa5n0jeupQuIc+KLoTC2K09H2ruZnHRX4bCKI7RZENClxFoP1wvyRpYj8GVEEl8s0Di/VF/ZvI8EcGvjpoyMKEAImjDRA==; 5:9NKe3TNituaLlJ8zJDbFjt2d60/LdxjnkpmuaPa2UZ/vQs4iuM9XpEG/yPHWyRdyvyKcUFO1GfDz1aayBd839qmd9npYsaNl8exfCYVWVxk05w88oJB2idXGXdLoFsymN6QVROOeLXAOeqhute9GMQ==; 24:72gSRwOK4aQPbbvSukpbPaI35DZ2X+9Yb636wceezNQPYiLNlNJ27hCuYy4y4ULDn2ll/RufMsJXHzHxBv3n3mRMpCpg9pY8WIE0slWvKME=; 7:q7bOi1ZhMp+44jIfeIYAHMJnP1GtniOKaWPDWbMfmFvx3dfhz2U7BL8QufdXf/f5MAvoapFqt5oSXTPUNlfVxLMlOQg/UST+iZ+lTVQdJ5l53EqAj0FZ2kC2SjqbZbXhbrMnU2s9bnCfm08Glur2Fd7qJhEKmEGVq/rS8WCFHMNxsubUYh3ADl6zxHktpsYRmj5CvsS1TcfCPHNMj9JOX90DovczUm7UNub6n8p6MX8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2017 05:06:16.2869 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 24048f34-1787-4d4a-4a9c-08d517784b15 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3612 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 05:06:20 -0000 Eric McCorkle wrote: > > I've implemented verification in the freebsd loader, along the lines > > previously mentioned, for us this pretty much closes the secure-boot > > gap - loader verifies kernel and its initial rootfs so init and etc/rc. > > Which then gets us to mac_veriexec. > > Do I assume correctly that this is based on the NetBSD mac-based > verification stuff? ie. Not the public-key crypto stuff I've talked about? I didn't want to thread-jack... I've not looked at what's in NetBSD in this area for a decade at least, but I ported the original veriexec from NetBSD to Junos about a dozen years or so ago. More recently stevek re-implemented it for FreeBSD 10's MAC framework - the diffs (most of them anyway) have been sitting in phabricator for a year or so... The loader implementation shares no code with the above, but uses the same verification model and leverages the same signed manifests. Thus it retains all the flexibility of using X.509 certificate chains to verify the signatures on the manifests. This is very important for us, because it allows a 10 year old binary to verify the latest signatures - provided that the RootCA certs have not changed. For Junos the loader knows two RootCA's one for RSA and one for ECDSA - that's all it needs. We can tollerate more limited signing methods for the loader itself, to fit in to various secure BIOS/boot environments, but from there we want all the flexibility we can get. --sjg From owner-freebsd-arch@freebsd.org Fri Oct 20 11:27:56 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE739E2F993 for ; Fri, 20 Oct 2017 11:27:56 +0000 (UTC) (envelope-from bcketchum@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 8A8B272B6D for ; Fri, 20 Oct 2017 11:27:56 +0000 (UTC) (envelope-from bcketchum@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id j17so12878531iod.5 for ; Fri, 20 Oct 2017 04:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=k9hgWvahrtIdZVvXd4RB/mJi6BiAzyjFhWoxBrL3V00=; b=aQJ1ovz40QqNhl/NzFxQdsgapO8zPZEQ0/kui4dVjIpeHkrw5zSkYbrbWs3fR+Lebe mTG/GYMlH77awru684x2tr20OKsW5Nkhtk4C5sUHL9F7e1bhQ4CwL1xfxd5AJGADMTFP LFsLtdaYHpc+2/yxh+XATWsl/wE9LuRVJl7K82AAx8Qu792MwzVOGm2pjjOi70q+KJDk nAvmeMboE9DWaEmO90O8gtf4aJZ+Tiy8dtYH/c2+Y2VY3kmVZdC0Iu386gbdoqSLOoxl xdRBfzQB+yjK57OKwePODhfoy2FaKvKaHMtV+wo8Q2UapH4IAKnqI3tDpBGBO191kZa7 q4AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=k9hgWvahrtIdZVvXd4RB/mJi6BiAzyjFhWoxBrL3V00=; b=gejY54Ldr6YwG/1NowHc6KSimmTIG7t32aGgmGldSzHa5LCm/61t+JmdFDWWCzKdnv w7yoNK2hL+yqwk4Firz3h77AU7wXT6FhibIHcAdWn0CvXpJEjxlfFcMi+hSjOgUiNmXM GvRVNVdLJ2TdMVfs/eyanbOHaCjn0P72SoM9F/UEfGIFspaKuFgQtQnn5RNexXuUJGLc 5Xol13LuF0mVArRQ7inWxfOssSSrukEaK1io2ho3r1Uz7Rw+f9OLab4bhFxwZQeDlEKV MTEWfRESuKqfPCYTl3w9MbtmGcUIaeHPxgcEs7IhXdZr1mbsKML/wPGyEwjv1M53x1zS zNeA== X-Gm-Message-State: AMCzsaU6WUXI6ysHBiex9GAUGfiX9nyydK1GDvMgI9tDQX+TzcgZxdcE 2N1pt8k0qSMRE+r1cY2xeYPFja9ZG5qK5J0yiKs= X-Google-Smtp-Source: ABhQp+Qch5Q3VJdZIt7KssCO0zhD6PMhXQiJq5m0Bxs7Cw5B7LQUqWoOS7Naa507G8jjYqaFYgwLcHV7A+otV0UZPRc= X-Received: by 10.107.25.13 with SMTP id 13mr5689128ioz.11.1508498875866; Fri, 20 Oct 2017 04:27:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.1.151 with HTTP; Fri, 20 Oct 2017 04:27:55 -0700 (PDT) From: Bret Ketchum Date: Fri, 20 Oct 2017 06:27:55 -0500 Message-ID: Subject: PEBS support in hwpmc To: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 11:27:56 -0000 All, I apologize if there is a better forum for this question. Is there any current effort to support Processor Event Based Sampling in hwpmc? Without this support (or a VTune subscription) understanding Front-End/Back-End bound applications running on Skylake/Kaby Lake processors will be difficult at best. I'm thinking to simply add a flag and either add a char to iap_event_descr or increase the size of iap_evcode to house the sub-event (EVTSEL). Decoding and reporting the captured PEBS records would need a bit more thought. Bret From owner-freebsd-arch@freebsd.org Fri Oct 20 13:43:51 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E5BAE34C3B for ; Fri, 20 Oct 2017 13:43:51 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 1EA0776874 for ; Fri, 20 Oct 2017 13:43:51 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [10.207.101.115] (mobile-107-107-57-17.mycingular.net [107.107.57.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 2F3B6295F; Fri, 20 Oct 2017 13:43:44 +0000 (UTC) Date: Fri, 20 Oct 2017 09:43:41 -0400 User-Agent: K-9 Mail for Android In-Reply-To: <82995.1508475951@kaos.jnpr.net> References: <44307.1508432567@kaos.jnpr.net> <56a95153-e970-990c-d3f1-453be4da7150@metricspace.net> <82995.1508475951@kaos.jnpr.net> MIME-Version: 1.0 Subject: Re: boot1.efi future To: "Simon J. Gerraty" CC: freebsd-arch@freebsd.org,sjg@juniper.net From: Eric McCorkle Message-ID: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 13:43:51 -0000 Keeping it short, I've got a bunch of plans in this area=2E I was actually = planning to finish off a paper and put it up for discussion this weekend=2E= I'll talk more about it elsewhere=2E=20 On October 20, 2017 1:05:51 AM EDT, "Simon J=2E Gerraty" wrote: >Eric McCorkle wrote: >> > I've implemented verification in the freebsd loader, along the >lines >> > previously mentioned, for us this pretty much closes the >secure-boot >> > gap - loader verifies kernel and its initial rootfs so init and >etc/rc=2E >> > Which then gets us to mac_veriexec=2E >>=20 >> Do I assume correctly that this is based on the NetBSD mac-based >> verification stuff? ie=2E Not the public-key crypto stuff I've talked >about? > >I didn't want to thread-jack=2E=2E=2E > >I've not looked at what's in NetBSD in this area for a decade at least, >but I ported the original veriexec from NetBSD to Junos about a dozen >years or so ago=2E More recently stevek re-implemented it for FreeBSD >10's MAC framework - the diffs (most of them anyway) have been sitting >in phabricator for a year or so=2E=2E=2E > >The loader implementation shares no code with the above, but uses the >same verification model and leverages the same signed manifests=2E >Thus it retains all the flexibility of using X=2E509 certificate chains >to >verify the signatures on the manifests=2E > >This is very important for us, because it allows a 10 year old binary >to >verify the latest signatures - provided that the RootCA certs have not >changed=2E For Junos the loader knows two RootCA's one for RSA and one >for >ECDSA - that's all it needs=2E > >We can tollerate more limited signing methods for the loader itself, to >fit in to various secure BIOS/boot environments, but from there we want >all the flexibility we can get=2E > >--sjg --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-arch@freebsd.org Fri Oct 20 14:24:37 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75838E37037 for ; Fri, 20 Oct 2017 14:24:37 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 3125B7C9FC for ; Fri, 20 Oct 2017 14:24:37 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-qt0-x22c.google.com with SMTP id p1so18650449qtg.2 for ; Fri, 20 Oct 2017 07:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CG1WSM6MNDJGOJxugw6ZxTfXFopfFW1i7LerckdbivI=; b=vc7CWgq9tnCiBmnmV30kBdbLZlKUVn54aAv32hK6ozzIyg8nWZZgD6aQ6wgC0rc47m 8Gk8cm1A35iqSXcKbg9jN5onI+OM1WWB0hWMbo+lYrurQD8F9SM40bHu3dQtbjphaHV2 wrlcJbCuY3kYg65lU0bkojHPHuhWAViFy2aQwx3ydCVl8wpIahdQCe3zxr9Z+5YwroL/ B+zfGrX9edhBP861GzyMTr1TIF1+uOnqDRPi+cQWbN8Ishe5mZ4hZCe0lu1kajfjsAIp bSE3f89VSU6PrgdZgB1tH/XqlUUY+QR03qbU1evrCVxK1b1HoKJI6/tKaEV68FFl1TJ8 Y89g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CG1WSM6MNDJGOJxugw6ZxTfXFopfFW1i7LerckdbivI=; b=LsWxq71rgc2Fzg+uLlKfRLLxV/JcN+cjQMQNMAOPkO5yTr1w7bMkHkzRQk/9U8z0vy R6dWREnJn0bFircTFLEV7XHg5pTINSvF/fyUItrbuwUtNba+9IS4yhjdEHSEbC/eWksq MuPlgoDudRG6zq5MV5hAjWrq6qAq2U4wkEe1D7COezz4meZzbUXzzlTiqrJHUaXcdUEr PRIF4L4aXPaIC+Ppq5VTyhEvvJ6AJ9yi42oD7VdmwoEARA0gKmXVS94ovY/lSCAPxFQi qO4ci0fyAZvzfptelkeNPAZTyeu6gYWLpKfr99P2CxxtujbUBy8WBiWA6h6pWxAYbZjm BZYA== X-Gm-Message-State: AMCzsaU/PIFoiLtIMUdarOvW3TT0E4KnRwXekzcMkV/OKlOCs9quVj/p lrkQqRQP+StHgJMzK5QBRLUdksJr9HFxqMK/5ME= X-Google-Smtp-Source: ABhQp+R2QRhEVqRgsa6V99mz64PB7+t48v9xfXJUI7KcUj3inDUBMypD1zT1VO+uOaE9cpZziJywlX2cSuFv8zC9ETg= X-Received: by 10.200.38.122 with SMTP id v55mr7384046qtv.134.1508509476377; Fri, 20 Oct 2017 07:24:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.53.186 with HTTP; Fri, 20 Oct 2017 07:24:35 -0700 (PDT) In-Reply-To: References: From: Ryan Stone Date: Fri, 20 Oct 2017 10:24:35 -0400 Message-ID: Subject: Re: PEBS support in hwpmc To: Bret Ketchum Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 14:24:37 -0000 On Fri, Oct 20, 2017 at 7:27 AM, Bret Ketchum wrote: > Without this support (or a VTune subscription) understanding > Front-End/Back-End bound applications running on Skylake/Kaby Lake > processors will be difficult at best I'm afraid that I don't know of any work related to PEBS in hwpmc. However, I'm curious as to why PEBS is so important on these architectures. My experience with hwpmc profiling has been that callchain information is frequently critical for understanding the performance characteristics and my understanding is that PEBS by design cannot capture that information. From owner-freebsd-arch@freebsd.org Fri Oct 20 14:40:24 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A087E375D3 for ; Fri, 20 Oct 2017 14:40:24 +0000 (UTC) (envelope-from bz@zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 015157D25F; Fri, 20 Oct 2017 14:40:24 +0000 (UTC) (envelope-from bz@zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 43F9C25D389C; Fri, 20 Oct 2017 14:40:21 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 8515AD1F84C; Fri, 20 Oct 2017 14:40:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id a5FrCPKdUUZN; Fri, 20 Oct 2017 14:40:19 +0000 (UTC) Received: from [10.248.117.2] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0CE38D1F827; Fri, 20 Oct 2017 14:40:18 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Ryan Stone" Cc: "Bret Ketchum" , "Ruslan Bukin" , "freebsd-arch@freebsd.org" Subject: Re: PEBS support in hwpmc Date: Fri, 20 Oct 2017 14:40:21 +0000 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (2.0BETAr6093) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 14:40:24 -0000 On 20 Oct 2017, at 14:24, Ryan Stone wrote: > On Fri, Oct 20, 2017 at 7:27 AM, Bret Ketchum > wrote: >> Without this support (or a VTune subscription) understanding >> Front-End/Back-End bound applications running on Skylake/Kaby Lake >> processors will be difficult at best > > I'm afraid that I don't know of any work related to PEBS in hwpmc. > However, I'm curious as to why PEBS is so important on these > architectures. My experience with hwpmc profiling has been that > callchain information is frequently critical for understanding the > performance characteristics and my understanding is that PEBS by > design cannot capture that information. Ruslan is working on Intel PT to my best knowledge. Cc:ing him so he can chime in. /bz From owner-freebsd-arch@freebsd.org Fri Oct 20 15:56:29 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36475E39817 for ; Fri, 20 Oct 2017 15:56:29 +0000 (UTC) (envelope-from rb743@hermes.cam.ac.uk) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (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 0027080AA6 for ; Fri, 20 Oct 2017 15:56:28 +0000 (UTC) (envelope-from rb743@hermes.cam.ac.uk) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from sc1.bsdpad.com ([163.172.212.18]:11195) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (LOGIN:rb743) (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1e5Zes-000BAe-7o (Exim 4.89) (return-path ); Fri, 20 Oct 2017 16:56:26 +0100 Date: Fri, 20 Oct 2017 16:50:04 +0100 From: Ruslan Bukin To: Bret Ketchum Cc: freebsd-arch@freebsd.org Subject: Re: PEBS support in hwpmc Message-ID: <20171020155004.GA54718@bsdpad.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Sender: "R. Bukin" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 15:56:29 -0000 I have not seen that yet. We are working on Intel PT support currently. But we plan to look at ARM v8.2 Statistical Profiling Extension technology too, which sounds similar to PEBS by Intel ? Ruslan On Fri, Oct 20, 2017 at 06:27:55AM -0500, Bret Ketchum wrote: > All, > > I apologize if there is a better forum for this question. Is there > any current effort to support Processor Event Based Sampling in hwpmc? > Without this support (or a VTune subscription) understanding > Front-End/Back-End bound applications running on Skylake/Kaby Lake > processors will be difficult at best. I'm thinking to simply add a > flag and either add a char to iap_event_descr or increase the size of > iap_evcode to house the sub-event (EVTSEL). Decoding and reporting the > captured PEBS records would need a bit more thought. > > Bret > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Fri Oct 20 16:31:19 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81A12E3A324 for ; Fri, 20 Oct 2017 16:31:19 +0000 (UTC) (envelope-from bcketchum@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 4A22881C0F for ; Fri, 20 Oct 2017 16:31:19 +0000 (UTC) (envelope-from bcketchum@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id 72so14616087itl.5 for ; Fri, 20 Oct 2017 09:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wzpJEVlZTIQyXTP+NqJt707NagrkFX12/3KKSH66Mag=; b=e/GUuD2FXdXKxqhWaiVCRaBbLdWMBaNKj6ZRhCcuC1NwjsXgLMvQkmpGNBZgJXvchL MOSONRwSQsMLUzDu0O/e2ZbqZUG7lNEZM1+nC6kalU1rjLMl4mX3Q6lbvK8sHUkUe2dZ WboQ91qo7XNz+4Oez8+ib7EuM8aTqdfDH57XfO9Tev+Mbs/GiEqeeJf/2GXJ04Ad16Yn CQUDU3RmYSRIL9SuIWNPfUk6jxIxHMIDPuJFi4i2Z4qTPKkue27sxJG+GmUXwCv//ZV2 1YNjfLZOMHwJ5KvD0uN5rlVWt16+sBElig6a+VnZ5M5UxgsmwAa+4PhQ5kYHaJAT2Bvy 6faw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=wzpJEVlZTIQyXTP+NqJt707NagrkFX12/3KKSH66Mag=; b=C/FQi4bB7ODgcLmr+DtBAqSMvb7DTv55BVA7HaNTIx72GWBvhdP3rLEoYkj+ryoRKG NN8+P0zp1qroZareXMdJDapeR0X5aEAIwE2en+GboHqDSbzuuCmMYoy4APPltdWUxqsr gFoTg3+kZFI1hn/KkjVI+9xP/Pb116SWOGsF4lWbOmWh2Z1O1kPgNyxGw/JoLAw//3Ei bhRi3AkYCKR5jM3PUfcRC94dDKQUsfY6QYIsp1BAR7rDC3nnHb6bZ3W2OO9seCP6Ipkm ELZuK3BGKV+mlPZWRJWDPCFbgseyI692UOUUD4uNDG1HBE1PE+NHzFaudKIR4Cb0O8F7 FbmQ== X-Gm-Message-State: AMCzsaVdhGZ54G79SCq8/mRDCHdXOh3O0sMocHzy/QJqG6174M0+PK3f zLMWp5LmJ/qfBaCOPGmvO6iqXpqArYgMVFqjzFKrHw== X-Google-Smtp-Source: ABhQp+S+oyyD9PmIOQaK6ioKJ1ctWGgvJvQe60Q8llElgL5z2bjhJisAwucGytYAKkEXpo2vvh7Ph5UDyjxxBwNWFIQ= X-Received: by 10.36.93.84 with SMTP id w81mr3429021ita.139.1508517077531; Fri, 20 Oct 2017 09:31:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.1.151 with HTTP; Fri, 20 Oct 2017 09:31:16 -0700 (PDT) In-Reply-To: References: From: Bret Ketchum Date: Fri, 20 Oct 2017 11:31:16 -0500 Message-ID: Subject: Re: PEBS support in hwpmc To: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:31:19 -0000 PEBS records do capture callchain-like infromation. I'm most interested (currently) with FRONTEND_RETIRED, MEM_LOAD_RETIRED and MEM_LOAD_L3_HIT_RETIRED. Which require understanding of sub-events. These counters can be used to differentiate the myriad of Front-End/Back-End bound issues before drilling down to offending code fragments. On Fri, Oct 20, 2017 at 9:24 AM, Ryan Stone wrote: > On Fri, Oct 20, 2017 at 7:27 AM, Bret Ketchum wrote: >> Without this support (or a VTune subscription) understanding >> Front-End/Back-End bound applications running on Skylake/Kaby Lake >> processors will be difficult at best > > I'm afraid that I don't know of any work related to PEBS in hwpmc. > However, I'm curious as to why PEBS is so important on these > architectures. My experience with hwpmc profiling has been that > callchain information is frequently critical for understanding the > performance characteristics and my understanding is that PEBS by > design cannot capture that information. From owner-freebsd-arch@freebsd.org Fri Oct 20 16:36:27 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80959E3A4F1 for ; Fri, 20 Oct 2017 16:36:27 +0000 (UTC) (envelope-from bcketchum@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 49CA482062 for ; Fri, 20 Oct 2017 16:36:27 +0000 (UTC) (envelope-from bcketchum@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id l196so14065088itl.4 for ; Fri, 20 Oct 2017 09:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=dsHTGJB6rY5LqYGld/1lJ+Q43tNO02Fql8m/I845jtk=; b=tK5ygjgugR56luDy6yn3dgXMZsgURfI/8/pMrLFXJyjypI0OxZkQcK2K6dUtKgkI3R 08CER0F04YP9G8bha4w32t8eUr40pEKMC48fOljP2OLk95BGl4z/2yq+AZqYf0uumonz rvtG8KVZegu9sd+JbFpo7HcbxLrP0025eXin+aihtQBAVvoHDkrTJvKcfx8jv3JV1esI afwzzoZQhaRm0iMH+fbrKxpGdskj+XesFRn7oDOjTv3mYHK0F5k9rwdDwpt0MR3gnv6i admPH7vBJ+Wop991LEx264P9F/EUWrBeEfOlRdqKQvPE6jG3BCjo/b1GXx5h9Ah0G41j vwUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=dsHTGJB6rY5LqYGld/1lJ+Q43tNO02Fql8m/I845jtk=; b=OPR7z4HgwcD0cM8oYdI5LaB0LfDXZpXjjuU/0Z3ALXXx/RYrtVvd3buHDwlluosqi+ Wilfaic75cjA6/1ubG0d2MPw3UVZSUoJkjpWxhgHHt9N3cI6jr3eE60/z+Wb2eEYKe07 Dem5i+oEQOlXO7+2TNfNg6QrTykKGBCckljiXck/nPKXcZA04g1rwlTfElqhR0JnLEiP RxMLUVwI2f9b754bOy1ZO1wkf+pKcrE4noSONaZwR+NY4wkYZRfyyoEb4nZh9TFLwPr6 ciTF/tAPNC3gQErD5pwEgHZUnJ3+fi5DLCwmySVrJplRfzpmF4u09PSzlIaokjZMNtkT vvtw== X-Gm-Message-State: AMCzsaVd2K+eiWWJw2PHRqTHLNVId4t2wXsVMfXxRULAaQ+IKQAe9Mhb vIl9Fs0UUCfk7mSgr3OedIgQ/mfMOBhj3Iqipng= X-Google-Smtp-Source: ABhQp+RXtP3FXp1mFRp90mNFFUJgvuV5fcvIdOT9kwBc8LAP76e1gXuzrEfv2f7AKWN/FlQy/MVBykuY9FKcO1nJxUc= X-Received: by 10.36.170.65 with SMTP id y1mr3693381iti.13.1508517386564; Fri, 20 Oct 2017 09:36:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.1.151 with HTTP; Fri, 20 Oct 2017 09:36:26 -0700 (PDT) In-Reply-To: <20171020155004.GA54718@bsdpad.com> References: <20171020155004.GA54718@bsdpad.com> From: Bret Ketchum Date: Fri, 20 Oct 2017 11:36:26 -0500 Message-ID: Subject: Re: PEBS support in hwpmc To: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:36:27 -0000 Looks like PT would assist in instruction execution performance analysis. PEBS provide information related to uops flows in the OOO pipeline including cache operations, prefetch, etc. On Fri, Oct 20, 2017 at 10:50 AM, Ruslan Bukin wrote: > I have not seen that yet. We are working on Intel PT support currently. > But we plan to look at ARM v8.2 Statistical Profiling Extension technology too, which sounds similar to PEBS by Intel ? > > Ruslan > > On Fri, Oct 20, 2017 at 06:27:55AM -0500, Bret Ketchum wrote: >> All, >> >> I apologize if there is a better forum for this question. Is there >> any current effort to support Processor Event Based Sampling in hwpmc? >> Without this support (or a VTune subscription) understanding >> Front-End/Back-End bound applications running on Skylake/Kaby Lake >> processors will be difficult at best. I'm thinking to simply add a >> flag and either add a char to iap_event_descr or increase the size of >> iap_evcode to house the sub-event (EVTSEL). Decoding and reporting the >> captured PEBS records would need a bit more thought. >> >> Bret >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Sat Oct 21 04:38:33 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5357E4CC58 for ; Sat, 21 Oct 2017 04:38:33 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97F8372CF8 for ; Sat, 21 Oct 2017 04:38:33 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v9L4cPP1002695 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 20 Oct 2017 21:38:26 -0700 Subject: Re: Making C++11 a hard requirement for FreeBSD To: freebsd-arch@freebsd.org References: <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> <1723616.qgAo6xlX2y@ralph.baldwin.cx> From: Nathan Whitehorn Message-ID: <5d2efe50-62c4-d1af-db45-123d813f7acb@freebsd.org> Date: Fri, 20 Oct 2017 21:38:25 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1723616.qgAo6xlX2y@ralph.baldwin.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVZFn7H2VBA4iGYWrymYJf/3qX/9ygm+y0MaKvVo4Cmul09UwC38l9Iwrmg3PGITWO/Ds+O0HYpR01iLGgbDC3yG8TEYNWqD3rY= X-Sonic-ID: C;EHyArRm25xGnDolQ3iMJ6w== M;/N3IrRm25xGnDolQ3iMJ6w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 04:38:33 -0000 On 10/10/17 06:49, John Baldwin wrote: [...] >>> Let's focus on #1, the largest if not the only major problem. If I build, >>> say, a ppc64 system with an external toolchain right now, it boots and runs >>> fine. But the system is completely unusable since: >>> - There are no binary packages built for PPC64, because of project policy >>> preventing the use of native build systems >>> >>> >>> System is still usable w/o packages. People can still fire up custom >>> poudrier repos. We could also change project policy. This is is a specific >>> wrinkle for powerpc64 it seems. >> How would I do that? We can't run these natively, because the system >> ships without a compiler. And we can't cross-compile, because the ports >> tree does not support that. > The base/ ports _do_ cross-compile. See /usr/ports/base/README. You have to > build a world image using the external toolchain that can then be used as a > --sysroot with the external toolchain to build binutils and gcc packages. > These packages should then be able to be installed. To be clear, you would > build a world on an amd64 host with the foo-xtoolchain-gcc toolchain, install > it to some 'rootfs' directory, then build the base/ packages on the same > amd64 host but the generated packages can be installed on the target via > pkg install. In particular, we could automate building of the base/ packages > in the cluster and publish repositories that contain just binutils and gcc. > Has anyone managed to have this work recently? GCC seems to play quite poorly with our libc++ and I haven't managed to get base/gcc to build at all despite trying for a few days. I did get base/binutils and pkg to cross-compile after some tweaks, but base/gcc just won't go. -Nathan