ruben at mrbrklyn.com
Thu Sep 23 05:56:43 EDT 2021
On Wed, Sep 22, 2021 at 06:07:49PM +0200, Greg KH wrote:
> On Wed, Sep 22, 2021 at 11:47:42AM -0400, Ruben Safir wrote:
> > On Wed, Sep 22, 2021 at 08:35:15AM +0200, Greg KH wrote:
> > > On Wed, Sep 22, 2021 at 02:22:22AM -0400, Ruben Safir wrote:
> > > > What is this for?
> > > >
> > > > efivarfs on /sys/firmware/efi/efivars type efivarfs
> > > >
> > > > why would the OS need to know anything about the UEFI
> > > > boot loader once it is up and running?
> > >
> > > Because there are lots of needed system information that the OS, and
> > > userspace, needs to get from UEFI after the system has booted.
> > Such as what? It is not needed when booting with LILO?
> Do you really still use LILO?
> > Once the OS is up and running, what possible reason does the OS need
> > anything about the booting enviroonment?
> It needs to get up and running. And even then, while running, it still
> needs to get some information from UEFI. Fun things like device
> information, system information, and other things.
> Look at what `dmidecode` gives you, that's one example.
> > > Why do you think it does not need to be present? What problems is
> > > having it there causing?
> > >
> > Aside from the obvious security issues? It is a huge problem for
> > installation from BIOS environments and it is an unneeded lock in.
> What "lock in"? Your system relies on the bootloader to interact with
> the system both to boot, and for some system interactions while running.
> That's just how ACPI/UEFI works.
> If you don't like this, wonderful, use a system based on a different
> type of bootloader. But in the end, they end up all having to do the
> same thing somehow :)
> > All I want the boot loader to do is fine the kernel and run it.
> Your bootloader also has to do a lot more things (initialize hardware,
> provide information to the OS as to what hardware is present, do
> system-level things like suspend/resume, etc.)
Why does it need the bootloader to do any of that. It just needs to
bring up enough hardware to find the kernel and read it... STDIO, STDOUT
and the hard drive, assuming it is not a network boot. The hardware's
firmware has to initialize so minimal subset of hardware, but that has
nothing to do specifically with UEFI.
Since when does the OS not control all the hardware on the system?
What you seem to be saying is that the UEFI shell is running
simutanously to the OS, and controls hardware. That is all news to me.
It doesn't happen in BIOS mode or systems that are still BIOS, dieing
breed that that is.
> > I can't think of anything that a bootload does that should be needed for
> > a running OS whatsoever. What are EFI variables that are being stored
> > and manipulated?
> Look at them and see, it's all there for you to read. The whole UEFI
> spec is also public as well as a working implementation of the code that
> is used for your system.
> greg k-h
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
More information about the Kernelnewbies