New kernel options for trading off security for performance:
https://www.zdnet.com/article/linux-ker ... tigations/
New kernel options to disable Spectre mitigations
The Real Question is Whether Puppies need any mitigation
Most systems are Unitary --not distinguishing Storage from RAM, and constantly writing to Storage what will later be read into RAM.
By design, a Frugal Puppy Linux does not employ a Unitary system. It's operating system consist of compressed, Read-Only files: initrd, vmlinuz, Puppy_version_number.sfs, and any of the following compressed, Read-Only files: zdrv_xxx.sfs, fdrv_xxx.sfs, adrv_xxx.sfs and ydrv_xxx.sfs. Perhaps you could add some other compressed, Read-only sfses with different first initials. The contents of these files are read into RAM as and when needed. Puppy's operating system exists only in RAM, and then only until Puppy is shut-down/rebooted. Whatever was is RAM is cleared on shut-down.
Viruses and other malware can not infect the aforementioned files. Or at least not without a significant and easily discovered and thwarted attempt. To write to them you have to decompress them and the modified file re-compressed and substituted for the original. The occurrence of that activity, if not obvious as having a significant impact on performance, could easily be identified by a simple monitor triggering a notice and perhaps requiring a user specified password --perhaps preserved in a compressed, write-once-read-only thereafter xdrv.sfs-- to continue.
Puppy's only 'Achilies' heel' is its SaveFile and SaveFolder. I'll leave it to others to figure out how to protect the 'decompressed/exposed' contents of a SaveFolder. But a SaveFile, while write-able, is compressed. The default Automatic Write every 30 minutes can be set to 'Never'. Preservation of necessary changes can be made immediately upon bootup and while not on the internet, with the exception of changes to applications that provide access to the internet. Changes to the latter could at least be made immediately upon bootup and before accessing potentially insecure websites.
If Spectre and Meltdown remain a 'theoretical threat' to other operating systems, they are pretty much a fantasy to a Frugally 'Installed' Puppy, properly managed.
By design, a Frugal Puppy Linux does not employ a Unitary system. It's operating system consist of compressed, Read-Only files: initrd, vmlinuz, Puppy_version_number.sfs, and any of the following compressed, Read-Only files: zdrv_xxx.sfs, fdrv_xxx.sfs, adrv_xxx.sfs and ydrv_xxx.sfs. Perhaps you could add some other compressed, Read-only sfses with different first initials. The contents of these files are read into RAM as and when needed. Puppy's operating system exists only in RAM, and then only until Puppy is shut-down/rebooted. Whatever was is RAM is cleared on shut-down.
Viruses and other malware can not infect the aforementioned files. Or at least not without a significant and easily discovered and thwarted attempt. To write to them you have to decompress them and the modified file re-compressed and substituted for the original. The occurrence of that activity, if not obvious as having a significant impact on performance, could easily be identified by a simple monitor triggering a notice and perhaps requiring a user specified password --perhaps preserved in a compressed, write-once-read-only thereafter xdrv.sfs-- to continue.
Puppy's only 'Achilies' heel' is its SaveFile and SaveFolder. I'll leave it to others to figure out how to protect the 'decompressed/exposed' contents of a SaveFolder. But a SaveFile, while write-able, is compressed. The default Automatic Write every 30 minutes can be set to 'Never'. Preservation of necessary changes can be made immediately upon bootup and while not on the internet, with the exception of changes to applications that provide access to the internet. Changes to the latter could at least be made immediately upon bootup and before accessing potentially insecure websites.
If Spectre and Meltdown remain a 'theoretical threat' to other operating systems, they are pretty much a fantasy to a Frugally 'Installed' Puppy, properly managed.
My take-away, and the reason I posted the link, was that it's nice to know that even if a kernel has been compiled with S/M mitigations included, you can still turn some of them off via kernel line options at boot, if you would prefer not to take the performance hit.
Yes, Puppies are pretty safe. All the more reason to know about these kernel line option, so that you can say, "No thanks on the mitigations--I prefer the speed."
Have I misunderstood the article?
Yes, Puppies are pretty safe. All the more reason to know about these kernel line option, so that you can say, "No thanks on the mitigations--I prefer the speed."
Have I misunderstood the article?
When I have chance I will try:
For example, since Linux Kernel 4.15, administrators can disable the kernel's built-in mitigations for the Spectre v2 vulnerability (CVE-2017-5715) with the "nospectre_v2" kernel command line parameter.
Since Linux Kernel 4.17, administrators can disable all mitigations for Spectre v4 (CVE-2018-3639) with the "nospec_store_bypass_disable" command line parameter.
Similarly, a way to disable mitigations for Spectre v1 (CVE-2017-5753) has been added in the Linux Kernel 4.19, with the addition of the "nospectre_v1" parameter.
These three parameters were added despite the kernel already featuring the "spectre_v2" and "spec_store_bypass_disable" options for months, parameters that let system administrators control the complexity level of the Spectre-class mitigations, options which also included an "off" mode.
LxPup = Puppy + LXDEMain version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64