Re: "Boot this kernel once" functionality? (amd64)
On Sep 24, 9:14am, Reinoud Zandijk wrote: } Subject: Re: "Boot this kernel once" functionality? (amd64) } On Wed, Sep 16, 2020 at 12:09:43PM +0200, Martin Husemann wrote: } > On Wed, Sep 16, 2020 at 12:05:26PM +0200, Anthony Mallet wrote: } > > I was also wondering if it would be possible to pass arguments to the } > > primary or secondary bootloader via reboot(2) and the boothowto } > > flags. But this doesn't seem doable. Right? } > } > This works fine on e.g. sparc*; I can do: shutdown -b netbsd.t -r now } > } > and it will pass "netbsd.t" as boot argument to the firmware, which passes } > it on to the bootloader and then it boots /netbsd.t once. } } In shutdown(8) I read that the arguments are passed to reboot(8) and that is } mentioned in kloader(4) so I guess its using that mechanism. } } As for amd64, it would be great if I could boot a kernel once. It could } simplify testing out a new kernel. Not that a few lines of boot.cfg can't do } that but still. } } > I don't know if there is enough of a persistent environment for UEFI boots } > (I would guess there is), and probably no easy way for BIOS boot. } } I could imagine some BIOS/UEFI wiping all DRAM on reboot for security reasons. UEFI has the concept of persistent variable storage (key/value store). See Section 8.2 "Variable Services" of the UEFI spec. }-- End of excerpt from Reinoud Zandijk
re: "Boot this kernel once" functionality? (amd64)
Reinoud Zandijk writes: > On Wed, Sep 16, 2020 at 12:09:43PM +0200, Martin Husemann wrote: > > On Wed, Sep 16, 2020 at 12:05:26PM +0200, Anthony Mallet wrote: > > > I was also wondering if it would be possible to pass arguments to the > > > primary or secondary bootloader via reboot(2) and the boothowto > > > flags. But this doesn't seem doable. Right? > > > > This works fine on e.g. sparc*; I can do: shutdown -b netbsd.t -r now > > > > and it will pass "netbsd.t" as boot argument to the firmware, which passes > > it on to the bootloader and then it boots /netbsd.t once. > > In shutdown(8) I read that the arguments are passed to reboot(8) and that is > mentioned in kloader(4) so I guess its using that mechanism. this does not use kloader(4), which appeared in netbsd 1.6. the "pass boot args to loader" appeared in netbsd 1.3, and it is implemented on sparc* by asking the firmware to reboot with these arguments instead of the default. it very much relies upon this firmware feature. .mrg.
Re: Logging a kernel message when blocking on entropy
nia wrote: > Unless you buy one of the snake oil devices Mr. Gustafsson sells, of > course. The devices you call "snake oil" and me pushing for NetBSD to stop generating predictable keys are both aspects of me working to address entropy related vulnerabilities ever since recognizing them as a major weak link in Internet security while working on BIND 9 some 20 years ago. But of course I have no way of proving my sincere intent to you, just like you have no way of proving to me that you are not paid by the NSA to undermine the security of NetBSD. So please, let's stop with the ad hominem attacks and focus on the technical issues. -- Andreas Gustafsson, g...@gson.org
Re: "Boot this kernel once" functionality? (amd64)
On Wed, Sep 16, 2020 at 12:09:43PM +0200, Martin Husemann wrote: > On Wed, Sep 16, 2020 at 12:05:26PM +0200, Anthony Mallet wrote: > > I was also wondering if it would be possible to pass arguments to the > > primary or secondary bootloader via reboot(2) and the boothowto > > flags. But this doesn't seem doable. Right? > > This works fine on e.g. sparc*; I can do: shutdown -b netbsd.t -r now > > and it will pass "netbsd.t" as boot argument to the firmware, which passes > it on to the bootloader and then it boots /netbsd.t once. In shutdown(8) I read that the arguments are passed to reboot(8) and that is mentioned in kloader(4) so I guess its using that mechanism. As for amd64, it would be great if I could boot a kernel once. It could simplify testing out a new kernel. Not that a few lines of boot.cfg can't do that but still. > I don't know if there is enough of a persistent environment for UEFI boots > (I would guess there is), and probably no easy way for BIOS boot. I could imagine some BIOS/UEFI wiping all DRAM on reboot for security reasons. Reinoud
Re: Logging a kernel message when blocking on entropy
nia wrote: > On Tue, Sep 22, 2020 at 02:32:23PM +0200, Manuel Bouyer wrote: > > OK, so the printf should never happen when the system has been properly > > configured. In this case I have no objection. > > No, it will happen frequently in VMs and on non-recent-x86 hardware. The cases of processes blocking on randomness we tend to see reports about are pkgsrc builds and web browsers. Since entropy does not run out in -current as already discussed on this list, each hanging pkgsrc build or web browser will cause the message to be logged exactly once. How often do they hang for you? If PR 55659 is fixed, there will be more cases where the message is logged (at least ssh-keyegn), but still only one per blocking process. -- Andreas Gustafsson, g...@gson.org
Re: Logging a kernel message when blocking on entropy
mar...@duskware.de (Martin Husemann) writes: >On all of these it *still* is a setup error that needs to be avoided. Every VM is installed manually by someone rolling dice so that such setup errors cannot occur. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Logging a kernel message when blocking on entropy
On Thu, Sep 24, 2020 at 06:37:43AM +, nia wrote: > On Tue, Sep 22, 2020 at 02:32:23PM +0200, Manuel Bouyer wrote: > > OK, so the printf should never happen when the system has been properly > > configured. In this case I have no objection. > > No, it will happen frequently in VMs and on non-recent-x86 hardware. On all of these it *still* is a setup error that needs to be avoided. You are talking about a different "frequently". Many modern aarch64 SoCs will be affected, all VMs with no viornd(4) support, as well as most non x86 machines w/o special hardware (like ualea(4)). When these machines are properly setup *once* (ideally at install time), it will not happen to them ever again (that is the "frequently" Manuel was talking about). The problem is with USB images and VM clones that are not installed at all and we have no good idea (besides properly documenting and suggesting manual actions) so far. Martin
Re: Logging a kernel message when blocking on entropy
On Thu, Sep 24, 2020 at 06:37:43AM +, nia wrote: > On Tue, Sep 22, 2020 at 02:32:23PM +0200, Manuel Bouyer wrote: > > OK, so the printf should never happen when the system has been properly > > configured. In this case I have no objection. > > No, it will happen frequently in VMs and on non-recent-x86 hardware. Unless you buy one of the snake oil devices Mr. Gustafsson sells, of course.
Re: Logging a kernel message when blocking on entropy
On Tue, Sep 22, 2020 at 02:32:23PM +0200, Manuel Bouyer wrote: > OK, so the printf should never happen when the system has been properly > configured. In this case I have no objection. No, it will happen frequently in VMs and on non-recent-x86 hardware.
