Full technical blog article:
WIP documentation:
Personally I donāt trust coreboot/libreboot/dasharo because their firmware policy accept some proprietary blobs, for this reason the only viable project is gnu-boot which donāt accept like Linux-libre any proprietary blob/firmware.
Sure, as long as you have no critical deadlines dependent on its eventual releases.
Me too. This is why i hate Linux and OpenSource.
Finally I start my project to replace the non-safe modern pc with less-modern but more-secure and viable Amd Opteron, I have ordered the motherboard Asus-kgpe d16 (I hope they donāt send a wrong motherboard 
)
Next will be the case, any opinion about this one?
Meanwhile Iām still searching for good passive cooler
This seemās good. Consider actually Iām using passive cooler on AMD Ryzen 3 3100 4-Core Processor. The temp are 60-64Ā° under no stress and 80-85Ā° under heavy stress (over 400% of cpu used) in those years never shutdown pc for overeating and never had problems. I donāt know about Opteron because is the first time I use it, is more "sensible to heatā than Ryzen?
This site report is ok for 140w cpu, so opteron 6200 series are good for this, I hope.
On Amazon I read one user report has 30Ā° cpu (seems really low!) using this cooler
Another question and is the most important: for anyone who has opteron cpu.
What report
lscpu
and
I donāt want to spent money and use a bugged hw cpu.
Atm some old cpu are not safe
Intel core duo (has a lot of hardware bug, most of them not fixed, cause Intel release updated microcode only for new unsafe and not cheap cpus)
Ppc power5 (has a lot of hardware bug, most of them not fixed)
Some old cpu are safe
Amd turion (very old and slow, no bugs!) 
AMD A10-5800K (lscpu report āsmt vulnerableā, spectre-meltdown-checker report all green)
Opteron 6380 (lscpu report āsmt vulnerableā, I wait someone report output of spectre-meltdown checker )
Opteron 62** ?? (to be tested, meanwhile I wait someone report output of spectre-meltdown checker)
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: AuthenticAMD
Model name: AMD Opteron(tm) Processor 6380
CPU family: 21
Model: 2
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
Stepping: 0
Frequency boost: enabled
CPU(s) scaling MHz: 56%
CPU max MHz: 2500,0000
CPU min MHz: 1400,0000
BogoMIPS: 5000,27
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse
2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid e
xtd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsav
e avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ib
s xop skinit wdt fma4 tce tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd ibpb vmmcall bm
i1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter p
fthreshold
Virtualization features:
Virtualization: AMD-V
Caches (sum of all):
L1d: 256 KiB (16 instances)
L1i: 512 KiB (8 instances)
L2: 16 MiB (8 instances)
L3: 12 MiB (2 instances)
NUMA:
NUMA node(s): 2
NUMA node0 CPU(s): 0-7
NUMA node1 CPU(s): 8-15
Vulnerabilities:
Gather data sampling: Not affected
Indirect target selection: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Reg file data sampling: Not affected
Retbleed: Mitigation; untrained return thunk; SMT vulnerable
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines; IBPB conditional; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected;
BHI Not affected
Srbds: Not affected
Tsa: Not affected
Tsx async abort: Not affected
Vmscape: Not affected
(executed on old 6.1 kernel, newer kernel may report more vulnerabilities)
The case will be too small. You need an E-ATX case (EAB SSI or something like that), not just plain ATX.
Thanks, the 6380 works with gnu-boot? Here I read
CPU compatibility
Use Opteron 6200 series (works without microcode updates, including hw virt). 6300 series needs microcode updates, so avoid those CPUs. 6100 series is too old, and mostly untested.
Thanks, searching āeab ssi caseā on google return me some political sites and European american
bank site. Probably was āssi-eebā?
I read āSMT vulnerableā this mean must disable smt to be protected
I heard this became the cpu more slow, but personally I have already used on old intel cpu and was acceptable
It depends on your threat model.
Almost all of the CPU side-channel leaks are only a problem if you run untrusted code on your computer, and that is true even if the untrusted code is suitably sandboxed.
So at the low end of threat model, you need only be concerned about shared use scenarios such as
- a multi-user computer
- a VPS
and a personal use computer may well be acceptably safe. But see later.
An example risk scenario for shared use is that a cryptographic key or a password could be sniffed by a malicious but authorised process from the running code of another unrelated process.
At the high end of threat model, yes, you would need to disable all CPU features that are capable of side-channel leaks.
For a personal use computer, the biggest risk scenario is probably Javascript running in a web browser. So it may be necessary to use a Javascript engine that includes mitigations. You can reduce your own risk (theoretically) by visiting only web sites that a) you trust and b) which maintain their security properly i.e. have not been hacked.
Edit: PS
You can (very theoretically) mitigate SMT-related side-channel leaks by very careful scheduling.
For example, if you have a two core CPU chip and each core has two hyper-threads and the resulting four CPUs that are visible to the operating system are numbered (just as an example) 0 and 2 on the first core and 1 and 3 on the second core ā¦ then if you kept the malicious process to CPUs 1 and 3 while keeping all other processes to CPUs 0 and 2 ā¦ you should be safe from this one specific side-channel leak (at least as far as user-space is concerned).
However the hardware has to have enough resulting CPUs to be wasting CPUs like that. You wouldnāt usually want to do that with the example hardware in the previous paragraph. And this would require detailed knowledge and detailed control in order to set up.
I found this for lscpu output, but is too outdated
Second part bought
Amd opteron 6272
I hope was a good choice. Any opinion about it?
You would probably benefit from this resource:
Great, but I would prefer to use gnuboot, because coreboot (as Linux do) include the possibility of loading non-free firmware, meanwhile gnuboot is completely free. I still consider coreboot as an alternative to gnuboot or libreboot, personally I prefer this āpathā
a)try gnu-boot if all works without no problem, I will use this, if fail go to b
b)try libreboot, if all works without no problem, I will use this, if fail go to c
c)try coreboot-15h, if all works without no problem, I will use this, if fail..I will search another way instead of use proprietary bios 
Sure, good luck on your endeavour.
Another thing, on my coreboot AMD A10-5800K, lscpu report āsmt vulnerableā, spectre-meltdown-checker report all green. On dmes no message about the āneedā to disable smt, meanwhile in an old core2 hp server (go to trash some years ago) the dmesg said problems about leak of data and recommend to disable smt (and performance became mooore slow) using this kernel cmdline
mds=full,nosmt mitigations=auto