Kensan @Kensan@mastodon.social

Tfw when you finally figure out that the C code was not working as intended because you added a debug statement after an else which had no curly braces...

I chalk that one up to mainly using Ada/SPARK where you have to write an “end if”. It’s a bad excuse :/

It just occurred to me: Jann Horn is not listed as author of either the Meltdown or the Spectre paper. He is mentioned in a footnote and in the acknowledgements section of Meltdown.

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/

This SGX paper from May 2017 titled “Leaky Cauldron” describes how TLBs are shared between Hyperthreads (section 4.1): “Further we found that when HyperThreading is turned on for a processor, we can clear up the TLBs without issuing TLB shootdown”.

It also contains a systematic analysis of The susceptibility of Intel SGX to memory side-channels.

https://arxiv.org/abs/1705.07289

Paper about #LazyFP Intel CPU flaw is out:
“LazyFP: Leaking FPU Register State using Microarchitectural Side-Channels”

https://blog.cyberus-technology.de/images/lazyFP.pdf

So I pulled the plug and switched from UPC Cablecom to a small-ish local ISP (Init7) that has been very active with IPv6 and has a clear stance on net neutrality. Despite the (theoretical) bandwidth being much smaller, 200 vs. 27 Mbit, I am very satisfied.

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:

https://mastodon.social/@Kensan/99299078060423763

Considering the many interesting talks at #BSD conferences I hear about I have to get my ass to one of them at some point in the future.

More details about the #LazyFP Intel CPU issue. Affected OSes:
- Linux (mostly pre 4.4.y, y < 138)
- FreeBSD
- Windows
- KVM when run on affected Linux kernel versions
- All Xen versions and generally all hypervisors that employ lazy FPU switching

Affected CPUs:
- Verified on the Intel Core microarchitecture from Sandy Bridge to Skylake
- State of other processors unclear

There are also attack details, at least for one of three variants they discovered.

http://blog.cyberus-technology.de/posts/2018-06-06-intel-lazyfp-vulnerability.html

Pondering some more on the “Speculating Intel” #BSDCan talk: I have a feeling there are more issues to be found wrt. hyperthreading. A lot more state is shared between Hyperthreads than physical CPUs which, as we have learned, already share more state than intended...

Wait what? One should hold oneself to an embargo of a vendor even if One has not signed the NDA to get access to the embargoed information? Please tell me I am not the only person thinking this is ridiculous. #lazyFP #BSD

“...should have considered himself part of the embargo in spirit if not in letter.”

Source: https://lobste.rs/s/zwkuza/intel_cpus_might_leak_information_about#c_jri1zp

Well that escalated quickly: Q&A session of Theo de Raadt’s #BSDCan talk “Speculating About Intel” turns rather intense. Imho, Embargos are problematic and we do need to talk about them and/or find a better way to resolve such issues.

Also, with Muen we basically flush and switch “everything” we can when scheduling a different subject. Obviously we take a performance hit (in addition to using Virtualization as the isolation mechanism) but it’s ok for our workloads.

https://youtu.be/UaQpvXSa4X8