Puppy Linux Discussion Forum

What a rant!

In case you do not know:
Puppy does support secure boot.
The last official Puppy, Fossapup64, is 64bit only.
And Puppy is probably the fastest OS on a new machine.
Puppy is going forward.

Modern 'security' (EFI and secureboot) itself has introduced a lot of vulnerabilities.
It is not because MS calls it secure, that it is secure. It is just a signature.

What is wrong with 32bit anyway? What is wrong with an old puter?

By the way, you got Precise and BBpup booting from the same pendrive by now?

@foxpup wrote:

In case you do not know:
Puppy does support secure boot.

You are indeed right again and I am again wrong for which I apologize to all for being the source of false information. As can be seen from the title of this topic Precise Light and BionicPup are my daily drivers. As far as I know these distros do not support secure boot. After reading your post I wondered if you were referring to FossaPup so I examined my test installation of FossaPup and was pleasantly suprised to find these files in /EFI/boot:

bootia32.efi  bootx64.efi  fatdog64.cer  grubx64.efi  mmx64.efi

instead of what is found in BionicPup's /EFI/boot:

bootia32.efi  bootx64.efi

I think this is using Mathew Garrett's shim to support secure booting. I have some questions for you or anyone else that knows.

Is bootx64.efi Mathew Garrett's shim and grubx64.efi the original bootx64.efi (actually a functionally equivalent replacement for bootx64.efi)?

If this is true then the shim can be used in two ways:

A. As a link in the chain of trust.

B. As a device to circumvent "secure boot" by allowing the user to boot an unsigned kernel without having to disable "secure boot" in the BIOS.

Specifically, the shim bootx64.efi is trusted by the UEFI firmware as it is signed by Microsoft. So, the UEFI firmware transfers control to bootx64.efi. grubx64.efi is trusted by bootx64.efi as it is signed by an entity that matches the public key in fatdog64.cer, which the user has manually accepted as trustworthy. So, bootx64.efi transfers control to grubx64.efi. At this point the UEFI firmware is no longer involved in verifying trust. That responsibility now belongs to grubx64.efi. grubx64.efi can do one of two things:

A. Continue the chain of trust by verifying the signature of the kernel vmlinux before transferring control to vmlinux.

B. Just load and transfer control to an unsigned kernel.

So, which of the above is grubx64.efi doing?

If it does A does the kernel vmlinux further extend the chain of trust by verifying the kernel modules *.ko files before loading them?

m-cuda wrote: ↑Thu Dec 17, 2020 8:57 am

Is bootx64.efi Mathew Garrett's shim and grubx64.efi the original bootx64.efi (actually a functionally equivalent replacement for bootx64.efi)?

Yes and almost.
EFI goes looking for anything that it can boot, efi binaries, but has a preference for /EFI/boot/bootx64.efi.
This bootx64.efi can be anything renamed.
If you do not want to support secure boot, you could put your preferred unsigned bootloader there, rEFInd, grub2, or even fallback.
It makes sense to put shim there if you want to support secure boot. In that case the bootloader sits next to shim and has to be signed.

So, which of the above is grubx64.efi doing?

I was thinking that too, until I read (and understood ) this excellent text:
https://en.wikipedia.org/wiki/Unified_E ... _criticism
Especially the third paragraph about the different linux implementations of shim.
It is not the grubx64.efi, the grub2 bootloader, that decides how far the chain of trust goes, it is shim!

m-cuda wrote: ↑Thu Dec 17, 2020 8:57 am

After reading your post I wondered if you were referring to FossaPup so I examined my test installation of FossaPup and was pleasantly suprised to find these files in /EFI/boot:

Code: Select all

bootia32.efi  bootx64.efi  fatdog64.cer  grubx64.efi  mmx64.efi

That could have been what I was referring to, but in fact, I was thinking of frugalpup from gyro.
Frugalpup has known a long chain of development and I consider it to be the one that brought secure boot support to Puppylinux.
Frugalpup is certainly one of the most interesting tools developed in Puppylinux.

@foxpup wrote (emphasis are mine):

So, which of the above is grubx64.efi doing?

I was thinking that too, until I read (and understood ) this excellent text:
https://en.wikipedia.org/wiki/Unified_E ... _criticism
Especially the third paragraph about the different linux implementations of shim.
It is not the grubx64.efi, the grub2 bootloader, that decides how far the chain of trust goes, it is shim!

I think you have misunderstood the excellent text.

All links in the chain of trust including grubx64.efi "can decide how far the chain of trust goes", not exclusively the shim!

Anyway, this just avoids answering the still important question of:

grubx64.efi can do one of two things:

A. Continue the chain of trust by verifying the signature of the kernel vmlinux before transferring control to vmlinux.

B. Just load and transfer control to an unsigned kernel.

So, which of the above is grubx64.efi doing?

m-cuda wrote: ↑Fri Dec 18, 2020 5:33 am

All links in the chain of trust including grubx64.efi "can decide how far the chain of trust goes", not exclusively the shim!

Why do you say so? Where do you read this? In this text or in another one?

You are right for grub2, it can do that. I've checked their manual.
So it depends on the builder of the grub efi binary.

You could check if the kernel of Puppy is signed
or drop to the grub command line (c) and ask for the environment variables (set) and look what check_signatures says.

Why do you think this important?

By the way, I think we are getting way out of scope for this thread.
Have you managed to dual boot Precise en BBpup?

Here is my two cent's on @Clarity 's post - https://forum.puppylinux.com/viewtopic ... 477#p12477
and @foxpup's comment:

What is wrong with 32bit anyway? What is wrong with an old puter?

I am a very frugal person and I have always tried to make the maximum use of the things that I have and I have tried mightly to use my ASUS Eee PC as a daily driver. After years of trying I have conclude that old hardware is not a viable option for a daily driver if daily driving includes browsing modern web pages and playing modern videos because:

• Old CPUs do not have the CPU cycles to render modern web pages in a timely way. When browsing some web pages both cores of my Atom CPU would be at or near 100% and it would take many seconds to respond to a mouse or keyboard event.

• The GPUs on old motherboards will not support hardware video acceleration for modern codecs, e.g. VP9 and H.265(HEVC). These codecs did not exists when the GPU was manufactured. Although, GPU firmware can be updated, the updates I have seen are patches or tweaks to existing features. I don't know of an update that has deployed a whole new codec. Compared to VP8 and H.264(AVC), VP9 and HEVC have very impressive compression ratios but this comes at the cost of more CPU cycles required for decoding straining an already strained CPU. VP9 is especially important because about half the videos on YouTube are now VP9.

• The private DRM video decryption keys needed to play a hardware DRM protected video must be burned into firmware on the motherboard. Old motherboards do not have these decryption keys (and the ancillary TEE software) burned into their firmware and cannot play hardware DRM protected videos. I see more and more free YouTube videos that are clearly never intended to be sold but nevertheless the video creator wants to prevent anyone from making a copy and protects his video with DRM encryption. (Although, I don't know if these are using hardware DRM or software DRM.)

Instead of old hardware, in my opinion Puppy really works well as a replacement for Windows on a brand new very cheap laptop. These machines are painfully slow running Windows but can run Puppy fast enough and they have GPUs with support for modern codecs and motherboards with the DRM firmware. This is how I use Puppy.

@foxpup wrote in viewtopic.php?p=12169#p12169:

m-cuda wrote: ↑Sun Nov 15, 2020 1:26 pm
Conjecture:

bootx64.efi does not know the partition it was loaded from and searches all available partitions for a grub.cfg to use.

Is this conjecture correct? Is there any way to force bootx64.efi to use the grub.cfg from the same partition where the bootx64.efi lives?

Yes the conjecture is right. Where it is going to look is 'programmed' before the bootx64.efi was compiled.
So if you want it differently, you will have to program and compile the bootx64.efi yourself.

In fact the conjecture is false. I have a flash drive with antiX Linux installed on partition /dev/sdb3 and MX Linux installed on partition /dev/sdb1. When I use the UEFI firmware to select partition sdb1 the BOOTx64.efi on that partition loads the MX grub.cfg from that partition and then loads the MX vmlinuz from the same partition. When I use the UEFI firmware to select partition sdb3 the BOOTx64.efi on that partition loads the antiX grub.cfg from that partition and then loads the antiX vmlinuz from the same partition. Note that MX Linux is derived from antiX and they share the same boot system - cmp shows that the BOOTx64.efis are identical.

The MX grub shell shows the variable $cmdpath has the value (hd0,gpt1)/efi/path. The antiX grub shell shows the variable $cmdpath has the value (hd0,gpt3)/efi/boot. So each bootx64.efi knows the partition and the path it was loaded from.

I don't know the exact mechanism of how bootx64.efi finds out the partition it was loaded from. It doesn't appear to be passed as an argument to efi_main(). But, after reading Intel's "Extensible Firmware Interface Specification" I learned that the UEFI firmware has a function GetVariable() which the code in bootx64.efi can call and suspect that bootx64.efi calls back into the UEFI firmware to get this value. This is pure speculation on my part. However, it is true that bootx64.efi can know the partition it was loaded from as the $cmdpath variable shows. So, the conjecture is false.

However, the value of $cmdpath in BionicPup64's grub shell is (hd0)/efi/boot. It is missing the partition.

@foxpup wrote:

Why do you say so? Where do you read this? In this text or in another one?

It follows from the basic principle by which the chain of trust works. Nothing in the Wikipedia article contradicts this because it can't.

You are right for grub2, it can do that. I've checked their manual.
So it depends on the builder of the grub efi binary.

Any grub implementation that supports secure boot must work in accordance to basic principle by which the chain of trust works. Of course the shim or any other link in the chain can ignore its responsibility load and transfer control to an unsigned binary. But, the point is the shim isn't special as you have claimed. With respect to trustworthiness all links in the chain share an equal responsibility.

You could check if the kernel of Puppy is signed

Until two years ago I used Windows as my daily driver and although I have learned a lot about Puppy in two years in many ways I am still a noob. In particular, I don't know how to verify a digital signature of a binary. (This was easy in Windows as there is a GUI tool for doing this.) Please tell me the tool to use in Puppy?

or drop to the grub command line (c) and ask for the environment variables (set) and look what check_signatures says.

Thank-you for telling me about the variable check_signatures. I did not know about this variable. Unfortunately, I can no longer do this myself as just yesterday I installed MX Linux to the partition where FossaPup formerly lived and I don't have a spare partition to re-install FossaPup. Since, I can no longer do this myself to satisfy my curiosity please do me a favor and tell me the value of check_signatures for either FossaPup or frugalpup.

Why do you think this important?

To be honest I will be replacing Puppy with a more secure distro. Until two years ago Windows was my daily driver. Windows takes security extremely seriously. I was quite comfortable with Windows's security. (Unfortunately, Windows runs very slowly on the class of hardware that I can afford to buy.) I really am not comfortable with Puppy's security. The reality is Puppy is probably safe enough. But, is safety by obscurity - the market share of Puppy and Linux desktops in general is probably too small to make them a likely target for malware writers. But, the sense of security that you get from security by obscurity is not the same as the sense of security that you get from having real protection. Would you rather have your valuables hidden under a rock or locked in a safe? It is an emotional thing really. I am the type of person that out of proportion to the actual risk I am going to worry and not have peace of mind. Not having peace of mind is an unnecessary emotional toll that I can and will avoid by having a more secure OS.

My first impression of MX Linux is:

• It is very fast and stable on my Dell Inspiron 11 model 3180 laptop with a AMD A6-9220e processor and 4GB memory, subjectvely comparable to Puppy.

• It is more secure than Puppy as it makes better use of DAC and supports MAC(AppArmor) out of the box. Moreover, from posts in the MX forum I believe that it can be optionally further hardened.

• On the downside, I don't think it supports secure boot and the constellation of desktop tools and applications in my opinion is inferior to that of Puppy. Although, this may just be a matter of getting use to a new constellation.

Have you managed to dual boot Precise en BBpup?

For quite some time I have been using a very simple and fast procedure of my own design for creating multi-boot, EFI bootable disks. But, this procedure is probably known and used by many others as it is quite obvious if you think about it. If you read my original post carefully you will understand that I was not looking for any such procedure but a tweak to make my procedure work better. Further, if you read carefully you will see that I really only want a solution to a specialized multi-boot problem rather than a complete generic multi-boot problem. I would have gladly shared my procedure, but both you and bigpup were so adamant that you knew the best procedure and no other procedure could be better. Frankly, I am put off by that kind of arrogance. However, I will leave you with this hint. With respect to UEFI booting the end result of an installation is that certain files exists in certain locations in a FAT32 filesystem. Is there not another way to achieve this same result without going through bigpup's rather long and complicated procedure? N.B. Since, I am not using legacy booting the specialized tools needed to manipulate the MBR are not necessary.

As this may be my final post (or may not but as you can tell I am quite smitten with MX Linux) I wish to thank everyone that responded to my questions. I certainly learned a lot and am very grateful for what I have learned.

For the conjecture. It is true for the grub binaries from Puppy.
I mean, they do not look for a specific partition, they look for a grub configfile on a few places where Puppy usually puts its grub files.
As I already said, there are tons of possibilities to build your grub binary and MX/Antix seem to do it differently.
About every distro has its own way.
A grub configfile inside the grub binary is usually a big part of it.
You can read the grub2 manual or on arch wiki if you are interested.
It can get quite complicated.

I do not use "secure" boot nor the grub from fossapup or frugalpup (probably the same),
so I cannot tell you the check_signature variable.
But you do not have to install the whole fossapup to know.
It is easy enough to add the grub to any fat32 partition and start a boot from that.

I am sure you can check the signatures from any file, also 'puppy' files in windows or MX.
I would have to look up the linux command. Something with sign (pesign?). It is possible you have to install it on Puppy.