efivars

efivars

[Ruben Safir]

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?


-- 
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
http://www.mrbrklyn.com 

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!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Greg KH]

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.

Why do you think it does not need to be present?  What problems is
having it there causing?

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

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?

Once the OS is up and running, what possible reason does the OS need
anything about the booting enviroonment?

> 
> 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.

All I want the boot loader to do is fine the kernel and run it.

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?

I did a search for this answer, but you just get useless parroted
empty answers.

> thanks,
> 
> greg k-h
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-- 
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
http://www.mrbrklyn.com 

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!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Greg KH]

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.)

> 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.

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

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?

whenever possible


> 
> > 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.
>

The OS has direct access to the hardware.  It can read it and identify
it.

> Look at what `dmidecode` gives you, that's one example.

Thanks, I will look

What is all this garbage?

~$ sudo ls /sys/firmware/efi/efivars/ |wc
    211     211   11511


> > 
> > 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 that should be it.  

>and for some system interactions while running.
> That's just how ACPI/UEFI works.

And if you are running out of a BIOS system, the system won't boot and
work?  Of course it will.

How about non-x86 platforms that don't have UEFI?

> 
> 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 :)

Don't like it, that is for sure.  What it is doing is another problem.

If you are booted from an thumbdrive using BIOS, and installing a UEFI system, it
shouldn't need a bunch of UEFI firmware data to do the installation for
a UEFI installation.  The kernel OS should be independent once it is up
and running and building a UEFI boot chain shouldn't depend on being
already loaded UEFI environment.  

Why would the OS need to know what booted it?  Hence the question, what
does efivars provides that is needed for the OS to run... not BOOT but
run.

> 
> > 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 that?  The OS has access directly to all the hardware
and can read it and load any needed modules.


> > 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 

I've read it.  Refresh my memory.  Where does it say that the bootloader
actively speaks to the running OS after the OS is up and running?  Once
it hands off to GRUB or any other boot loader, and the OS is up and
running, why does the OS care what launched it?

I've been told that the OS needs to reload firmware to reboot atached
devices like network cards.  These devices phsycially are plugged into the system
Once they are IDed, the OS should be able to control them completely.

>as well as a working implementation of the code that
> is used for your system.

That has been called Kernel Modules.  Are we talking about binary firmware blobs 
that are not part of the kernel?

Thanks for the reply!

Reuvain

-- 
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
http://www.mrbrklyn.com 

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!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

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.
> 
> thanks,
> 
> greg k-h
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-- 
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
http://www.mrbrklyn.com 

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!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Greg KH]

On Thu, Sep 23, 2021 at 05:56:43AM -0400, Ruben Safir wrote:
> On Wed, Sep 22, 2021 at 06:07:49PM +0200, Greg KH wrote:
> > 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.

Define "minimal" please.  What about your RAM?  Your north/south bridge
and the i/o controllers there?  Your processor init sequence?  Find the
boot disk to start with?  How do you tell the bootloader _where_ the
boot disk is?

> Since when does the OS not control all the hardware on the system?

For x86 systems, since i486 days.  Again, remember APM?

> What you seem to be saying is that the UEFI shell is running
> simutanously to the OS, and controls hardware.

No, not at all, the "shell" is not running, but parts of it are running
and are called by the OS to do things.  Sometimes those things wake up
the OS and tell it to do things.

> That is all news to me.
> It doesn't happen in BIOS mode or systems that are still BIOS, dieing
> breed that that is.

Yes, it happened in much worse ways in the "old style BIOS" modes and
systems.  Now it is documented and unified and works much better than
ever before.

Yes, it is more "complex" than before, but you are using a much more
complex system than you used to have as well.

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[FMDF]

[-- Attachment #1.1: Type: text/plain, Size: 2672 bytes --]

On Thu, 23 Sep 2021, 11:57 Ruben Safir, <ruben@mrbrklyn.com> wrote:

>
> Why does it need the bootloader to do any of that.


You still don't want to listen: the OS does not need to use bootloaders to
do the things that Greg and I listed.

It needs UEFI runtime services; please don't be lazy and read Wikipedia
article whose I provided the link.

This is copy-pasted for your convenience:

"The Unified Extensible Firmware Interface (UEFI)[1]
<https://en.m.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#cite_note-1>
is
a publicly available specification
<https://en.m.wikipedia.org/wiki/Specification> that defines a software
interface <https://en.m.wikipedia.org/wiki/Interface_%28computer_science%29>
between
an operating system <https://en.m.wikipedia.org/wiki/Operating_system> and
platform firmware <https://en.m.wikipedia.org/wiki/Firmware>. UEFI replaces
the legacy Basic Input/Output System (BIOS
<https://en.m.wikipedia.org/wiki/BIOS>) firmware interface originally
present in all IBM PC-compatible
<https://en.m.wikipedia.org/wiki/IBM_PC_compatible> personal computers
<https://en.m.wikipedia.org/wiki/Personal_computer>,[2]
<https://en.m.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#cite_note-Intel2000-2>
[3]
<https://en.m.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#cite_note-ElReg1-3>
with
most UEFI firmware implementations providing support for legacy BIOS
services[]".

If you spend few minutes there, you'll find also information there about
the two different logical roles of UEFI:

"EFI defines two types of services: boot services and runtime services.
Boot services are available only while the firmware owns the platform
(i.e., before the ExitBootServices() call), and they include text and
graphical consoles on various devices, and bus, block and file services.
Runtime services are still accessible while the operating system is
running; they include services such as date, time and NVRAM
<https://en.m.wikipedia.org/wiki/Non-volatile_random-access_memory>
 access.".

Boot services are available only while the firmware owns the platform, so
please stop saying "Why does it need the bootloader to do any of that[?]"

I told you that Linux can be booted without bootloaders, but that it still
needs the UEFI runtime services. I also provided a link to the Kernel
official  documentation to prove it.

Anyway, it really looks like you don't care to listen and that your main
interest is standing by your own (unsubstantiated) positions.

Thanks,

Fabio


_________________

> > Kernelnewbies mailing list
> > Kernelnewbies@kernelnewbies.org
> > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

[-- Attachment #1.2: Type: text/html, Size: 10497 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

On 9/23/21 6:28 AM, FMDF wrote:
> but that it still needs the UEFI runtime services. I


No, it doesn't.  It can run a BIOS system or on hardware that has no
UEFI at all.

How do you think it has worked for the last 25 years.


-- 
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
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

On 9/23/21 6:28 AM, FMDF wrote:
> ut that it still needs the UEFI runtime services.


My webserver runs without efi - for example.

sudo ls -al /sys/firmware/efi/efivars
ls: cannot access /sys/firmware/efi/efivars: No such file or directory

-- 
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
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

FWIW
ttps://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf


On 9/23/21 6:28 AM, FMDF wrote:
> On Thu, 23 Sep 2021, 11:57 Ruben Safir, <ruben@mrbrklyn.com
> <mailto:ruben@mrbrklyn.com>> wrote:
> 
> 
>     Why does it need the bootloader to do any of that.  
> 
> 
> You still don't want to listen: the OS does not need to use bootloaders
> to do the things that Greg and I listed.
> 
> It needs UEFI runtime services; please don't be lazy and read Wikipedia
> article whose I provided the link. 
> 
> This is copy-pasted for your convenience:
> 
> "The Unified Extensible Firmware Interface (UEFI)[1]
> <https://en.m.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#cite_note-1> is
> a publicly available specification
> <https://en.m.wikipedia.org/wiki/Specification> that defines a
> software interface
> <https://en.m.wikipedia.org/wiki/Interface_%28computer_science%29> between
> an operating system
> <https://en.m.wikipedia.org/wiki/Operating_system> and
> platform firmware <https://en.m.wikipedia.org/wiki/Firmware>. UEFI
> replaces the legacy Basic Input/Output System (BIOS
> <https://en.m.wikipedia.org/wiki/BIOS>) firmware interface originally
> present in all IBM PC-compatible
> <https://en.m.wikipedia.org/wiki/IBM_PC_compatible> personal computers
> <https://en.m.wikipedia.org/wiki/Personal_computer>,[2]
> <https://en.m.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#cite_note-Intel2000-2>[3]
> <https://en.m.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#cite_note-ElReg1-3> with
> most UEFI firmware implementations providing support for legacy BIOS
> services[]".
> 
> If you spend few minutes there, you'll find also information there about
> the two different logical roles of UEFI:
> 
> "EFI defines two types of services: boot services and runtime
> services. Boot services are available only while the firmware owns the
> platform (i.e., before the ExitBootServices() call), and they include
> text and graphical consoles on various devices, and bus, block and file
> services. Runtime services are still accessible while the operating
> system is running; they include services such as date, time and NVRAM
> <https://en.m.wikipedia.org/wiki/Non-volatile_random-access_memory> access.".
> 
> Boot services are available only while the firmware owns the platform,
> so please stop saying "Why does it need the bootloader to do any of that[?]"
> 
> I told you that Linux can be booted without bootloaders, but that it
> still needs the UEFI runtime services. I also provided a link to the
> Kernel official  documentation to prove it.
> 
> Anyway, it really looks like you don't care to listen and that your main
> interest is standing by your own (unsubstantiated) positions.
> 
> Thanks,
> 
> Fabio
> 
> 
> _________________
> 
>     > Kernelnewbies mailing list
>     > Kernelnewbies@kernelnewbies.org
>     <mailto:Kernelnewbies@kernelnewbies.org>
>     > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>     <https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies>
> 


-- 
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
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

On 9/22/21 2:35 AM, Greg KH wrote:
> Because there are lots of needed system information that the OS, and
> userspace, needs to get from UEFI after the system has booted.

OS's shouldn't need anything from a boot loader.  That ties the OS to
the bootloader completely without need.

-- 
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
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Greg KH]

On Wed, Sep 22, 2021 at 11:58:55AM -0400, Ruben Safir wrote:
> On 9/22/21 2:35 AM, Greg KH wrote:
> > Because there are lots of needed system information that the OS, and
> > userspace, needs to get from UEFI after the system has booted.
> 
> OS's shouldn't need anything from a boot loader.  That ties the OS to
> the bootloader completely without need.

Good luck with that!

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 1307 bytes --]

On Wed, 22 Sep 2021 11:58:55 -0400, Ruben Safir said:
> OS's shouldn't need anything from a boot loader.  That ties the OS to
> the bootloader completely without need.

You might want to read Documentation/x86/boot.rst and think about what  the OS
is expecting to get passed from the boot loader, and then think about how you
would deal with the situation if that information wasn't passed along.

And oddly enough, your OS isn't tied to the boot loader.  In fact, any of the
following will work:

  Assigned boot loader ids (hexadecimal):

        == =======================================
        0  LILO
           (0x00 reserved for pre-2.00 bootloader)
        1  Loadlin
        2  bootsect-loader
           (0x20, all other values reserved)
        3  Syslinux
        4  Etherboot/gPXE/iPXE
        5  ELILO
        7  GRUB
        8  U-Boot
        9  Xen
        A  Gujin
        B  Qemu
        C  Arcturus Networks uCbootloader
        D  kexec-tools
        E  Extended (see ext_loader_type)
        F  Special (0xFF = undefined)
        10 Reserved
        11 Minimal Linux Bootloader
           <http://sebastian-plotz.blogspot.de>
        12 OVMF UEFI virtualization stack
        == =======================================

And that's just the *documented* ones. So, as you were saying?


[-- Attachment #1.2: Type: application/pgp-signature, Size: 494 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

On 9/22/21 1:04 PM, Valdis Klētnieks wrote:
> And that's just the *documented* ones. So, as you were saying?

Why does it depend on variables from EFI?

-- 
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
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

On 9/22/21 1:04 PM, Valdis Klētnieks wrote:
> You might want to read Documentation/x86/boot.rst and think about what  the OS
> is expecting to get passed from the boot loader, and then think about how you
> would deal with the situation if that information wasn't passed along.


Link?

FWIW, it doesn't need anything from the boot loader.  The installed OS
is capable of IDing hardware and running.

I've read through the entire documantation for UEFI, as boring as that
is never saw anyiong about passing info to the OS.

I did a sumation of this at one point:

http://www.nylxs.com/docs/grad_school/uefi/page1.html



-- 
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
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Dave Stevens]

On Wed, 22 Sep 2021 22:02:43 -0400
Ruben Safir <ruben@mrbrklyn.com> wrote:

> Being so tracked is for FARM ANIMALS and extermination camps,

on the way

-- 
Sometimes I wonder whether the world is being run by 
smart people who are putting us on or by imbeciles who 
really believe it.

Mark Twain

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Greg KH]

On Wed, Sep 22, 2021 at 10:02:43PM -0400, Ruben Safir wrote:
> On 9/22/21 1:04 PM, Valdis Klētnieks wrote:
> > You might want to read Documentation/x86/boot.rst and think about what  the OS
> > is expecting to get passed from the boot loader, and then think about how you
> > would deal with the situation if that information wasn't passed along.
> 
> 
> Link?
> 
> FWIW, it doesn't need anything from the boot loader.  The installed OS
> is capable of IDing hardware and running.

How does the OS determine something as "simple" as "where is the memory
in the system" without getting that information from the bootloader?

How does the hardware describe itself to the OS?

> I've read through the entire documantation for UEFI, as boring as that
> is never saw anyiong about passing info to the OS.

I think you missed some sections :)

> I did a sumation of this at one point:
> 
> http://www.nylxs.com/docs/grad_school/uefi/page1.html

Private page :(

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

On 9/22/21 1:04 PM, Valdis Klētnieks wrote:
> You might want to read Documentation/x86/boot.rst and think about what  the OS
> is expecting to get passed from the boot loader,


Aside from that, I really just want to know what efi varriables exist
and why we have a sys file for them, not a recommendationt of read pages
of documentation for the linux boot process, including details of the
memory map etc.



-- 
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
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Bjørn Mork]

Ruben Safir <ruben@mrbrklyn.com> writes:

> I really just want to know what efi varriables exist and why we have a
> sys file for them

The "why" question is answered here:
https://www.kernel.org/doc/Documentation/filesystems/efivarfs.rst

The "what" question doesn't have a short answer.  If you don't want the
long one, then that's fine.  You don't need to worry about efi
variables.  Leave them alone and they will do you no harm.


Bjørn

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

On Thu, Sep 23, 2021 at 09:32:00AM +0200, Bjørn Mork wrote:
> Ruben Safir <ruben@mrbrklyn.com> writes:
> 
> > I really just want to know what efi varriables exist and why we have a
> > sys file for them
> 
> The "why" question is answered here:
> https://www.kernel.org/doc/Documentation/filesystems/efivarfs.rst


Thanks

I read that, but for my purposes it is circular.

They created another virtual fielsystem because the current
/sys and /proc entries seemed to fail to do something consistently 
as UEFI developed and was grafted on the current kernel.

It doesn't explain why these new variables were needed in the 
first place.

Thanks

> 
> The "what" question doesn't have a short answer.  If you don't want the
> long one, then that's fine.  You don't need to worry about efi
> variables.  Leave them alone and they will do you no harm.

They are a problem and present a securilty risk.  I can't change
anything and nobody asks me about OS design, but it does cause 
real problems and I run into them repeatedly at installfests.


-- 
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
http://www.mrbrklyn.com 

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!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Greg KH]

On Thu, Sep 23, 2021 at 04:41:28AM -0400, Ruben Safir wrote:
> On Thu, Sep 23, 2021 at 09:32:00AM +0200, Bjørn Mork wrote:
> > Ruben Safir <ruben@mrbrklyn.com> writes:
> > 
> > > I really just want to know what efi varriables exist and why we have a
> > > sys file for them
> > 
> > The "why" question is answered here:
> > https://www.kernel.org/doc/Documentation/filesystems/efivarfs.rst
> 
> 
> Thanks
> 
> I read that, but for my purposes it is circular.
> 
> They created another virtual fielsystem because the current
> /sys and /proc entries seemed to fail to do something consistently 
> as UEFI developed and was grafted on the current kernel.

Creating new filesystems is trivial in the kernel, and these didn't fall
into the rules allowed by sysfs, so a new one was created.  Just because
it is a new filesystem does not mean anything here.

> It doesn't explain why these new variables were needed in the 
> first place.

They are exposed by UEFI for the OS and userspace to use for various
things.  The filenames should show you the functionality to look up in
the UEFI spec if you are curious about anything specific in there.

> > The "what" question doesn't have a short answer.  If you don't want the
> > long one, then that's fine.  You don't need to worry about efi
> > variables.  Leave them alone and they will do you no harm.
> 
> They are a problem and present a securilty risk.

What security risk specifically?

And what problem specifically?

> I can't change
> anything and nobody asks me about OS design, but it does cause 
> real problems and I run into them repeatedly at installfests.

What specifc problems do they cause with installing a distro?

Details please.

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 355 bytes --]

On Wed, 22 Sep 2021 22:07:28 -0400, Ruben Safir said:
> Aside from that, I really just want to know what efi varriables exist

On Thu, 23 Sep 2021 00:01:20 -0400, Ruben Safir said:
> What is all this garbage?
>
> ~$ sudo ls /sys/firmware/efi/efivars/ |wc
>     211     211   11511

Put the keyboard down, and back away slowly, before somebody gets hurt.


[-- Attachment #1.2: Type: application/pgp-signature, Size: 494 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

On Thu, Sep 23, 2021 at 04:12:51AM -0400, Valdis Klētnieks wrote:
> On Wed, 22 Sep 2021 22:07:28 -0400, Ruben Safir said:
> > Aside from that, I really just want to know what efi varriables exist
> 
> On Thu, 23 Sep 2021 00:01:20 -0400, Ruben Safir said:
> > What is all this garbage?
> >
> > ~$ sudo ls /sys/firmware/efi/efivars/ |wc
> >     211     211   11511
> 
> Put the keyboard down, and back away slowly, before somebody gets hurt.
> 

Don't be a jackass




> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


-- 
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
http://www.mrbrklyn.com 

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!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Bjørn Mork]

Ruben Safir <ruben@mrbrklyn.com> writes:

> OS's shouldn't need anything from a boot loader.

Why do you need a bootloader then?

I'd suggest playing with embedded devices for a while. Their boot chain
is usually much simpler than on PC hardware. There you can really get a
feeling of how easy and decoupled stuff could have been. Load a kernel
directly to some location in memory and just jump there.

Then try to expand a bit by reading the kernel from some specific flash
device, or even network.  Maybe trying to make the kernel do the right
thing depending on where it was booted from.  Or add a file system to
the flash.  Etc.  Maybe you even want some way to configure the
bootloader from the OS?

Add all the features you take for granted on PC hardware.

I think you will find that the OS has to be aware of some of the stuff
the bootloader does.  And that many of the features depend on the OS
communicating with the bootloader somehow.  Both ways.



Bjørn

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

On Thu, Sep 23, 2021 at 09:13:02AM +0200, Bjørn Mork wrote:
> Ruben Safir <ruben@mrbrklyn.com> writes:
> 
> > OS's shouldn't need anything from a boot loader.
> 
> Why do you need a bootloader then?

To boot and that is it.  It is a hardware specific ibinary boot chain that
finds the kernal on the hard drive and says - load that and run.

After that, it should serve no purpose.

> 
> I'd suggest playing with embedded devices for a while. Their boot chain
> is usually much simpler than on PC hardware. There you can really get a
> feeling of how easy and decoupled stuff could have been. Load a kernel
> directly to some location in memory and just jump there.
> 

That is pretty much all you want.  Firmware creep has gotten so 
unecesserily complex that UEFI has a virtual machine running in it.

I don't need or want it to play a multiplayer networked version of 
freecell.  I just need it to find the kernel and load it.

> Then try to expand a bit by reading the kernel from some specific flash
> device, or even network.  

Hardware interupts work to announce hardware on the bus.  The devices 
announce themselves on the system bus.

> Maybe trying to make the kernel do the right
> thing depending on where it was booted from.  

No it doesn't unless your hardware is broken.  Why should it?
The kernel responds independently to its hardware environment.
These show up is dmesg.

> Or add a file system to
> the flash.  Etc.  Maybe you even want some way to configure the
> bootloader from the OS?
> 

This wasn't invented with UEFI.  

> Add all the features you take for granted on PC hardware.
> 
> I think you will find that the OS has to be aware of some of the stuff
> the bootloader does.  And that many of the features depend on the OS
> communicating with the bootloader somehow.  

Why?  The Kernel interacts with the hardware independently.  
The devices each have their own firmware and process data
according to an API and the Kernel either natively, or through loaded
modules, processes data from the devices.  There is nothing here for a
boot loader to do.  It ran its bit on the stack and it should be gone.

If you run a system in BIOS mode or even with just a BIOS, the Kernal 
can still do everything, including SATA and Thunderbolt, Firewire,
PCI-Express, SATA etc.

What can it do with UEFI that it can not do with BIOS?

-- 
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
http://www.mrbrklyn.com 

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!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Greg KH]

On Thu, Sep 23, 2021 at 05:17:41AM -0400, Ruben Safir wrote:
> On Thu, Sep 23, 2021 at 09:13:02AM +0200, Bjørn Mork wrote:
> > Ruben Safir <ruben@mrbrklyn.com> writes:
> > 
> > > OS's shouldn't need anything from a boot loader.
> > 
> > Why do you need a bootloader then?
> 
> To boot and that is it.  It is a hardware specific ibinary boot chain that
> finds the kernal on the hard drive and says - load that and run.
> 
> After that, it should serve no purpose.

That is not how modern hardware works, sorry.

If you wish to revisit this, please talk to the hardware designers.

> > I'd suggest playing with embedded devices for a while. Their boot chain
> > is usually much simpler than on PC hardware. There you can really get a
> > feeling of how easy and decoupled stuff could have been. Load a kernel
> > directly to some location in memory and just jump there.
> > 
> 
> That is pretty much all you want.  Firmware creep has gotten so 
> unecesserily complex that UEFI has a virtual machine running in it.

You mean ACPI?  :)

You do remember APM, right?

> I don't need or want it to play a multiplayer networked version of 
> freecell.  I just need it to find the kernel and load it.

You also need to know how to stop the machine, change power levels,
detect some hardware changes, and so on.

> > Then try to expand a bit by reading the kernel from some specific flash
> > device, or even network.  
> 
> Hardware interupts work to announce hardware on the bus.  The devices 
> announce themselves on the system bus.

What exactly do you mean by "system bus"?

> > Or add a file system to
> > the flash.  Etc.  Maybe you even want some way to configure the
> > bootloader from the OS?
> > 
> 
> This wasn't invented with UEFI.  
> 
> > Add all the features you take for granted on PC hardware.
> > 
> > I think you will find that the OS has to be aware of some of the stuff
> > the bootloader does.  And that many of the features depend on the OS
> > communicating with the bootloader somehow.  
> 
> Why?  The Kernel interacts with the hardware independently.  
> The devices each have their own firmware and process data
> according to an API and the Kernel either natively, or through loaded
> modules, processes data from the devices.  There is nothing here for a
> boot loader to do.  It ran its bit on the stack and it should be gone.
> 
> If you run a system in BIOS mode or even with just a BIOS, the Kernal 
> can still do everything, including SATA and Thunderbolt, Firewire,
> PCI-Express, SATA etc.
> 
> What can it do with UEFI that it can not do with BIOS?

What do you think that BIOS is?  It's the same thing that UEFI is, just
that UEFI is the "newer version and standard of BIOS" that solved many
many things that were wrong with the BIOS interface and specification.

Again, remember APM?

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

On 9/22/21 4:41 AM, FMDF 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?
> 
> 
> Not from the boot loader, but the OS needs system information from the UEFI.


Please send your answer to the LIST and never directly to me.




-- 
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
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[FMDF]

[-- Attachment #1.1: Type: text/plain, Size: 1151 bytes --]

On Wed, 22 Sep 2021, 08:22 Ruben Safir, <ruben@mrbrklyn.com> 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?
>

I think you are still making confusion: UEFI bootloaders and UEFI are two
different entities.

UEFI bootloaders (like Grub2) serve the purpose to locate, pass kernel
options  and platform information to the kernel that themselves are going
to boot.

Instead the UEFI is an interface between the running OS and the platform
firmware.

UEFI defines two types of services: boot services and runtime services.

After booting is done, via UEFI boot services and eventually UEFI
bootloaders, the OS does not need anymore the bootloader and the UEFI boot
services.

Instead the OS needs UEFI runtime services to talk to the platform
firmware. For example, if OS cannot talk to the platform via UEFI, it
cannot even shutdown the system (obviously there is much more than simply
shutting down). How can an OS know that you've attached a plug and play
device if it cannot talk to the platform firmware?

Fabio


>

[-- Attachment #1.2: Type: text/html, Size: 2435 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[FMDF]

[-- Attachment #1.1: Type: text/plain, Size: 1570 bytes --]

On Thu, 23 Sep 2021, 09:11 FMDF, <fmdefrancesco@gmail.com> wrote:

> On Wed, 22 Sep 2021, 08:22 Ruben Safir, <ruben@mrbrklyn.com> 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?
>>
>
> I think you are still making confusion: UEFI bootloaders and UEFI are two
> different entities.
>
> UEFI bootloaders (like Grub2) serve the purpose to locate, pass kernel
> options  and platform information to the kernel that themselves are going
> to boot.
>
> Instead the UEFI is an interface between the running OS and the platform
> firmware.
>
> UEFI defines two types of services: boot services and runtime services.
>
> After booting is done, via UEFI boot services and eventually UEFI
> bootloaders, the OS does not need anymore the bootloader and the UEFI boot
> services.
>
> Instead the OS needs UEFI runtime services to talk to the platform
> firmware. For example, if OS cannot talk to the platform via UEFI, it
> cannot even shutdown the system (obviously there is much more than simply
> shutting down). How can an OS know that you've attached a plug and play
> device if it cannot talk to the platform firmware?
>
> Fabio
>

For sake of completeness and for better understanding that OS need UEFI,
but not necessarily EFI bootloaders, please read the following document:

https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.html

Linux can boot without bootloaders, but it still needs to use UEFI at
runtime.

Fabio

>

[-- Attachment #1.2: Type: text/html, Size: 3344 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[FMDF]

[-- Attachment #1.1: Type: text/plain, Size: 1846 bytes --]

On Thu, 23 Sep 2021, 09:22 FMDF, <fmdefrancesco@gmail.com> wrote:

> On Thu, 23 Sep 2021, 09:11 FMDF, <fmdefrancesco@gmail.com> wrote:
>
>> On Wed, 22 Sep 2021, 08:22 Ruben Safir, <ruben@mrbrklyn.com> 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?
>>>
>>
>> I think you are still making confusion: UEFI bootloaders and UEFI are two
>> different entities.
>>
>> UEFI bootloaders (like Grub2) serve the purpose to locate, pass kernel
>> options  and platform information to the kernel that themselves are going
>> to boot.
>>
>> Instead the UEFI is an interface between the running OS and the platform
>> firmware.
>>
>> UEFI defines two types of services: boot services and runtime services.
>>
>> After booting is done, via UEFI boot services and eventually UEFI
>> bootloaders, the OS does not need anymore the bootloader and the UEFI boot
>> services.
>>
>> Instead the OS needs UEFI runtime services to talk to the platform
>> firmware. For example, if OS cannot talk to the platform via UEFI, it
>> cannot even shutdown the system (obviously there is much more than simply
>> shutting down). How can an OS know that you've attached a plug and play
>> device if it cannot talk to the platform firmware?
>>
>> Fabio
>>
>
> For sake of completeness and for better understanding that OS need UEFI,
> but not necessarily EFI bootloaders, please read the following document:
>
> https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.html
>
> Linux can boot without bootloaders, but it still needs to use UEFI at
> runtime.
>
> Fabio
>


While at this, please read also:

https://www.kernel.org/doc/html/latest/arm/uefi.html
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

[-- Attachment #1.2: Type: text/html, Size: 4430 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

On 9/23/21 3:27 AM, FMDF wrote:
> but it still needs to use UEFI at runtime.
no if it is on a bios system



-- 
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
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Greg KH]

On Thu, Sep 23, 2021 at 08:24:10AM -0400, Ruben Safir wrote:
> On 9/23/21 3:27 AM, FMDF wrote:
> > but it still needs to use UEFI at runtime.
> no if it is on a bios system

If you are using the old "BIOS" interface, there are still places where
that BIOS takes over control from the CPU and does things behind the
operating system's back.  There are also things that the BIOS does that
the operating system must talk to over time in order to coordinate
things like power management and "simple" things like powering off the
system (hint, that's not a simple thing).

So your old BIOS was still sitting there running and providing services
to the operating system just like UEFI does so today.  That has not
changed except that a number of the issues involved with that old
interface have been fixed up, and a number of new interfaces have been
added.

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Ruben Safir]

On Thu, Sep 23, 2021 at 09:11:32AM +0200, FMDF wrote:
> On Wed, 22 Sep 2021, 08:22 Ruben Safir, <ruben@mrbrklyn.com> 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?
> >
> 
> I think you are still making confusion: UEFI bootloaders and UEFI are two
> different entities.
> 
> UEFI bootloaders (like Grub2) 

Grub is not a UEFI bootloader.  Actually, with UEFI, you don't need
grub.  UEFI has effectively moved the boot loader to the system
firmware.  Grub2 is a secondary bootloader, and it is not really needed.

https://bbs.archlinux.org/viewtopic.php?id=229634
https://archived.forum.manjaro.org/t/can-i-use-pure-uefi-without-grub/21367/2


> serve the purpose to locate, pass kernel
> options  and platform information to the kernel that themselves are going
> to boot.
> 
> Instead the UEFI is an interface between the running OS and the platform
> firmware.
>

Yeah - that is what I am discovering!  Why do I need that?  If the SAME
OS is run from BIOS, it doesn't exist like that.


> UEFI defines two types of services: boot services and runtime services.
> 
> After booting is done, via UEFI boot services and eventually UEFI
> bootloaders, the OS does not need anymore the bootloader and the UEFI boot
> services.
> 
> Instead the OS needs UEFI runtime services to talk to the platform
> firmware. 

What is that?  The kernel is on the Metal.  It is talking directly to
the hardware.

> For example, if OS cannot talk to the platform via UEFI, it
> cannot even shutdown the system

That is another issue.  I don't even want to get into why my HP
workstations don't shutdown properly.

It doesn't need UEFI to shutdown.  It has been able to do that for over
25 years.


> (obviously there is much more than simply
> shutting down). How can an OS know that you've attached a plug and play
> device if it cannot talk to the platform firmware?
> 
What are you talking about?  The Kernel doesn't need UEFI to know a
device is attached and to autoload a kernel module and talk to it.

It causes an interupt and announces itself on the systembus.

What do you think those thousands of hardware choices are about when you 
compile the kernel?

BIOS systems can do that 100%.  And then there is other hardware, like
ARM.

It is useless to for me to argue what I would want to have happen.  I
have no say and nobody cares about my opinion.  I do want to know what
it is doing, though, and why I can't install a UEFI boot system from a
thumdrive that loads in BIOS mode.

-- 
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
http://www.mrbrklyn.com 

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!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: efivars

[Greg KH]

On Thu, Sep 23, 2021 at 05:38:27AM -0400, Ruben Safir wrote:
> > Instead the OS needs UEFI runtime services to talk to the platform
> > firmware. 
> 
> What is that?  The kernel is on the Metal.  It is talking directly to
> the hardware.

No it is not.  It is turtles all the way down, sorry.

> > (obviously there is much more than simply
> > shutting down). How can an OS know that you've attached a plug and play
> > device if it cannot talk to the platform firmware?
> > 
> What are you talking about?  The Kernel doesn't need UEFI to know a
> device is attached and to autoload a kernel module and talk to it.

Yes it does.

> It causes an interupt and announces itself on the systembus.

What do you mean exactly by "systembus"?  I have never heard of such a
thing.

> What do you think those thousands of hardware choices are about when you 
> compile the kernel?

Those are options that the kernel can enable/disable support for and
have nothing to do with how the kernel can find those devices in the
system.

> BIOS systems can do that 100%.

As I stated before, UEFI is just the newer standard of BIOS.

> And then there is other hardware, like
> ARM.

UEFI runs on many ARM systems.

Those that do not use UEFI rely on device trees to get information for
what the system looks like and how to talk to it.  x86 systems do not
use device tree, sorry.

> It is useless to for me to argue what I would want to have happen.  I
> have no say and nobody cares about my opinion.  I do want to know what
> it is doing, though, and why I can't install a UEFI boot system from a
> thumdrive that loads in BIOS mode.

Because those are two different standards.

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies