Puppy Linux Discussion Forum

Duprate wrote:

add the microcode (it didn't work, maybe the kernel was not configured for that).

The running kernel is from the official Debian "linux-image-*" package, it should have the patches applied for Spectre and Meltdown, almost sure.
I could be that the microcode you added should be part of the initrd (to be loaded at boot), but just guessing, to be honest I know very little about Spectre and Meltdown, how to apply things, sorry.
EDIT: Don't know how you did add the microcode, but there's package "intel-microcode" in Sid repository, not sure if it helps, just saying.

The save file I converted to changes.squashfs.

I was wondering if that works OK also with deleted files (that are included in 01-filesystem.squashfs), did a quick test and it seems to work ok (masking the deleted files). Although it can be tested more. It worked well with aufs, but with overlay it may be different...

Fred

Good afternoon! As shown in the image, I put the microcode in the firmware folder. After loading the system, with the command "echo 1> / sys / device / system / cpu / microcode / reload, I managed to load the microcode late, but the vulnerabilities continued ... originally, in PupSysinfo the value would be" microcode: 0x19 ", after reloading it was" 0x28 ".

1- I had previously placed the microcode in the initrd folder, as I do in the other distros I have (all aufs). Did not work.
2- First I tested it with the kernel you provided. Then, with the kernel 5.4.80, which I compiled from the source "Kernel.org", but the result was the same.
3- I will make Kernel-5.4.80 available to you in a few minutes at: It is no longer available!

The kernel has the firmware together. To test this kernel, it is also necessary to open initrd, and in the / lib / modules / folder change the module to 5.4.80. Debian is hard work ...The problem is how to load the microcode using overlay ...

In fact, most developers are neglecting to mitigate processor vulnerabilities. As far as I know, only the developers of FatDog64 have really cared about this for a long time! They make life easier for the user.

Anyway, systems based on other systems, inherit the problems of those systems and their developers.

There is a way to load the microcode, described by a very active member of the Forum, who has very creative ideas:
"Microcode 64bit Updates & howto
Post by ozsouth »Wed Nov 11, 2020 8:27 am
How to use microcode-update- (x) -64.cpio files in Puppy on 64bit UEFI systems:
EFI folder structure - on boot partition (I use folder micd, as in examples below):
/ EFI / BOOT / micd .cpio file goes in folder micd, on same level as folders with initrd.gz
if grub bootloader, initrd line:
initrd /EFI/BOOT/micd/microcode-update-(x)-64.cpio /EFI/BOOT/(folder)/initrd.gz
if syslinux bootloader, initrd line:
initrd micd / microcode-update- (x) -64.cpio, (folder) /initrd.gz "

So, following this example, I placed the file "ucode11112020.cpio" in the same directory where this "initrd" and Grub was like this:

menuentry "DebianDog Overlay Kernel 5.9.0-3" {
linux /DebianDog/live/vmlinuz1 kvm.nx_huge_pages = auto lockdown = confidentiality noauto copy2ram from = / DebianDog /
initrd /DebianDog/live/ucode11112020.cpio /DebianDog/live/initrd1.xz
}
I will make the ucode11112020.cpio file available at the same address where I put the kernel 5.4.80, but with this procedure described by ozsouth, it is not even worth changing the kernel or wiggling a lot.

* Itlb_multihit: KVM: remains vulnerable, but this is only a problem where attacks against the iTLB di system multitits errata can be mounted from malicious guests on virtualized systems.

Hi Duprate, good to see that you've found a way and thanks for the info!
Btw, @rcrsn51 has posted about it too: viewtopic.php?p=10976#p10976

Fred

Hi Fred! In whatever I can help, I will make available what I have. However, if I offer something that is of interest to you, it is always good for you to review ...

Duprate wrote:

However, if I offer something that is of interest to you, it is always good for you to review

I did test your method (and also from rcrsn51) and makes no difference for me (both "vulnerable") probably because of my hardware not supported (that, in fact, I knew already in 2018) HP Compaq 6710b laptop from 2007. But your info can be valuable for other people .

Fred

I think I have other useful information. I noticed that Firefox originally browses as Root. So, I thought: He has to work as a puppy. I modified the "run-as-spot" script, for DebianDog it's called run-as-puppy. I put it in / home / puppy.
In / usr / share / applications, open "Firefox ESR" as text and in Exec=/usr/lib/firefox-esr/firefox-esr %u, edit like this:
Exec=/home/puppy/run-as-puppy /usr/lib/firefox-esr/ firefox-esr %u
The bad thing is that your browser customization will have to be done again, copying from root does not work.
The good thing is that you will be surfing without root privileges, just like the other puppies.

@Duprate
DebianDogs already have the facility to run as an unprivileged user. It has a program run-as-user, which is exeuted the same as run-as-spot.

fredx181 wrote: ↑Fri Nov 27, 2020 9:14 pm

(and also from rcrsn51)

Was this a Grub4Dos or GRUB2 system? The key issue is whether you can put multiple items on the initrd line.

Was this a Grub4Dos or GRUB2 system? The key issue is whether you can put multiple items on the initrd line

Grub4Dos.
And dmesg says "updated early" so I guess intel-ucode.img is loaded:

root@live:~# dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0x60f, date = 2010-09-29
[    0.096388] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[    3.589666] microcode: sig=0x10676, pf=0x80, revision=0x60f
[    3.589733] microcode: Microcode Update Driver: v2.2.

The only difference of spectre-meltdown-checker output is that it shows "ucode 0x60f" (without loading the intel-ucode.img, it shows ucode 0x60c)

family 0x6 model 0x17 stepping 0x6 ucode 0x60f cpuid 0x10676

For the rest all "Vulnerable" is the same.

Fred

I ran some tests on a very old Core i3 and a recent Celeron N2870.

In both cases, the checker reports no problems with Spectre/Meltdown (5753,5715,5754) , with or WITHOUT the microcode. Is that because the kernel now handles them?

For other vulnerabilities, the microcode fixed everything on the Celeron, but left 4 problems with the i3.

rcrsn51 wrote: ↑Sat Nov 28, 2020 1:53 pm

I ran some tests on a very old Core i3 and a recent Celeron N2870.

In both cases, the checker reports no problems with Spectre/Meltdown (5753,5715,5754) , with or WITHOUT the microcode.
...

Same for me (5753,5715,5754 (and more) with or WITHOUT the microcode):

Not sure if I should be too much concerned about the "red ones" ?

Is that because the kernel now handles them?

Could very well be, but not sure.
Fred

It looks like my old Core i3 is only slightly better than your Core2Duo. Maybe someone with a newer Core ix will report.

TerryH wrote: ↑Sat Nov 28, 2020 2:08 am

@Duprate
DebianDogs already have the facility to run as an unprivileged user. It has a program run-as-user, which is exeuted the same as run-as-spot.

Nice! I know little about DebianDog. I didn't know ... But like water, I always find the way. Thanks!

Good afternoon! I installed the latest version of Vivaldi, creating an extra file "05-vivaldi.squashfs". It works without "root" privileges in a single file inside / home / puppy, without spreading settings across the system. The size is 119Mb. If a user is interested, I can prepare an English version and remove some personal settings.

EDIT 2021-01-06 new attached loadmodule script, bug fix:
- Fixed that in some (or more) cases the filelist (containing symlinks) in /etc/SFS wasn't created.
-------------------------------------------------------------------
EDIT 2020-12-07 new attached loadmodule and rmbrokenlinks.sh, change:
- No empty directories are left behind after unloading.
-------------------------------------------------------------------
EDIT 2020-12-06 new attached loadmodule and rmbrokenlinks.sh, changes:
- Fixed the problem that while a module is loaded, some packages may fail to install (with apt) because of not being able to overwrite files located in folders that are symlinked to a read-only filesystem (mounted read-only .squashfs). See also: viewtopic.php?p=11666#p11666
- The method to symlink the files (only symlinks to files, folders will be created) is "cp -arsn .... ....", this may leave some empty folders after unloading, which is not a real problem IMO.
- Attached script "rmbrokenlinks.sh", to remove leftover broken symlinks, if needed run it at startup, or, to run automatically at boot, place it in /root/Startup or /etc/profile.d (the latter works on Sid and Buster, needs to have .sh extension though)
-------------------------------------------------------------------
EDIT 2020-12-03 new attached loadmodule script, changes:
- when loading a module, it outputs now a file list named after the module (in /etc/SFS), the list can be used by running "rmbrokenlinks.sh" (see below) script at (next) startup, in case the (broken) symlinks did remain in the system after forgotten to unload and e.g. a system crash or power down
- support for filenames including spaces (added double quotes around some variables)
- Attached script "rmbrokenlinks.sh", to remove leftover broken symlinks, if needed run it at startup, or, to run automatically at boot, place it in /root/Startup or /etc/profile.d (the latter works on Sid, needs to have .sh extension though)
-------------------------------------------------------------------
EDIT 2020-12-02 re-attached loadmodule, fixed slow unloading.
-------------------------------------------------------------------
Here's a script (loadmodule, attached) for testing to load SFS "on the fly" under the overlay based system (instead aufs), usage:

root@live: ~# ./loadmodule --help
This script will (de)activate a module 'On the Fly', e.g. *.squashfs, *.xzm or *.sfs.
Usage:
./loadmodule -a </path/to/module> to activate or: 
./loadmodule -d </path/to/module> to deactivate 

It works by symlinking files from the SFS in the system when activating, deactivate will remove them.
One difference compared to how loading SFS works under 'aufs' overlay system is: if the SFS isn't deactivated before rebooting, the files (symlinks) from the SFS will be included in the save storage (if used). So better deactivate after use. (EDIT, fixed now, see EDIT 2020-12-03)

Inspired by the ideas/discussion from @rufwoof and @wanderer (based on tinycore method of loading SFS using symlinks):
viewtopic.php?p=10778#p10778

Fred

I have not tested this, but if a file in the module is itself a symlink, will the correct link be linked into the filesystem?

Edit: I checked and this works OK.

I modified my-squash-loader to use the new loadmodule and activated a number of large packages. They all worked in some quick tests.

If a module is NOT unloaded in Session #1, do the broken links work again when the module is loaded in Session #2?

Edit: This looks OK too.

Would it be possible to create a shut-down script that would unload any orphaned modules?

In my tests, unloading is much slower than loading. Is there a reason for this?

Bill

Glad it works OK, thanks for testing.

Would it be possible to create a shut-down script that would unload any orphaned modules?

Yes, I thought of that too, but then, I think, it's best to mount the SFS's in separate folder (not in same dir as modules loaded at boot), so I changed in loadmodule, near the top to:

if [ -f /mnt/live/tmp/modules ]; then
CHNGS=/mnt/live/memory/images/SFS  # porteus-boot, separate SFS folder
else
CHNGS=/mnt/SFS  # live-boot, separate SFS folder
fi

And for to unload at reboot in scripts /usr/bin/wmreboot and /usr/bin/wmpoweroff, I added near the top (just under the whoami != root line):
EDIT 2020-12-02, Edited below, fixed slow unloading EDIT 2020-12-03 some changes/fixes (added quotes)

if [ -f /mnt/live/tmp/modules ]; then
CHNGS=/mnt/live/memory/images/SFS  # porteus-boot
else
CHNGS=/mnt/SFS  # live-boot
fi

if [ "$(ls $CHNGS 2> /dev/null)" ]; then
    for BUNDLE in $(ls $CHNGS); do
 FILES=$(find $CHNGS/$BUNDLE | sed "s|$CHNGS/$BUNDLE||")
umount $CHNGS/$BUNDLE && rmdir $CHNGS/$BUNDLE  # unmount squashfs, now check for broken symlinks to be removed...
    if [ $? -eq 0 ]; then
while read line; do
 if [ ! -e "$line" ]; then
 # speedup unloading, check first if symlink exists before removing
# if not doing that, rm outputs lots of error messages, which makes it very slow
[ -L "$line" ] && rm "$line"
 fi
done <<< "$FILES"
echo "Module $BUNDLE should be deactivated"
    fi
    done
fi

In my tests, unloading is much slower than loading. Is there a reason for this?

Yes it's slow, specially when unloading several modules, perhaps there's a faster way (without the "while read", using find maybe), not sure.

Fred

Since unloading is slow and there does not appear to be a penalty for not unloading a module, would it be simpler to make a "cleanup" tool that crawls your filesystem and removes any broken symlinks? You could run it occasionally or before backing up your save folder.

Or might this create new problems?

Or what about another option to loadmodule that just deletes any broken symlinks of a module that is not currently loaded?

Fixed the slow unloading, just as fast as loading now, re-attached loadmodule script here: viewtopic.php?p=11354#p11354
And edited the unload code (for in shutdown scripts) here: viewtopic.php?p=11416#p11416
Change is:

# speedup unloading, check first if symlink exists before removing (it can be already removed when symlink to parent folder has been removed)
# if not doing that, rm outputs lots of error messages, which makes it very slow
[ -L $line ] && rm $line

@Bill Just curious, why your interest in this new loadmodule concept ?
(I mean, assuming you use the aufs based frugal system, you have problems with that ? (I do have btw, unloading sometimes fails with aufs, but with this new concept, unloading cannot fail easily, I think)

Fred

rcrsn51 wrote: ↑Wed Dec 02, 2020 1:24 pm

Or what about another option to loadmodule that just deletes any broken symlinks of a module that is not currently loaded?

That might be good, or perhaps not necessary anymore now with the speedup of unloading ?
And what you think about adding the unload code to wmreboot and wmpoweroff ?

Fred

fredx181 wrote: ↑Wed Dec 02, 2020 5:20 pm

And what you think about adding the unload code to wmreboot and wmpoweroff ?

If a machine crashed or was powered down without running wmpoweroff, the links would remain.

But they would be automatically cleaned up on the next session with a proper load/unload.

rcrsn51 wrote: ↑Wed Dec 02, 2020 6:22 pm

fredx181 wrote: ↑Wed Dec 02, 2020 5:20 pm

And what you think about adding the unload code to wmreboot and wmpoweroff ?

If a machine crashed or was powered down without running wmpoweroff, the links would remain.

But they would be automatically cleaned up on the next session with a proper load/unload.

Yes, in case of crash, I'm thinking of letting loadmodule to create a filelist for each loaded module, e.g. in /etc/SFS (e.g. /etc/SFS/mymodule.squashfs.txt)
(and delete it after unloading)
And have a startup script (e.g. in /etc/profile.d) to delete all possibly broken symlinks at boot (in case of a crash) reading the file(s) in /etc/SFS :
EDIT: changed below code a little bit:

#!/bin/bash

  if [ "$(ls /etc/SFS/*.txt 2> /dev/null)" ]; then
for i in $(ls /etc/SFS/); do
echo "Remove broken symlinks listed in /etc/SFS/$i . . ."
    cat /etc/SFS/$i | while read line; do
 if [ ! -e "$line" ]; then
 [ -L "$line" ] && rm -f "$line"
 fi
    done
rm -f /etc/SFS/$i # remove list when done
done
  fi

Together with unloading the modules in the shutdown scripts, I guess it will prevent to remain broken symlinks.
It's all together rather complicated, but works (tested quickly).

Fred

That would be useful. I can see a situation where I might load a module for testing purposes, forget to unload it, then delete it.

Without some kind of cleanup, its broken links would remain forever.

I was impressed with how fast the new Unload function is.

See for a new attached "loadmodule" (and "rmbrokenlinks.sh" script) and changes info here: viewtopic.php?p=11354#p11354

Fred

Looks good.

From a multi-user point of view, will there be a problem putting these files in /etc/SFS?

Maybe a better place would be $HOME/.config/SFS

Or can non-root users even load a module in the first place?

rcrsn51 wrote:

From a multi-user point of view, will there be a problem putting these files in /etc/SFS?

Maybe a better place would be $HOME/.config/SFS

No, system-wide is better from multi-user point of view, say user Mike logs in, activates a module, then on next boot user Joe logs in, then $HOME/.config/SFS/... cannot be found.

Or can non-root users even load a module in the first place?

Mounting or unmounting can only be done as root (and creating the symlinks in the system too), so a "user" needs to run loadmodule with sudo or "gsu" (graphical sudo).
The older load module has at beginning of script:

[ "`whoami`" != "root" ] && exec gsu ${0}

When running as user it will bring up small GUI for entering password. I forgot to add it now.

Fred

Hi Fred:

This project is going well. I can foresee a situation where you abandon aufs and make this the standard method for load-on-the fly.

It also eliminates one of my headaches - accidentally getting a whiteout over a file in a squashfs layer (or doing it on purpose and forgetting). Now if you delete a file in a loaded module, you just delete the current symlink. On the next load, the file will reappear.

However, it is still possible to over-ride a file that is in a module. Just create the file when the module is unloaded. When the module loads, your copy takes precedence.

I was starting to like it too, but now found a big problem:
While a module is loaded, trying to install some packages with apt-get and some of them failed to install, example error message;

Preparing to unpack .../00-poppler-data_0.4.10-1_all.deb ...
Unpacking poppler-data (0.4.10-1) ...
dpkg: error processing archive /tmp/apt-dpkg-install-f5Fabi/00-poppler-data_0.4.10-1_all.deb (--unpack):
 unable to create '/etc/ghostscript/cidfmap.d/90gs-cjk-resource-cns1.conf.dpkg-new' (while processing './etc/ghostscript/cidfmap.d/90gs-cjk-resource-cns1.conf'): Read-only file system

The package (including same files as are in the loaded module) is trying to overwrite read-only files, which failed.
I found that the cause is that there are directories symlinked containing read-only files (from the read only mounted squashfs).
A solution is to unload the module, then the packages install OK, but that's not acceptable IMO.

I think I found a fix for the load function (by using cp to create the symlinks), but still testing...

Fred