From owner-freebsd-current@freebsd.org Mon Mar 30 03:32:27 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0B42D2708A1 for ; Mon, 30 Mar 2020 03:32:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48rJ192ygXz4HF3 for ; Mon, 30 Mar 2020 03:32:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-pf1-x441.google.com with SMTP id c21so7279622pfo.5 for ; Sun, 29 Mar 2020 20:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2l7W7i/vTBhL79lr858DvljgbjpM/ZzOAEQRpVN0xcQ=; b=sRrT3Vy2MMH//drdkyJKXSjQNbDmMdDyGYHwMvV5mGnx3qLj01b4xK1FngP8+mTxPW xfRxRhTaVXrAMhcBT50PDRyLhg9fNiIhnh5vncFOrwizxlM867yH1ds/Lq5oMB5RI2kv MmG8NgyHlab9tcrwtmS7E8yx1IK9bfPwfmMo8WjPAQOLn1TXJW629cFSc93ZVo0x2dHL Btt25QPH2/wx7boIuFqDMpEXrwvgamSQZuwiJRus1S1xPrFWoafV2Atgm2eU6WTPbKIR JlL6PbW5vAVTtXOk5TSJkfSWTTOLM9jQvLsDpAMyQwZyoIqFah6KaelV/RF5g7dwNwbn Q+Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2l7W7i/vTBhL79lr858DvljgbjpM/ZzOAEQRpVN0xcQ=; b=ZsNTpbu+HHiR2kaimmyovl7akIX/DhJNkQqcAP0B1lrJmaMALNQxYY4vZuJ1zMCIU5 IBXfVpPThuPNsd20fG4yA9SgiBurpoKZxjd9wi0vydVFPpDatuCkCmazI7yLow+vw8PH Z5vgLMF4+3QdUx4oKzdcGZJN0DAJzGQO0EW59W6F4EyKWF7bwpF+U9jYEbVutHq1qPhU YOrViwOkEYRW79Y+maWVDhZgUg9rXwZOrmePCE1Dz8KwK/EIvmjNGdGJpIs9wnNr2S/J ieUrI49HojzuyStfPTxoNxy/pEMeziSetstRSxoxB9UnmLALl5wqs44TY88Lq9fq1G9X KljQ== X-Gm-Message-State: ANhLgQ0NraSTRiFRmLos68QomiExXgP3yVOIOkk7dTvaZPyJGNHMgz/b Fs7iEPMmmVLETPzIk75sxrstqI9jgiSeuxxRcmX8Kb4Y X-Google-Smtp-Source: ADFU+vuUcOMx8CUrE11pQeOf3nY/W72n9CD4+Zz9w9sMt/9HRD4LKsZ7y7ZXJ0LLuf71GyEDGkHsJSQxtLobIxUeFn4= X-Received: by 2002:a0c:a8e2:: with SMTP id h34mr9607399qvc.22.1585538678448; Sun, 29 Mar 2020 20:24:38 -0700 (PDT) MIME-Version: 1.0 References: <318FDBAF-448F-4C55-A9A8-69D71A73E43B@me.com> <344e85545cfc47c9835fc5918e5b1dc1@udns.ultimatedns.net> <20200329211137.012a8fd62b58525b027bcfb6@dec.sakura.ne.jp> <40bacb99-d463-cbad-3ccf-b3ddd6856d10@bsdio.com> <675a41c7-46c1-f548-b285-e5ede55db76a@freebsd.org> <16728.1585537356@kaos.jnpr.net> <18df34fe-6256-6e68-ead5-481e83a501fe@freebsd.org> In-Reply-To: <18df34fe-6256-6e68-ead5-481e83a501fe@freebsd.org> From: Warner Losh Date: Sun, 29 Mar 2020 21:24:27 -0600 Message-ID: Subject: Re: When will the FreeBSD (u)EFI work? To: Nathan Whitehorn Cc: "Simon J. Gerraty" , Kyle Evans , Rebecca Cran , Tomoaki AOKI , FreeBSD Current , Chris H X-Rspamd-Queue-Id: 48rJ192ygXz4HF3 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=sRrT3Vy2; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::441) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-0.11 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.955,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; IP_SCORE(-0.18)[ip: (-0.02), ipnet: 2607:f8b0::/32(-0.36), asn: 15169(-0.46), country: US(-0.05)]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; NEURAL_HAM_LONG(-0.98)[-0.980,0]; MAILSPIKE_FAIL(0.00)[1.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.rep.mailspike.net:query timed out]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[1.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 03:32:27 -0000 On Sun, Mar 29, 2020 at 9:14 PM Nathan Whitehorn wrote: > > > On 2020-03-29 20:02, Simon J. Gerraty wrote: > > Nathan Whitehorn wrote: > >> It's basically this that has been the problem: we need a way to manage > >> updates of the EFI loader in this situation, which we don't currently > >> have. The ESP needs to be mounted at a standard point, > >> installworld/freebsd-update/etc. need to know to replace files there, we > >> need to fall back cleanly on older systems, etc. The original (failed -- > > Actually if you are doing secure boot, the *last* thing you want is to > > update /efi/boot with an unsigned update. > > > > So I would think it should be done as a unique operation - do you don't > > do it accidentally. > > > > At least that's how I'm handling it for embedded devices. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > > The problem then is that we have treated loader as a > continuously-updatable part of the OS, like the kernel, and the update > system and development process assumes they get updated in sync. > It's thorny issues like this which have led me to believe we need to have an install-loader target and separate it out just like we separate out world from kernel because the loader has become more like a kernel and it may need to be updated asynchronously to all other parts of the system. However, this also breaks all the instructions in the world, and often times will make things worse, not better. Things like etcupdate shouldn't be used to paper over this problem, though: it needs to be solved systematically. Ideally, we'd impose a one true location for the ESP, have a make variable to override that one true location, and have a WITHOUT_LOADER_INSTALL or somesuch flag if we don't go the install-loader router. This would make it safe to do automatically because the unsafe installations can just turn it off. Warner