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.
Further info: https://www.suse.com/c/revolutionizing-arm-technology-x86_64-option-rom-aarch64/
software release, hype Show more
run the COOLEST UNIKERNELS in CYBERSPACE with MirageOS version 3.1.0, just released! changelog at https://github.com/mirage/mirage/releases/tag/3.1.0 , get started at https://mirage.io/docs :D
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.
Paper about #LazyFP Intel CPU flaw is out:
“LazyFP: Leaking FPU Register State using Microarchitectural Side-Channels”
@_xhr_ Here's the commit message for that, marc.info's a little slow today: https://email@example.com/msg99141.html
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:
More details about the #LazyFP Intel CPU issue. Affected OSes:
- Linux (mostly pre 4.4.y, y < 138)
- KVM when run on affected Linux kernel versions
- All Xen versions and generally all hypervisors that employ lazy FPU switching
- 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.
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.”
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.
Good 29A mirror with all zines present + intact http://dsr.segfault.es/stuff/website-mirrors/29A/main.html
Apparently there are rumors that FPU state is affected by Spectre as well (h/t @mlarkin on the birdsite):
“post-Spectre rumors suggest that the %cr0 TS flag might not block speculation, permitting leaking of information about FPU state (AES keys?) across protection boundaries.”
Ouch, XSA-201 (Don’t panic, it’s from 2016) sounds like a nasty ARM issue: „ARM guests may induce host asynchronous abort“
Apparently there was some beef between Xen and KVM since the advisory also has a „Note regarding lack of embargo“ section which says: The issue was discussed publicly (and has been fixed already in KVM in public trees). ¯\_(ツ)_/¯
Check out the latest Genode release: it brings update of the Genode Foundations book and much improved Sculpt TC - for The Curious (alternative naming that did not catch on: Trixie-Park Compilation):
Full release notes can be found here: