Page 38 of 135

Porteus Kernel Builder

Posted: 22 May 2019, 20:53
by Rava
neko wrote:
22 May 2019, 19:23
64bit-kernel5.1.4.tar (90 M)
Is that one hardened against all issues that spectre-meltdown-checker.sh V0.41 tests against?

BTW, according to github.com/speed47/spectre-meltdown-checker you can always get the newest version like so:

Code: Select all

wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
The just chmod a+x spectre-meltdown-checker.sh and you are set.

Porteus Kernel Builder

Posted: 23 May 2019, 04:11
by neko
@Rava
I have tested the example build kernel 5.1.4 & 5.0.18 with the newest "spectre-meltdown-checker.sh" that was told to me.
The results are as followed.

==== kernel 5.1.4 ====
CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface: YES (Not affected)
* CPU supports the MD_CLEAR functionality: NO
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: NO
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)

[How to test]

Code: Select all

% wget -c https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
% chmod +x spectre-meltdown-checker.sh
% su
# cp APorteus-MULT_ja-v19.05.21-x86_64/boot/syslinux/vmlinuz /boot/
# modprobe configs
# uname -r
5.1.4-porteus
# ./spectre-meltdown-checker.sh -v --explain
Spectre and Meltdown mitigation detection tool v0.41

Checking for vulnerabilities on current system
Kernel is Linux 5.1.4-porteus #1 SMP PREEMPT Wed May 22 20:50:57 UTC 2019 x86_64
CPU is Intel(R) Celeron(R) N4100 CPU @ 1.10GHz
Will use kernel image /boot/vmlinuz
Will use kconfig /proc/config.gz (decompressed)
Will use no System.map file (accuracy might be reduced)
We're missing some kernel info (see -v), accuracy might be reduced
Kernel image is Linux version 5.1.4-porteus (root@porteus) (gcc version 8.3.0 (GCC)) #1 SMP PREEMPT Wed May 22 20:50:57 UTC 2019

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  YES 
    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  YES 
    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  YES 
    * CPU indicates STIBP capability:  YES  (Intel STIBP feature bit)
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability:  NO 
  * L1 data cache invalidation
    * FLUSH_CMD MSR is available:  NO 
    * CPU indicates L1D flush capability:  NO 
  * Microarchitecture Data Sampling
    * VERW instruction is available:  NO 
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  YES 
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  YES 
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO 
  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO):  NO 
  * CPU/Hypervisor indicates L1D flushing is not necessary on this system:  NO 
  * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA):  NO 
  * CPU explicitly indicates not being vulnerable to Microarchitectural Data Sampling (MDC_NO):  NO 
  * CPU supports Software Guard Extensions (SGX):  YES 
  * CPU microcode is known to cause stability problems:  NO  (model 0x7a family 0x6 stepping 0x1 ucode 0x22 cpuid 0x706a1)
  * CPU microcode is the latest known available version:  NO  (latest version is 0x2e dated 2019/01/02 according to builtin MCExtractor DB v110 - 2019/05/11)
* CPU vulnerability to the speculative execution attack variants
  * Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass):  YES 
  * Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection):  YES 
  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load):  YES 
  * Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read):  YES 
  * Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass):  YES 
  * Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault):  NO 
  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault):  NO 
  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault):  NO 
  * Vulnerable to CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)):  NO 
  * Vulnerable to CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)):  NO 
  * Vulnerable to CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)):  NO 
  * Vulnerable to CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)):  NO 

CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'
* Mitigated according to the /sys interface:  YES  (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec:  YES  (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO 
* Kernel has mask_nospec64 (arm64):  NO 
* Checking count of LFENCE instructions following a jump in kernel...  NO  (only 4 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface:  YES  (Mitigation: Enhanced IBRS, IBPB: conditional, RSB filling)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES  (found IBRS in sysfs)
    * IBRS enabled and active:  YES 
  * Kernel is compiled with IBPB support:  YES  (IBPB found enabled in sysfs)
    * IBPB enabled and active:  YES 
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO 
  * Kernel compiled with retpoline option:  YES 
    * Local gcc is retpoline-aware:  YES 
  * Kernel supports RSB filling:  YES 
> STATUS:  NOT VULNERABLE  (IBRS + IBPB are mitigating the vulnerability)

CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'
* Mitigated according to the /sys interface:  YES  (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI):  YES  (found 'CONFIG_PAGE_TABLE_ISOLATION=y')
  * PTI enabled and active:  YES 
  * Reduced performance impact of PTI:  NO  (PCID/INVPCID not supported, performance impact of PTI will be significant)
* Running as a Xen PV DomU:  NO 
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability:  NO 
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this vulnerability)

> How to fix: The microcode of your CPU needs to be upgraded to mitigate this vulnerability. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). The microcode update is enough, there is no additional OS, kernel or software change needed.

CVE-2018-3639 aka 'Variant 4, speculative store bypass'
* Mitigated according to the /sys interface:  NO  (Vulnerable)
* Kernel supports disabling speculative store bypass (SSB):  YES  (found in /proc/self/status)
* SSB mitigation is enabled and active:  NO 
> STATUS:  VULNERABLE  (Your CPU doesn't support SSBD)

> How to fix: Your kernel is recent enough to use the CPU microcode features for mitigation, but your CPU microcode doesn't actually provide the necessary features for the kernel to use. The microcode of your CPU hence needs to be upgraded. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section).

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'
* Mitigated according to the /sys interface:  YES  (Not affected)
* Kernel supports PTE inversion:  YES  (found in kernel image)
* PTE inversion enabled and active:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface: 
* This system is a host running a hypervisor:  NO 
* Mitigation 1 (KVM)
  * EPT is disabled:  NO 
* Mitigation 2
  * L1D flush is supported by kernel:  YES  (found flush_l1d in kernel image)
  * L1D flush enabled:  UNKNOWN  (unrecognized mode)
  * Hardware-backed L1D flush supported:  NO  (flush will be done in software, this is slower)
  * Hyper-Threading (SMT) is enabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* CPU supports the MD_CLEAR functionality:  NO 
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* CPU supports the MD_CLEAR functionality:  NO 
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* CPU supports the MD_CLEAR functionality:  NO 
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* CPU supports the MD_CLEAR functionality:  NO 
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:KO CVE-2018-3639:KO CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK

We're missing some kernel info (see -v), accuracy might be reduced
A false sense of security is worse than no security at all, see --disclaimer
#
==== kernel 5.0.18 ====
CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface: YES (Not affected)
* CPU supports the MD_CLEAR functionality: NO
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: NO
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)

[How to test]

Code: Select all

% wget -c https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
% chmod +x spectre-meltdown-checker.sh
% su
# cp APorteus-MULT_ja-v19.05.21-x86_64/boot/syslinux/vmlinuz /boot/
# modprobe configs
# uname -r
5.0.18-porteus
# ./spectre-meltdown-checker.sh -v --explain
Spectre and Meltdown mitigation detection tool v0.41

Checking for vulnerabilities on current system
Kernel is Linux 5.0.18-porteus #1 SMP PREEMPT Wed May 22 23:01:26 UTC 2019 x86_64
CPU is Intel(R) Celeron(R) N4100 CPU @ 1.10GHz
Will use kernel image /boot/vmlinuz
Will use kconfig /proc/config.gz (decompressed)
Will use no System.map file (accuracy might be reduced)
We're missing some kernel info (see -v), accuracy might be reduced
Kernel image is Linux version 5.0.18-porteus (root@porteus) (gcc version 8.3.0 (GCC)) #1 SMP PREEMPT Wed May 22 23:01:26 UTC 2019

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  YES 
    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  YES 
    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  YES 
    * CPU indicates STIBP capability:  YES  (Intel STIBP feature bit)
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability:  NO 
  * L1 data cache invalidation
    * FLUSH_CMD MSR is available:  NO 
    * CPU indicates L1D flush capability:  NO 
  * Microarchitecture Data Sampling
    * VERW instruction is available:  NO 
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  YES 
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  YES 
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO 
  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO):  NO 
  * CPU/Hypervisor indicates L1D flushing is not necessary on this system:  NO 
  * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA):  NO 
  * CPU explicitly indicates not being vulnerable to Microarchitectural Data Sampling (MDC_NO):  NO 
  * CPU supports Software Guard Extensions (SGX):  YES 
  * CPU microcode is known to cause stability problems:  NO  (model 0x7a family 0x6 stepping 0x1 ucode 0x22 cpuid 0x706a1)
  * CPU microcode is the latest known available version:  NO  (latest version is 0x2e dated 2019/01/02 according to builtin MCExtractor DB v110 - 2019/05/11)
* CPU vulnerability to the speculative execution attack variants
  * Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass):  YES 
  * Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection):  YES 
  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load):  YES 
  * Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read):  YES 
  * Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass):  YES 
  * Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault):  NO 
  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault):  NO 
  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault):  NO 
  * Vulnerable to CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)):  NO 
  * Vulnerable to CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)):  NO 
  * Vulnerable to CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)):  NO 
  * Vulnerable to CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)):  NO 

CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'
* Mitigated according to the /sys interface:  YES  (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec:  YES  (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO 
* Kernel has mask_nospec64 (arm64):  NO 
* Checking count of LFENCE instructions following a jump in kernel...  NO  (only 4 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface:  YES  (Mitigation: Enhanced IBRS, IBPB: conditional, RSB filling)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES  (found IBRS in sysfs)
    * IBRS enabled and active:  YES 
  * Kernel is compiled with IBPB support:  YES  (IBPB found enabled in sysfs)
    * IBPB enabled and active:  YES 
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO 
  * Kernel compiled with retpoline option:  YES 
    * Local gcc is retpoline-aware:  YES 
  * Kernel supports RSB filling:  YES 
> STATUS:  NOT VULNERABLE  (IBRS + IBPB are mitigating the vulnerability)

CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'
* Mitigated according to the /sys interface:  YES  (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI):  YES  (found 'CONFIG_PAGE_TABLE_ISOLATION=y')
  * PTI enabled and active:  YES 
  * Reduced performance impact of PTI:  NO  (PCID/INVPCID not supported, performance impact of PTI will be significant)
* Running as a Xen PV DomU:  NO 
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability:  NO 
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this vulnerability)

> How to fix: The microcode of your CPU needs to be upgraded to mitigate this vulnerability. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). The microcode update is enough, there is no additional OS, kernel or software change needed.

CVE-2018-3639 aka 'Variant 4, speculative store bypass'
* Mitigated according to the /sys interface:  NO  (Vulnerable)
* Kernel supports disabling speculative store bypass (SSB):  YES  (found in /proc/self/status)
* SSB mitigation is enabled and active:  NO 
> STATUS:  VULNERABLE  (Your CPU doesn't support SSBD)

> How to fix: Your kernel is recent enough to use the CPU microcode features for mitigation, but your CPU microcode doesn't actually provide the necessary features for the kernel to use. The microcode of your CPU hence needs to be upgraded. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section).

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'
* Mitigated according to the /sys interface:  YES  (Not affected)
* Kernel supports PTE inversion:  YES  (found in kernel image)
* PTE inversion enabled and active:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface: 
* This system is a host running a hypervisor:  NO 
* Mitigation 1 (KVM)
  * EPT is disabled:  NO 
* Mitigation 2
  * L1D flush is supported by kernel:  YES  (found flush_l1d in kernel image)
  * L1D flush enabled:  UNKNOWN  (unrecognized mode)
  * Hardware-backed L1D flush supported:  NO  (flush will be done in software, this is slower)
  * Hyper-Threading (SMT) is enabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* CPU supports the MD_CLEAR functionality:  NO 
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* CPU supports the MD_CLEAR functionality:  NO 
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* CPU supports the MD_CLEAR functionality:  NO 
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* CPU supports the MD_CLEAR functionality:  NO 
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:KO CVE-2018-3639:KO CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK

We're missing some kernel info (see -v), accuracy might be reduced
A false sense of security is worse than no security at all, see --disclaimer
#

Thanks.

Porteus Kernel Builder

Posted: 23 May 2019, 04:50
by Rava
neko wrote:
23 May 2019, 04:11

Code: Select all

We're missing some kernel info (see -v), accuracy might be reduced
I fogot to ask earlier, but what remains the reason your run of spectre-meltdown-checker.sh still produces that error?

You as our kernel guru, when you are not able to get his error to vanish, then who is?
Cause
neko wrote:
23 May 2019, 04:11
A false sense of security is worse than no security at all, see --disclaimer
is not just some clever words but quite true when it comes to IT security. Unfortunately.

Porteus Kernel Builder

Posted: 23 May 2019, 17:56
by raja
^^
Missing some kernel info....
Fully installed Linux OS will have boot folder in root, containing vmlinuz, initrd,system.map,kconfig,config etc files. Spectre script probably uses those files to dig deeper and present report. (see an Ubuntu install)

Porteus does not.

vulnerable part for mine:

Code: Select all

CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* CPU supports the MD_CLEAR functionality:  YES 
* Kernel supports using MD_CLEAR mitigation:  UNKNOWN 
> STATUS:  VULNERABLE  (Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* CPU supports the MD_CLEAR functionality:  YES 
* Kernel supports using MD_CLEAR mitigation:  UNKNOWN 
> STATUS:  VULNERABLE  (Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* CPU supports the MD_CLEAR functionality:  YES 
* Kernel supports using MD_CLEAR mitigation:  UNKNOWN 
> STATUS:  VULNERABLE  (Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* CPU supports the MD_CLEAR functionality:  YES 
* Kernel supports using MD_CLEAR mitigation:  UNKNOWN 
> STATUS:  VULNERABLE  (Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability)
neko, please note:
Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability

Porteus Kernel Builder

Posted: 23 May 2019, 20:20
by Rava
raja wrote:
23 May 2019, 17:56
Fully installed Linux OS will have boot folder in root, containing vmlinuz, initrd,system.map,kconfig,config etc files. Spectre script probably uses those files to dig deeper and present report. (see an Ubuntu install)
[...]
Porteus does not.
neko, please note:
Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability
I suggest PM should have, for all future versions, all needed for kernel hardening as either additional kernel module, or as 2nd large all-include module,
In my book the 2nd version is not really needed, it is easy enough done for someone to merge both modules together.

But maybe still for the very few stable version we should get 2 variants of the kernel module, one with the added info files for the scanner, and the standard one like before, but all hardened.
On the other hand, by another approach me thinks it is not needed. One can load the system with the added kernel info module just fine, to the checks with spectre-meltdown-checker.sh .
And after checking and seeing all is fine, there would be no need to have that module loaded every time. When there a new threats that spectre-meltdown-checker.sh might cover in the future, or maybe new variants of known threats, then one can load the extra kernel info and do the tango spectre-meltdown-checker.sh dancing once again.
And when there are issues, users should and we maintainers should look into solutions for getting the kernel safe again.

And then after all is safe, one again not needs the extra mini kernel module.

What are your thoughts on that?
___________________________

Especially for neko's versions I think its better he just added a small mini module for the hardening info for each kernel.

Hopefully that's feasible and not too much work, but Porteus should keep up with the security issues and at least provide all is needed to have a hardening done, and to have each user do the testing by her/himself so that everyone can see what the scanner tells him/her..

Porteus Kernel Builder

Posted: 24 May 2019, 01:15
by neko
@Rava
Kernel 5.2-rc1 was rebuilt with the config that was set to CONFIG_KALLSYMS=y.
I have tested this kernel with the newest "spectre-meltdown-checker.sh" that was told to me.
The results are as followed.

(1)The warnings were deleted.
-------------------
.
.
Will use no System.map file (accuracy might be reduced)
We're missing some kernel info (see -v), accuracy might be reduced
.
.
We're missing some kernel info (see -v), accuracy might be reduced
A false sense of security is worse than no security at all, see --disclaimer
-------------------

(2)ZombieLoad
CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface: YES (Not affected)
* CPU supports the MD_CLEAR functionality: NO
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: NO
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)

[How to test]

Code: Select all

% wget -c https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
% chmod +x spectre-meltdown-checker.sh
% su
# ls /proc/kallsyms
/proc/kallsyms
# cp UP.APorteus-MULT_ja-v19.05.21-x86_64/boot/syslinux/vmlinuz /boot/
# modprobe configs
# ls /proc/config.gz
/proc/config.gz
# uname -r
5.2.0-rc1-porteus
# ./spectre-meltdown-checker.sh -v --explain
Spectre and Meltdown mitigation detection tool v0.41

Checking for vulnerabilities on current system
Kernel is Linux 5.2.0-rc1-porteus #1 SMP PREEMPT Fri May 24 00:12:31 UTC 2019 x86_64
CPU is Intel(R) Celeron(R) N4100 CPU @ 1.10GHz
Will use kernel image /boot/vmlinuz
Will use kconfig /proc/config.gz (decompressed)
Will use System.map file /proc/kallsyms
Kernel image is Linux version 5.2.0-rc1-porteus (root@porteus) (gcc version 8.3.0 (GCC)) #1 SMP PREEMPT Fri May 24 00:12:31 UTC 2019

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  YES 
    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  YES 
    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  YES 
    * CPU indicates STIBP capability:  YES  (Intel STIBP feature bit)
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability:  NO 
  * L1 data cache invalidation
    * FLUSH_CMD MSR is available:  NO 
    * CPU indicates L1D flush capability:  NO 
  * Microarchitecture Data Sampling
    * VERW instruction is available:  NO 
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  YES 
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  YES 
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO 
  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO):  NO 
  * CPU/Hypervisor indicates L1D flushing is not necessary on this system:  NO 
  * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA):  NO 
  * CPU explicitly indicates not being vulnerable to Microarchitectural Data Sampling (MDC_NO):  NO 
  * CPU supports Software Guard Extensions (SGX):  YES 
  * CPU microcode is known to cause stability problems:  NO  (model 0x7a family 0x6 stepping 0x1 ucode 0x22 cpuid 0x706a1)
  * CPU microcode is the latest known available version:  NO  (latest version is 0x2e dated 2019/01/02 according to builtin MCExtractor DB v110 - 2019/05/11)
* CPU vulnerability to the speculative execution attack variants
  * Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass):  YES 
  * Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection):  YES 
  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load):  YES 
  * Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read):  YES 
  * Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass):  YES 
  * Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault):  NO 
  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault):  NO 
  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault):  NO 
  * Vulnerable to CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)):  NO 
  * Vulnerable to CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)):  NO 
  * Vulnerable to CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)):  NO 
  * Vulnerable to CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)):  NO 

CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'
* Mitigated according to the /sys interface:  YES  (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec:  YES  (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO 
* Kernel has mask_nospec64 (arm64):  NO 
* Checking count of LFENCE instructions following a jump in kernel...  NO  (only 4 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface:  YES  (Mitigation: Enhanced IBRS, IBPB: conditional, RSB filling)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES  (found IBRS in sysfs)
    * IBRS enabled and active:  YES 
  * Kernel is compiled with IBPB support:  YES  (IBPB found enabled in sysfs)
    * IBPB enabled and active:  YES 
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO 
  * Kernel compiled with retpoline option:  YES 
    * Local gcc is retpoline-aware:  YES 
  * Kernel supports RSB filling:  YES 
> STATUS:  NOT VULNERABLE  (IBRS + IBPB are mitigating the vulnerability)

CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'
* Mitigated according to the /sys interface:  YES  (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI):  YES  (found 'CONFIG_PAGE_TABLE_ISOLATION=y')
  * PTI enabled and active:  YES 
  * Reduced performance impact of PTI:  NO  (PCID/INVPCID not supported, performance impact of PTI will be significant)
* Running as a Xen PV DomU:  NO 
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability:  NO 
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this vulnerability)

> How to fix: The microcode of your CPU needs to be upgraded to mitigate this vulnerability. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). The microcode update is enough, there is no additional OS, kernel or software change needed.

CVE-2018-3639 aka 'Variant 4, speculative store bypass'
* Mitigated according to the /sys interface:  NO  (Vulnerable)
* Kernel supports disabling speculative store bypass (SSB):  YES  (found in /proc/self/status)
* SSB mitigation is enabled and active:  NO 
> STATUS:  VULNERABLE  (Your CPU doesn't support SSBD)

> How to fix: Your kernel is recent enough to use the CPU microcode features for mitigation, but your CPU microcode doesn't actually provide the necessary features for the kernel to use. The microcode of your CPU hence needs to be upgraded. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section).

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'
* Mitigated according to the /sys interface:  YES  (Not affected)
* Kernel supports PTE inversion:  YES  (found in kernel image)
* PTE inversion enabled and active:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface: 
* This system is a host running a hypervisor:  NO 
* Mitigation 1 (KVM)
  * EPT is disabled:  NO 
* Mitigation 2
  * L1D flush is supported by kernel:  YES  (found flush_l1d in kernel image)
  * L1D flush enabled:  UNKNOWN  (unrecognized mode)
  * Hardware-backed L1D flush supported:  NO  (flush will be done in software, this is slower)
  * Hyper-Threading (SMT) is enabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* CPU supports the MD_CLEAR functionality:  NO 
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* CPU supports the MD_CLEAR functionality:  NO 
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* CPU supports the MD_CLEAR functionality:  NO 
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* CPU supports the MD_CLEAR functionality:  NO 
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:KO CVE-2018-3639:KO CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK

A false sense of security is worse than no security at all, see --disclaimer
#

P.S.
I am just an operator.

-----------------------------------------------------------------------
@raja
I am afraid of updating microcode.
If it has some issues, PC will be a stone.


Thanks.

Porteus Kernel Builder

Posted: 24 May 2019, 01:31
by Rava
neko wrote:
24 May 2019, 01:15
I am just an operator.
You are one of our kernel gurus, that is way more than "just an operator". the kernel is the heart and core of every OS, the most crucial part even when most users might not even get for what its even there ince they cannot seemingly start it up like they can start SM-Office Word. LOL.
_____________________________________

Anyhow, what are your thoughts of giving a small kernel add-on module that provides the needed files for "spectre-meltdown-checker.sh" to run without issues?

I think my idea of only giving it as small additional module makes more sense that having a standard kernel module and also a large kernel module with the added info files - since usually users only need such extra files when they want to test the vulnerability of the kernel with "spectre-meltdown-checker.sh" by themselves - or maybe test with other scanners or methods.

When it is obvious that the kernel is secured, the extra kernel-info module is no longer needed for day-to-day Porteus booting and using of our OS.

And when the kernel in question has a vulnerability - e.g. against a new variant of a known vulnerability, or when a newer "spectre-meltdown-checker.sh" is able to check again yet another utter failure by IBM CPU security leak, then we best need an updated kernel anyway.
neko wrote:
24 May 2019, 01:15
@raja
I am afraid of updating microcode.
If it has some issues, PC will be a stone.
Same could be said about updating the BIOS. Still the PC is not stone, you could change the BIOS chip against another one, and you could also exchange the CPU - against one that fits your motherboard and pocket money of course. :D

I did update quite some BIOS chips in my years, and sure always did hope we in my local area not get a power failure at that very wrong moment of BIOS flashing, but I never had issues and all flashing went well.

I never did any CPU updating microcode, though. :)
I would read on stackoverflow about that (and other sites a duckduckgo would give me) and maybe even ask own question or questions on stackoverflow and then decide. :)

Porteus Kernel Builder

Posted: 24 May 2019, 17:05
by raja

Code: Select all

[    0.000000] microcode: microcode updated early to revision 0xb4, date = 2019-04-01
[    0.000000] Linux version 5.0.3-porteus (root@porteus) (gcc version 8.2.1 20181127 (GCC)) #1 SMP PREEMPT Tue Mar 19 20:13:37
Intel suggests my processor(Kabylake) needs new microcode. Done. No problems.

I shall replace my kernel when you release v5.2 with CONFIG_KALLSYMS=y

Porteus Kernel Builder

Posted: 24 May 2019, 18:13
by Rava
raja wrote:
24 May 2019, 17:05
Intel suggests my processor(Kabylake) needs new microcode. Done. No problems.
I presume it works similar to BIOS flashing?

Porteus Kernel Builder

Posted: 25 May 2019, 16:51
by raja
BIOS Flashing is a permanent procedure, microcode overwritten in the chip on Motherboard.

Loading new Microcode as an image file before initrd, during boot is a temporary affair, executed by the kernel every boot. Remove the image file from boot order, you go back to original old code.

Porteus Kernel Builder

Posted: 26 May 2019, 11:19
by neko
1. "Porteus Kernel Builder" was updated to mkKernel-19.05.26-noarch-1.xzm
Please refer to Porteus Kernel Builder (Post by neko #52232)

mkKernel-19.05.26-noarch-1.xzm (5.3 M)
http://simosnet.com/livecd/isobuilder/k ... arch-1.xzm
md5sum: 8e43570be5d119ee570826b7fe102840 mkKernel-19.05.26-noarch-1.xzm

=== AUFS patch applying process was changed from all applying to only core patch applying. ===
(1) all applying (OLD: example 5.2-rc)
Create all patch. (aufs.patch)
/usr/local/share/mkKernel/lib/v5.2-rc/full.get.aufs.patch

Code: Select all

#!/bin/sh

mkdir auf
cd auf

git clone https://github.com/sfjro/aufs5-standalone.git aufs5-standalone.git
cd aufs5-standalone.git
if ! ( git checkout origin/aufs5.2 )
then
	echo "get aufs5.x-rcN"
	git checkout origin/aufs5.x-rcN
fi

mkdir ../a ../b
cp -r {Documentation,fs,include} ../b
rm ../b/include/uapi/linux/Kbuild 2>/dev/null || rm ../b/include/linux/Kbuild
cd ..
diff -rupN a/ b/ > ../aufs.patch

cat aufs5-standalone.git/*.patch >> ../aufs.patch

cd ../
rm -r auf
Then apply aufs.patch to source files.

(2) core patch applying (NEW: example 5.2-rc)
Get "AUFS-git"
/usr/local/share/mkKernel/lib/v5.2-rc/get.aufs.patch

Code: Select all

#!/bin/sh

mkdir auf
cd auf

git clone https://github.com/sfjro/aufs5-standalone.git aufs5-standalone.git
cd aufs5-standalone.git
if ! ( git checkout origin/aufs5.2 )
then
	echo "get aufs5.x-rcN"
	git checkout origin/aufs5.x-rcN
fi
Then apply core patches to source files.
/usr/local/share/mkKernel/lib/v5.2-rc/ownPatch.sh

Code: Select all

PATCHDIR=../../auf/aufs5-standalone.git

# [auf/aufs5-standalone.git/README]
#- copy ./{Documentation,fs,include/uapi/linux/aufs_type.h} files to your
#  kernel source tree. Never copy $PWD/include/uapi/linux/Kbuild.
cp -r "$PATCHDIR"/fs ./
cp -r "$PATCHDIR"/Documentation ./
cp "$PATCHDIR"/include/uapi/linux/aufs_type.h ./include/uapi/linux
#- apply ./aufs5-kbuild.patch to your kernel source files.
echo '-------------------aufs5-kbuild'
cat "$PATCHDIR"/aufs5-kbuild.patch | patch -p1
#- apply ./aufs5-base.patch too.
echo '-------------------aufs5-base'
cat "$PATCHDIR"/aufs5-base.patch | patch -p1
#- apply ./aufs5-mmap.patch too.
echo '-------------------aufs5-mmap'
cat "$PATCHDIR"/aufs5-mmap.patch | patch -p1
#- apply ./aufs5-standalone.patch too, if you have a plan to set
#  CONFIG_AUFS_FS=m. otherwise you don't need ./aufs5-standalone.patch.
#
# % grep CONFIG_AUFS_FS v5.2-rc/*.config
#v5.2-rc/32bit.config:CONFIG_AUFS_FS=y
#v5.2-rc/64bit.config:CONFIG_AUFS_FS=y
#
#- enable CONFIG_AUFS_FS, you can select either
#  =m or =y.

#There several other patches in aufs5-standalone.git. They are all
#optional. When you meet some problems, they will help you.

#- aufs5-loopback.patch
#  Supports a nested loopback mount in a branch-fs. This patch is
#  unnecessary until aufs produces a message like "you may want to try
#  another patch for loopback file".

#- vfs-ino.patch
#  Modifies a system global kernel internal function get_next_ino() in
#  order to stop assigning 0 for an inode-number. Not directly related to
#  aufs, but recommended generally.

#- tmpfs-idr.patch
#  Keeps the tmpfs inode number as the lowest value. Effective to reduce
#  the size of aufs XINO files for tmpfs branch. Also it prevents the
#  duplication of inode number, which is important for backup tools and
#  other utilities. When you find aufs XINO files for tmpfs branch
#  growing too much, try this patch.

#- lockdep-debug.patch
#  Because aufs is not only an ordinary filesystem (callee of VFS), but
#  also a caller of VFS functions for branch filesystems, subclassing of
#  the internal locks for LOCKDEP is necessary. LOCKDEP is a debugging
#  feature of linux kernel. If you enable CONFIG_LOCKDEP, then you will
#  need to apply this debug patch to expand several constant values.
#  If don't know what LOCKDEP, then you don't have apply this patch.
For each kernel version 3.18, 4.14, 4.19, 4.4, 4.9, 5.0, 5.1, 5.2-rc,
this change was done.

Note 1: For kernel version 5.2-rc line, after AUFS patch applying, owen patch is applied.

Code: Select all

for SRC in fs+aufs+hfsnotify.c
do
src=`echo $SRC|tr '+' '/'`
#====<loop>====#
if [ ! -f $KDIR/v$KVER/$COMPARCH/linux-${KVER}/${src} ]
then
	echo "There is not $src"
	exit 1
fi
if [ ! -f /usr/local/share/mkKernel/lib/v${V3_4}.${SUB}/auf.patch.${SRC} ]
then
	echo "There is not Own Patch."
	exit 1
fi
DIFF=`diff $KDIR/v$KVER/$COMPARCH/linux-${KVER}/${src} /usr/local/share/mkKernel/lib/v${V3_4}.${SUB}/auf.patch.${SRC}`
if [ -n "$DIFF" ]
then
	echo "Own Patch is mismatch !!"
	exit 1
fi

cp /usr/local/share/mkKernel/lib/v${V3_4}.${SUB}/own.patch.${SRC} $KDIR/v$KVER/$COMPARCH/linux-${KVER}/${src}
#====<loop>====#
done
exit 0
Note 2:
This core patches applying is introduced by @Kriss's help.
@Kriss! Thank you very much.


2. current kernel version
[from https://www.kernel.org/finger_banner]
The latest stable version of the Linux kernel is: 5.1.5
The latest mainline version of the Linux kernel is: 5.2-rc1
The latest stable 5.1 version of the Linux kernel is: 5.1.5 <---NEW
The latest stable 5.0 version of the Linux kernel is: 5.0.19 <---NEW
The latest longterm 4.19 version of the Linux kernel is: 4.19.46 <---NEW
The latest longterm 4.14 version of the Linux kernel is: 4.14.122 <---NEW
The latest longterm 4.9 version of the Linux kernel is: 4.9.179 <---NEW
The latest longterm 4.4 version of the Linux kernel is: 4.4.180
The latest longterm 3.18 version of the Linux kernel is: 3.18.140 (EOL)
The latest linux-next version of the Linux kernel is: next-20190524


3. NEW Example of updated kernel that was built by "Porteus Kernel builder" was updated.

"copy firmwares from firmware packages" function was used when build kernel.


=== Simple package (vmlinuz, 000-kernel.xzm, 06-crippled_sources-NNN-XXbit.xzm) ===
[5.1.5]
32bit-kernel5.1.5.tar (85 M)
http://www.mediafire.com/file/ca4qtqt3o ... l5.1.5.tar
md5sum: 682ccded8144fe8f2544bc99ee39dd12 32bit-kernel5.1.5.tar

64bit-kernel5.1.5.tar (90 M)
http://www.mediafire.com/file/cl07i2ctw ... l5.1.5.tar
md5sum: db8cf1cb50321cbd641d43f6781375ed 64bit-kernel5.1.5.tar

[5.0.19]
32bit-kernel5.0.19.tar (87 M)
http://www.mediafire.com/file/2a3k3p28t ... 5.0.19.tar
md5sum: 0b0b6a1858685bc319d1f4ac5ca8a6a7 32bit-kernel5.0.19.tar

64bit-kernel5.0.19.tar (92 M)
http://www.mediafire.com/file/nu2c3ns6c ... 5.0.19.tar
md5sum: 500e01fb96a9739cb56d032e04b77f43 64bit-kernel5.0.19.tar


Note 1: Compiler
Compiled by gcc-8.3.0-x86_64-1

Note 2: AUFS patch
Kernel 5.1.5 was patched with AUFS_VERSION AUFS_VERSION "5.1-20190520".
Kernel 5.0.19 was patched with AUFS_VERSION AUFS_VERSION "5.0-20190311".


Thanks.

Porteus Kernel Builder

Posted: 27 May 2019, 08:48
by neko
1. current kernel version
[from https://www.kernel.org/finger_banner]
The latest stable version of the Linux kernel is: 5.1.5
The latest mainline version of the Linux kernel is: 5.2-rc2 <---NEW
The latest stable 5.1 version of the Linux kernel is: 5.1.5
The latest stable 5.0 version of the Linux kernel is: 5.0.19
The latest longterm 4.19 version of the Linux kernel is: 4.19.46
The latest longterm 4.14 version of the Linux kernel is: 4.14.122
The latest longterm 4.9 version of the Linux kernel is: 4.9.179
The latest longterm 4.4 version of the Linux kernel is: 4.4.180
The latest longterm 3.18 version of the Linux kernel is: 3.18.140 (EOL)
The latest linux-next version of the Linux kernel is: next-20190524


2. NEW Example of updated kernel that was built by "Porteus Kernel builder" was updated.

"copy firmwares from firmware packages" function was used when build kernel.


=== Simple package (vmlinuz, 000-kernel.xzm, 06-crippled_sources-NNN-XXbit.xzm) ===
[5.2-rc2]
32bit-kernel5.2-rc2.tar (85 M)
http://www.mediafire.com/file/ot94dt584 ... .2-rc2.tar
md5sum: 953a67ecbb6bedd53341a5419e40d731 32bit-kernel5.2-rc2.tar

64bit-kernel5.2-rc2.tar (90 M)
http://www.mediafire.com/file/40dg11dp7 ... .2-rc2.tar
md5sum: 3d7ad3576c9267625bd03f076e1553c9 64bit-kernel5.2-rc2.tar


Note 1: Compiler
Compiled by gcc-8.3.0-x86_64-1

Note 2: AUFS patch
Kernel 5.2-rc2 was patched with AUFS_VERSION "5.x-rcN-20190520".


Thanks.

Porteus Kernel Builder

Posted: 28 May 2019, 04:37
by AcnapyxoB
Is it necessary to boot with intel-ucode.cpio or new kernels are patched vs Intel vulnerabilities?

Porteus Kernel Builder

Posted: 01 Jun 2019, 03:19
by neko
1. "Porteus Kernel Builder" was updated to mkKernel-19.05.31-noarch-1.xzm
Please refer to Porteus Kernel Builder (Post by neko #52232)

mkKernel-19.05.31-noarch-1.xzm (5.3 M)
http://simosnet.com/livecd/isobuilder/k ... arch-1.xzm
md5sum: 910bea60292fab4e00661b9a09e75a83 mkKernel-19.05.31-noarch-1.xzm

==== Firmware database was updated by the following archlinux packages ====
alsa-firmware-1.0.29-noarch-2
ipw2100-fw-1.3-noarch-9
ipw2200-fw-3.1-noarch-7
linux-atm-2.5.2-x86_64-5
linux-firmware-20190514.711d329-noarch-1 <---NEW
wireless-regdb-2019.03.01-noarch-1 <---NEW


2. current kernel version
[from https://www.kernel.org/finger_banner]
The latest stable version of the Linux kernel is: 5.1.6
The latest mainline version of the Linux kernel is: 5.2-rc2
The latest stable 5.1 version of the Linux kernel is: 5.1.6 <---NEW
The latest stable 5.0 version of the Linux kernel is: 5.0.20 <---NEW
The latest longterm 4.19 version of the Linux kernel is: 4.19.47 <---NEW
The latest longterm 4.14 version of the Linux kernel is: 4.14.123 <---NEW
The latest longterm 4.9 version of the Linux kernel is: 4.9.180 <---NEW
The latest longterm 4.4 version of the Linux kernel is: 4.4.180
The latest longterm 3.18 version of the Linux kernel is: 3.18.140 (EOL)
The latest linux-next version of the Linux kernel is: next-20190531


3. NEW Example of updated kernel that was built by "Porteus Kernel builder" was updated.

"copy firmwares from firmware packages" function was used when build kernel.


=== Simple package (vmlinuz, 000-kernel.xzm, 06-crippled_sources-NNN-XXbit.xzm) ===
[5.1.6]
32bit-kernel5.1.6.tar (87 M)
http://www.mediafire.com/file/qn257m7z1 ... l5.1.6.tar
md5sum: ed5824e8fbc2f0ed971ff54ea82aeb22 32bit-kernel5.1.6.tar

64bit-kernel5.1.6.tar (92 M)
http://www.mediafire.com/file/rr7or4hja ... l5.1.6.tar
md5sum: 78d072c388c0112acc80d99678148ec1 64bit-kernel5.1.6.tar

[5.0.20]
32bit-kernel5.0.20.tar (87 M)
http://www.mediafire.com/file/baes0fss7 ... 5.0.20.tar
md5sum: e422ff12b5b5d43cbebc5eb22a5cfcea 32bit-kernel5.0.20.tar

64bit-kernel5.0.20.tar (92 M)
http://www.mediafire.com/file/o96cp1w2p ... 5.0.20.tar
md5sum: 4abc2968e0ebb51c5bb4a087f044c94e 64bit-kernel5.0.20.tar


Note 1: Compiler
Compiled by gcc-8.3.0-x86_64-1

Note 2: AUFS patch
Kernel 5.1.6 was patched with AUFS_VERSION AUFS_VERSION "5.1-20190520".
Kernel 5.0.20 was patched with AUFS_VERSION AUFS_VERSION "5.0-20190311".


----------------------------------------------------------------------------------
@AcnapyxoB
I apologize for the late answer.
I am not familiar with CPU microcode updates.
Microcode updates should occur at boot time.
I think that the corresponding process is included in Porteus initrd.xz.
Please ask at Newbie questions


Thanks.

Porteus Kernel Builder

Posted: 01 Jun 2019, 04:56
by AcnapyxoB
Thanks @neko