cynicalsecurity @cynicalsecurity@bsd.network
IT Security, cynically aged. Maths. Some nukes. Four languages. Longing for Symbolics and Connection Machines. Keeper of Ancient Computing Lore. Ⓐ
This talk contains an interesting idea: emulating Instruction Set Architectures on function-level granularity using NX/execute-disable to trap calls crossing ISA boundaries. The application is using QEMU in UEFI on Aarch64 to run x86_64 Option ROMs. This allows 64-bit ARM code to call x86_64 code, which is emulated, that in turn can call back into Aarch64 code etc.
Video: https://www.youtube.com/watch?v=uxvAH1Q4Mx0
Slides: https://www.linux-kvm.org/images/b/b4/QEMU_in_UEFI.pdf
Code: https://github.com/ardbiesheuvel/X86EmulatorPkg
Further info: https://www.suse.com/c/revolutionizing-arm-technology-x86_64-option-rom-aarch64/
USB over USB
Thank you #OpenBSD for disabling HyperThreading on Intel. I could not agree more.
HyperThreading was a mis-guided attempt at improving performance of Java threads by copying the SPARC processors without having the SPARC architecture… as usual with these marketing-driven issues it is coming back to bite Intel (and us…).
I never, literally never, ran a piece of code benefitting from HyperThreading nor ever heard anyone brag about it.
Just renewed my m:tier subscription - Platinum even though it is a huge dent in my budget.
… and GRX got slammed with a big invoice:
"Court Orders Open Source Security, Inc. and Bradley Spengler To Pay $259,900.50 To My Attorneys"
Oh look, Theo de Raadt seems to confirm my feeling regarding Intel Hyperthreading that I tooted about yesterday:
https://marc.info/?l=openbsd-tech&m=152910536208954&w=2
See also this discussion/rant (with @mulander @cynicalsecurity @csirac2) about Hyperthreading from January:
#Intel #LazyFP vulnerability: Exploiting lazy FPU state switching
Earlier this year, Julian Stecklina (Amazon) and Thomas Prescher (Cyberus Technology) jointly discovered and responsibly disclosed another vulnerability that might be part of these, and we call it LazyFP. LazyFP (CVE-2018-3665) is an attack targeting operating systems that use lazy FPU switching. This article describes what this attack means, outlines how it can be mitigated and how it actually works.
https://blog.cyberus-technology.de/posts/2018-06-06-intel-lazyfp-vulnerability.html
responsible disclosure Show more
OK, so doing the following fixes the issue:
* syspatch -r 014_ipsecout # to revert the patch
* reboot
* system is fine
* syspatch it again
* reboot
* system is fine
It appears that the first relinking of the kernel had an effect.
Trying to reproduce.
Interesting problem:
Installing 014_ipsecout on an #OpenBSD 6.2 machine (Lenovo ThinkPad) causes it to become substantially slower (windowing is sluggish) even though there is no IPsec in use on the system.
Reverting the patch "cures" the problem.
Trying to apply & reboot on a server to see what happens.
The amount of double backflips which are taking place to avoid mentioning the #OpenBSD word in the Intel "Lazy FPU" issue is mind-boggling.
What is even more amazing is how this avoidance is taking place despite people like Colin Percival specifically and openly crediting Theo's talk at BSDcon as the source of his knowledge.
The next OpenBSD cover had better be "Puffy the Pirate" to fully support the pariah status #OpenBSD enjoys…
Ridiculous.
Colin Percival tweeted a short thread on the “Lazy FPU” vulnerability that was just disclosed (CVE-2018-3665).
Colin credits his learning about it to Theo de Raadt. Took him ~5 hours to come up with working exploit code.
https://twitter.com/cperciva/status/1007010583244230656?s=21
More info on seclists.org and discussion on lobste.rs.
http://seclists.org/oss-sec/2018/q2/189
https://lobste.rs/s/qotnxq/confirmed_speculative_register_leakage
Now with accept4(2), which saves us a round trip to the kernel to get non-blocking sockets.
https://marc.info/?l=openbsd-tech&m=152889733627575&w=2
(I already had the improved refuse-any option cherry picked for OpenBSD)
The most beautiful feeling ever: on the birdsite I linked up @lattera with PINE64 in the vain hope of getting him a device to work #HardenedBSD on and they replied…
I would have never thought it would happen.
:)
@lattera have you any experience of running FreeBSD (or, better, HardenedBSD) on an HP EliteBook 840 G5? I am probably getting one for work (I have no say in the matter).
Specs here: https://store.hp.com/us/en/pdp/hp-elitebook-840-g5-notebook-pc-p-3rf06ut-aba-1
Does anyone know if, besides the blinkenlichten case by @jjg (see Rain Mk. II,
https://hackaday.com/2018/03/21/everyone-needs-a-personal-supercomputer/) there are any other cases for the PINE64 ClusterBoard?
I haven't been able to find any nor any good recommendations.
"semi-eager FPU switching" https://marc.info/?l=openbsd-cvs&m=152818076013158&w=2 #OpenBSD
"3) post-Spectre rumours suggest that the %cr0 TS flag might not block speculation, permitting leaking of information about FPU state (AES keys?) across protection boundaries."
I am amazed at the amount of centralisation on "other people's machines" which the free/open-source movement blindly supports.
Just one of them going out of business or going Evil and so much would be lost.
How many projects rely on Google in some way? How many on Github? How many on Microsoft?
The PINE64 people have come up with the necessary accessories to the Rock64Pro board which includes a PCI-e slot:
* RockPro64: https://www.pine64.org/?page_id=61454
* PCI-e to dual SATA II: https://www.pine64.org/?product=rockpro64-pci-e-to-dual-sata-ii-interface-card
* Prototype NAS case: https://forum.pine64.org/showthread.php?tid=6129
things are starting to warm up dramatically. My plan remains to migrate to a ClusterBoard-based design with SOPINE modules "per-machine" but now the NAS feeding them NFS need not be a Synology…
