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
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
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
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
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
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
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
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_n...> 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_n...> [3] <https://en.m.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#cite_n...> 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
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
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
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
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
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
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?
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
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
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
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:
Private page :(
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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/...
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
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
participants (6)
-
Bjørn Mork -
Dave Stevens -
FMDF -
Greg KH -
Ruben Safir -
Valdis Klētnieks