24 ms·

M1racles: An Apple M1 covert channel vulnerability

1067 points by paulgerhardt 5y ago

sneak 5y ago
Marcan's posts, comments, and now websites are always fun to read, and this one is no exception.
- arunc 5y ago
  Not to miss his YouTube channel where he does live hacking sessions. Invaluable for beginners. https://www.youtube.com/watch?v=hLQKrEh6w7M https://www.youtube.com/watch?v=hLQKrEh6w7M
  - nayuki 5y ago
    I love the two puns in the title: "M1RACLES: Bad Apple!! on a bad Apple (M1 vulnerability)"
krrrh 5y ago
TL;DR and he really buried the lede > So what's the real danger? > If you already have malware on your computer, that malware can communicate with other malware on your computer in an unexpected way. > Chances are it could communicate in plenty of expected ways anyway. > That doesn't sound too bad. > Honestly, I would expect advertising companies to try to abuse this kind of thing for cross-app tracking, more than criminals. Pretty sure Apple could catch them if they tried, though (for App Store apps).
- bombcar 5y ago
  > So what's the point of this website? >Poking fun at how ridiculous infosec clickbait vulnerability reporting has become lately. Just because it has a flashy website or it makes the news doesn't mean you need to care. >If you've read all the way to here, congratulations! You're one of the rare people who doesn't just retweet based on the page title :-) Heh my initial take at the top was confirmed.
mhh__ 5y ago
Do Apple actually maintain a list of errata
- sanxiyn 5y ago
  I couldn't find one from search and this Linux kernel documentation: https://www.kernel.org/doc/html/latest/arm64/silicon-errata.html https://www.kernel.org/doc/html/latest/arm64/silicon-errata.....
  - mhh__ 5y ago
    I also had a look a while back but I was hoping they had one for Apple devs or whatever. Some documentation would be nice...
- saagarjha 5y ago
  Internally they certainly do.
culturestate 5y ago
I'm almost as impressed that m1racles.com was available as I am with people who are good enough at this kind of reverse engineering that they can do it for fun.
- bombcar 5y ago
  Quick register all words that start with MI for future vulnerabilities. I’m waiting for M1RAGE and M1TIGATE myself.
  - culturestate 5y ago
    You joke but somewhere there's a domainer doing this right now.
    - cmehdy 5y ago
      I'll give them a couple too: M1GHT, M1CRO*, M1ASMA (M1ASTHMA?), M1D*, M1FFED (with some 0xFFED somewhere?), M1GRATE (for some particularly pesky data extraction hack?), M1LES (for some unit conversion bug that makes the first MacOs-based spaceship crash)
      - k_sze 5y ago
        M1GRAIN for something about atomic ops.
        fooker 5y ago
        M1LF
        jraph 5y ago
        That would be a line feed related parsing vulnerability in a messaging app on M1.
        Cybotron5000 5y ago
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
eyelidlessness 5y ago
I checked this out to find out just... information I guess? I don’t own an M1 but plan to get an ARM Mac when I can budget it. Good to be aware of the landscape. I was not expecting such an entertaining FAQ. Good job, very informative, very amusing!
- madis 5y ago
  Why would you spend money on crappy and locked down hardware that can't be fixed. A computer that you don't own but basically rent. Get a Lenovo Thinkpad and join the light side, you'll be amazed!
  - BusTrainBus 5y ago
    Lenovo is a Chinese company.
    - mukesh610 5y ago
      So?
  - ImprobableTruth 5y ago
    Well, the performance is pretty good...
  - princekolt 5y ago
    “Aaaaa look at me I am right you are wrong aaaa”
  - raxxorrax 5y ago
    > locked down hardware not every register!
  - breakfastduck 5y ago
    Whatever your opinions on Apples policies and behavior it's just ignorant to call the M1 'crappy' when it absolutely annihilates any processor in its class and doesn't at all get embarrassed when compared to high end desktop CPUs.
lasagnaphil 5y ago
Holy shit, just as I thought we’ve run out of novel ways of playing Bad Apple, here we are...
- breck 5y ago
  https://www.youtube.com/watch?v=tO6sfku_1b8 https://www.youtube.com/watch?v=tO6sfku_1b8
timeimp 5y ago
Heh, its "baked in" heh In all seriousness, I wonder what the actual issue is. Could anyone comment as to the implications of only supporting a Type 2 hypervisor that is (as said on the site) "in violation of the ARMv8 specification"?
- bombcar 5y ago
  One implication is it prevents solutions to things like this. This one is a minor side note but there could be other vulnerabilities that could be resolved if the specifications were followed (I assume).
  - marcan_42 5y ago
    You can still solve the issue in VHE mode, since you can still implement a Type 1 hypervisor in VHE mode. It's just that, well, nobody does that, because why would they? That's what non-VHE mode is for. So it's not that not following the spec prevents the workaround, it's just that had they followed the spec it would just take a single kernel command line argument (to force non-VHE mode) to fix this in Linux, while instead, now we'd have to make major changes to KVM to make the non-VHE code actually work with VHE, and really nobody wants to do that just to mitigate this silly thing. Had this been a more dangerous flaw (e.g. with DoS or worse consequences), OSes would be scrambling to make major reworks right now to mitigate it in that way. macOS would have to turn its entire hypervisor design on its head. Possible, but not fun.
    - withinboredom 5y ago
      Are there any legal ramifications for them not following the spec?
- marcan_42 5y ago
  The implications are just that OSes that assume otherwise won't run; Linux used to work (by chance) until a patch that just about coincided with our project went in that used the non-VHE ("type 1") mode by default, which broke it, and then we had to add an explicit workaround for the M1. It's just a very unfortunate coincidence that precisely that support would allow this bug to be trivially mitigated on Linux. (Wouldn't help macOS, as they'd have to implement this from scratch anyway; it's just that existing OSes that support this mode could use it). The actual issue is just what I described: the hardware implementation of this register neglects to check for and reject accesses from EL0 (userspace). It's a chip logic design flaw. I don't know exactly where it is (whether in the core/instruction decoder, or in the cluster component that actually holds the register, depending on where they do access controls), but either way that's what the problem is.
m1keil 5y ago
This doesn't look like an issue that deserves its own website tbh.
- floatingatoll 5y ago
  The author agrees with you partway down the page.
- pthariensflame 5y ago
  I think that was the point. XD
- jkaplowitz 5y ago
  The content of the website basically makes that point itself. It's mocking the whole concept of these vulnerability websites, while also presenting a real (but not very impactful) vulnerability.
  - m1keil 5y ago
    Oh, right. sorry, I sort of bailed on the whole FAQ thing when it was silly joke after joke but I get it now. It's the onion news of CVEs.
    - marcan_42 5y ago
      It's real though, The Onion is largely fake/jokes.
      - rswail 5y ago
        The Onion almost gave up in the 2016-2020 period because their satire was overtaken by the actual headlines.
        mnw21cam 5y ago
        Ah, but did they write a story about that?
alberth 5y ago
ELI5, anyone. Are the chip registers not protected? What's the mechanism that's allowing this data sharing to happen?
- peteretep 5y ago
  > So what's the real danger? > If you already have malware on your computer, that malware can communicate with other malware on your computer in an unexpected way. > Chances are it could communicate in plenty of expected ways anyway.
- josephcsible 5y ago
  There's two bits of a CPU's register that are shared between all of its processes and that any process can write to. The result is that two sandboxed processes that are supposed to be totally isolated from each other can use this to communicate anyway. One example of how this can be exploited is cross-app tracking: if you told one app your name and another your location, they could secretly communicate with each other so both apps end up with both pieces of information.
  - herpderperator 5y ago
    Why couldn't a future OS update add access control to these registers?
    - josephcsible 5y ago
      Because the CPU doesn't provide a practical means to do so.
      - herpderperator 5y ago
        Doesn't the kernel control CPU access?
        kevingadd 5y ago
blendergeek 5y ago
My favorite part of the entire page: > So what's the point of this website? > Poking fun at how ridiculous infosec clickbait vulnerability reporting has become lately. Just because it has a flashy website or it makes the news doesn't mean you need to care. > If you've read all the way to here, congratulations! You're one of the rare people who doesn't just retweet based on the page title :-)
- meowface 5y ago
  In case anyone was confused by this comment: it's not a hoax/joke site. It's a real bug; just a low-severity one that's intentionally overhyped.
  - lamontcg 5y ago
    Heh, I couldn't get through it because of the toxic levels of self promotion and was about to get very ranty about it all.
    - philbert101 5y ago
      Maybe you missed the disclaimer at the top? “CVE-2021-30747 Should you be worried? Probably not.”
      - lamontcg 5y ago
        Yes, I got that from the top comment here.
peteretep 5y ago
"So you're telling me I shouldn't worry? Yes."
sebmellen 5y ago
Actually not a bad song [0]. Thanks to whoever made this, I guess :D [0]: https://www.youtube.com/watch?v=i41KoE0iMYU https://www.youtube.com/watch?v=i41KoE0iMYU
- marcan_42 5y ago
  I had to use that one for this demo for obvious reasons, but if I'm allowed the shameless plug, I actually make my own music in the same genre (Touhou rearrangements) [0]. I'm actually very much looking forward to moving my music production to M1 and seeing what the real-time performance is like, though that will depend on us having at least a usable Rosetta-like thing on Linux to run x86 Windows apps (which will allow me to bridge the few x86 Windows plug-ins I rely on with yabridge, as I do today on x86) :-) [0] https://www.youtube.com/playlist?list=PL68XxS4_ek4afs0eXwRiYvMML5Y4OYWzx https://www.youtube.com/playlist?list=PL68XxS4_ek4afs0eXwRiY...
  - sebmellen 5y ago
    Awesome! I'll take a listen and play it during my all-nighter tonight. Best of luck getting that M1 Mac working, I'm really liking mine so far!
  - NobodyNada 5y ago
    That's awesome! I'm definitely thinking about getting an M1 for realtime keys, though I'm all set up in Logic/MainStage so I'll probably stick with macOS for now :) On the Linux side, would qemu user-mode emulation work for that (maybe with a patch to take advantage of the M1's switchable-memory-order thing)?
    - marcan_42 5y ago
      I think qemu would work fine, but it's pretty slow, so I'm hoping it can either be improved or another project more focused on this use case can do it better. If nothing else though, I plan to expose at least the TSO feature of the M1 so qemu can reduce the overhead of its memory accesses.
  - 5y ago
kbenson 5y ago
Was this responsibly disclosed? I tried, but I also talked about it on public IRC before I knew it was a bug and not a feature, so I couldn't do much about that part. ¯\_(ツ)_/¯ This whole site is a good read. A great mix of real information, jokes, and a good send-up of how some security releases appear these days (I understand to a degree the incentives that cause those sites to be as they are, and I don't think they area all bad, but it's still good and useful to poke fun them I think).
vmception 5y ago
well this is a new genre of satire
Rantenki 5y ago
I've been stumbling through writing a pile of secure software development lifecycle management and disclosure practices documentation all evening, and desperately needed a bit of levity. This post delivered. Thank you. Also, I am still not sure if this is a disclosure, performance art, or extremely dry comedy, but it certainly covered all the bases.
__d 5y ago
> Newton OS users: I guess those are technically Apple Silicon but... The Newton wasn't really Apple Silicon: The OMP/MP100/MP110/MP120/MP130 ran an ARM610. The eMate300 ran an ARM710. The MP2000/MP2100 ran a DEC StrongARM SA-110 CPU. None of which were designed or manufactured by Apple.
- phire 5y ago
  At the time, Apple owned 50% of ARM. ARM, the company only existed because Apple wanted them to manufacture a CPU for it's Newton project. While Apple might not have designed the ARM610, but they technically owned it.
  - __d 5y ago
    I did say "designed or manufactured" ... but I'll concede the point that they had some ownership of the 610/710, at least. On 27 Nov 1990, ARM was formed with Apple owning 43% alongside Acorn (the designer), and VLSI Technology (the manufacturer). Funny thing: I've found two articles that claim two different purchase prices for that 43%: one $3M [0] and the other $1.5B [1]. That's quite a difference! [0] https://appleinsider.com/articles/20/06/09/how-arm-has-already-saved-apple---twice https://appleinsider.com/articles/20/06/09/how-arm-has-alrea... [1] https://www.cultofmac.com/97055/this-is-how-arm-saved-apple-from-going-bust-1990s/ https://www.cultofmac.com/97055/this-is-how-arm-saved-apple-...
  - klelatti 5y ago
    > At the time, Apple owned 50% of ARM. Nope, Apple never owned 50% of ARM. > ARM, the company only existed because Apple wanted them to manufacture a CPU for it's Newton project. Who knows what would have happened had Apple not invested but Apple was never ARM's only customer. > While Apple might not have designed the ARM610, but they technically owned it. If I own some Apple shares reasonably sure that doesn't mean that "technically" I own the M1.
- deleted 5y ago
  [deleted]
- tonyedgecombe 5y ago
deleted 5y ago
[deleted]
slver 5y ago
> If you already have malware on your computer, that malware can communicate with other malware on your computer in an unexpected way. > Chances are it could communicate in plenty of expected ways anyway. This site is basically if Douglas Adams instead had a career in security research.
- robertlagrant 5y ago
  I still think Apple Watches are a pretty neat idea.
xucheng 5y ago
Given M1 is in iPad Pro now, I think there could will be Apps seriously exploiting this to circumvent Do No Track in iOS 14.5.
- edgyquant 5y ago
  How? They’d have to communicate with an app that does have those permissions
  - xucheng 5y ago
    At the core, DO NOT TRACK prevents Apps having access to the Advertising Identifier. So different Apps cannot aggregate their analytics data about the users. This vulnerability enables different Apps to communicate a super cookie for cross-app tracking. A possible exploit would be to implement this feature in an AD SDK to be used by different Apps.
    - intricatedetail 5y ago
      But does it actually do anything? Apps can surely identify users by other means, e.g. IP, behaviour...
- marcan_42 5y ago
  Thankfully, Apple should be able to statically analyze apps to look for this on App Store submission, as the App Store does not allow dynamic code (JITs).
denysvitali 5y ago
> I came here from a news site and they didn't tell me any of this at all! > > Then perhaps you should stop reading that news site, just like they stopped reading this site after the first 2 paragraphs. Marcan is a genius, in every aspect. He is on my top list of people I could read all day long without getting annoyed. Pretty much everything he posts on Twitter is interesting and curious. I'm a huge fan! The other person I have similar feelings for is Geohot. These guys are really, really smart.
- xmprt 5y ago
  I also really liked this line > Wait. Oh no. Some game developer somewhere is going to try to use this as a synchronization primitive, aren't they. Please don't. The world has enough cursed code already. Don't do it. Stop it. Noooooooooooooooo
  - ohazi 5y ago
    m1racle-mutex: https://twitter.com/LunaFoxgirlVT/status/1397441284487401478?s=19 https://twitter.com/LunaFoxgirlVT/status/1397441284487401478...
- hans1729 5y ago
  >The other person I have similar feelings for is Geohot. These guys are really, really smart. Its ok George, we love you and you know it
- soedirgo 5y ago
  > The other person I have similar feelings for is Geohot. I don't know about that... https://news.ycombinator.com/item?id=25679907 https://news.ycombinator.com/item?id=25679907
  - comboy 5y ago
    You gave denysvitali some serious cognitive dissonance.
    - 5y ago
tyingq 5y ago
I suppose you could use it to create a "covert suite" of apps for the M1 iPad that talk to each other where they aren't supposed to. Sharing permission X from app 1 with app 2 that isn't supposed to have permission X, etc.
- marcan_42 5y ago
  Thankfully Apple can, in principle, statically analyze for this on the iOS App Store, as they do not allow JIT mappings on those devices.
  - e_proxus 5y ago
    Can they guarantee no JIT code via static analysis as well? Or could someone sneak in a tiny bit of disguised JIT code just to get to this register? I would assume a huge JITed VM implementation would show up easily in analysis.
    - phire 5y ago
      They don't provide anyway to mark memory as executable.
      - saagarjha 5y ago
        Well, they do, because they have to run your code :P You just can't make a new page of code and mark it executable.
        marcan_42 5y ago
        The OS only makes pages executable if they come from a signed app. There is no way for the app itself to do that.
        saagarjha 5y ago
        If it makes it more clear, my comment was mostly "if your code page has a valid signature you can mark it as executable".
vignesh_warar 5y ago
>I came here from a news site and they didn't tell me any of this at all! >Then perhaps you should stop reading that news site, just like they stopped reading this site after the first 2 paragraphs. This is my most favorite
bradleybuda 5y ago
Could this be fixed with a microcode update (he asks, not really having any idea what microcode is)?
- Operyl 5y ago
  Does the M1 even have microcode updates? I haven't seen anything pointing to that yet.
  - marcan_42 5y ago
    I don't think so, no. If it has microcode it's probably burned into sequencer tables, not updatable. I was kind of hoping Apple would have some chicken bit register up their sleeve as a last resource fix (e.g. "trap on instruction encodings matching this mask"), but given that they seem to have no useful mitigation for it, I don't think they do.
    - londons_explore 5y ago
      Is it possible Apple have the silicon functionality to fix this, but have decided it isn't worth fixing? After all, process isolation between cooperating processes is nearly impossible to do. If Apple close this loophole, there will be other lower bandwidth side channels like spinning up the fan in Morse code and the other process notices the clock speed scaling up and down...
      - marcan_42 5y ago
        It doesn't really make sense not to fix it if they can in fact do so easily.
        londons_explore 5y ago
        Except software-silicon patches usually have a limited number of filters, patch slots, etc. Might not be worth using one for this.
planb 5y ago
This is the best thing I've seen on the internet for a long time. Hopefully some people (tech journalists and twitter folks) will "fall for it" and learn along the way...
thysultan 5y ago
Sounds like a killer feature. They're going to announce this at wwdc21.
- mxcrossr 5y ago
  No definitely a big, but I expect that they will announce the swarm of nanobots they plan to release to fix all the affected chips.
gostsamo 5y ago
> Am I affected? > • OpenBSD users: Hi Mark! Yes, "Hi Mark", whoever you are and no matter that I'm not an OpenBSD user.
- psy-q 5y ago
  I took it as a reference to The Room. Isn't it? :|
  - gostsamo 5y ago
    I'm not aware of the referenced material. :)
    - meowface 5y ago
      https://www.youtube.com/watch?v=ZdzmKwKN3n8 https://www.youtube.com/watch?v=ZdzmKwKN3n8
    - psy-q 5y ago
      Oooo! Depending on your taste you're in for either a very boring movie or the experience of a lifetime. Complete with an associated rabbit hole of mystery surrounding the director: https://en.wikipedia.org/wiki/The_Room https://en.wikipedia.org/wiki/The_Room If you do end up watching and liking it, there is book and a film about the filming of the film to enjoy :D https://en.wikipedia.org/wiki/The_Disaster_Artist https://en.wikipedia.org/wiki/The_Disaster_Artist
    - gostsamo 5y ago
      Thanks both of you for the info.
- delroth 5y ago
  Context: Mark Kettenis has been porting OpenBSD to the M1 SoC, and is probably the only current user of that code.
  - marcan_42 5y ago
tectonic 5y ago
> Wait. Oh no. Some game developer somewhere is going to try to use this as a synchronization primitive, aren't they. Please don't. The world has enough cursed code already. Don't do it. Stop it. Noooooooooooooooo
- galgalesh 5y ago
  Cross-core communication without going through the kernel seems like a very useful performance feature for games. Am I missing something or is it somewhat likely this will be "abused" by games?
  - lilyball 5y ago
    This thing communicates at 1MB/s. A “performance feature” it ain’t.
    - deleted 5y ago
      [deleted]
    - dijit 5y ago
      throughput and latency are different measures. Games usually live in the realm of latency.
      - passivate 5y ago
        That begs the question, what is the latency, and what kind of feature would you anticipate this could be useful for?
    - mukesh610 5y ago
      Synchronization primitives AFAIK don't need to transfer huge amounts of data in a short time. One bit for every "okay" signal would suffice. At the given speed you can perform 8 million syncs per second between two threads.
    - smoldesu 5y ago
      who cares, it's not like you're going to use it to send textures from one thread to another
0xakhil 5y ago
How about randomising/reset these bits from kernel whenever there is a syscall? Not a great workaround but this should limit the effectiveness of leaking. Yeah, there will be tiny perf hit due to extra register read and write.
- NobodyNada 5y ago
  > Wait, didn't you say on Twitter that this could be mitigated really easily? > Yeah, but originally I thought the register was per-core. If it were, then you could just wipe it on context switches. But since it's per-cluster, sadly, we're kind of screwed, since you can do cross-core communication without going into the kernel. Other than running in EL1/0 with TGE=0 (i.e. inside a VM guest), there's no known way to block it. In other words: this register is shared between cores, so if the two processes are running simultaneously on different cores, they can communicate by reading & writing directly to & from this register, without any operating system interaction.
- CJefferson 5y ago
  Unfortunately, you can use this to send thousands of bits between syscalls, so the simplest error correction would fix that, with very little effort or overhead.
  - marcan_42 5y ago
    The demo already uses error correction (I'm not sure exactly what causes the errors, but I'm guessing the processes sometimes end up briefly scheduled on the other core cluster)
fulafel 5y ago
> It violates the OS security model. You're not supposed to be able to send data from one process to another secretly. I'd argue this is not the case. What mainstream operating systems have made credible attempts to eliminate covert channels from eg timing or resources that can be made visible by cooperating processes across user account boundaries?
- londons_explore 5y ago
  Indeed. Without this vulnerability, there would still be a million ways to send data between cooperative processes running as different users on Mac OS X. For example, a process could start subprocesses at a deterministic rate and the other end of the covert link observes how fast the pid counter is going up. This is a non-vulnerability, because it targets something there was no effort to protect.
  - Cthulhu_ 5y ago
    It's not really a vulnerability as the FAQ states, but it violates the operating system's own application isolation policies. If you don't want your Facebook app to talk to your Instagram app (e.g. different accounts for different purposes), you should be able, as a user, to block communication between the two. This is a backdoor to circumvent that. I mean not that anyone has a native Facebook or Instagram app on their device, but just to name an example.
    - vbsteven 5y ago
      > I mean not that anyone has a native Facebook or Instagram app on their device, but just to name an example. The M1 is used in the iPad Pro so your example is definitely possible. (or your comment was sarcasm in which case: woosh to myself)
- angrygoat 5y ago
  Yes, exactly. Multics actually tried, here's a memo from 1974 discussing the issue: https://multicians.org/mtbs/mtb696.html https://multicians.org/mtbs/mtb696.html Paged shared libraries, signalling by ramping up and down CPU usage, there are an enormous number of possible covert channels.
deleted 5y ago
[deleted]
Sparkyte 5y ago
Real? I'm confused by a particular infosec quote.
afandian 5y ago
Sorry if I missed it, but what is the defined purpose of the s3_5_c15_c10_1 register? Or is it just general purpose?
- Cthulhu_ 5y ago
  I googled it for you and err, came up blank, there's just two code references in some ASM code, the rest points to this resource. Weird, I would have thought things like this would have public documentation.
  - pthariensflame 5y ago
    https://news.ycombinator.com/item?id=27287519 https://news.ycombinator.com/item?id=27287519
- pthariensflame 5y ago
  It’s not a standard ARM register; it’s implementation-defined and nobody gave it a meaningful name. It appears to do nothing much.
  - exikyut 5y ago
    Then why not unofficially standardize its use in GCC and Clang's register-pooling subsystem?
    - saagarjha 5y ago
      Because GCC and Clang don't get to decide what hardware does with the register…
- marcan_42 5y ago
  It's an implementation-defined register, which means it's up to Apple to define it. We have no idea what it does; we haven't observed any visible effects from flipping those bits. Given that it's per-cluster, we can infer that it has something to do with cluster-specific logic. Perhaps memory interface or power control. There are hundreds of Apple implementation-defined registers; we're documenting them as we learn more about them [0] [1] [2] [0] https://github.com/AsahiLinux/m1n1/blob/main/tools/apple_regs.json https://github.com/AsahiLinux/m1n1/blob/main/tools/apple_reg... [1] https://github.com/AsahiLinux/docs/wiki/HW%3AARM-System-Registers https://github.com/AsahiLinux/docs/wiki/HW%3AARM-System-Regi... [2] https://github.com/AsahiLinux/docs/wiki/HW%3AARM-System-Registers-Dumps https://github.com/AsahiLinux/docs/wiki/HW%3AARM-System-Regi...
Woodi 5y ago
Wait, did he just, as exploit proof of concept, infiltrated some catch music&&video clip ? With life rendering on same CPU ? :> Anyway - Apple did it again ! In shiny, new hardware for "creative" ppl introduced hardware backdors... Like FireWire and Thunderbird. Seriously, there must be some market for spying on writers and painters. Or anyone who do thing and is rich...
- exikyut 5y ago
  Bad Apple goes much deeper than that. IMHO this pretty much retires it.
umanghere 5y ago
While Marcan has written in a very entertaining fashion, there is perhaps one application of this vulnerability that wasn't considered. If this can be reproduced on the iPhone, it can lead to 3rd party keyboards exfiltrating data. By default, keyboard app extensions are sandboxed away from their owning applications [0], but they may communicate with the app over this channel and leak data. It's not as easy as I describe because the app would have to be alive and scheduled on the same cluster, but it's within the realm of possibility. [0]: https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/CustomKeyboard.html https://developer.apple.com/library/archive/documentation/Ge...
- gostsamo 5y ago
  IPhones use A12/13/14 chip and the vulnerability is not confirmed there. Also, the post mentions that if you have two malware apps on your device, they can communicate in many other ways, so I'm not sure what's new here. Edit: fixed name of the chip.
  - umanghere 5y ago
    iPhones do not use the A1 chip as of quite a few years ago. Besides, the M1 and the A12+ have significant microarchitectural similarities, to the point that the DTK used the A12Z. Furthermore, the keyboard app extension and the keyboard app are installed as a single package whose components are not supposed to communicate, hence why I brought this up.
    - gostsamo 5y ago
      The only 1 in the name of the chip is typo. The rest I'm still not sure if it is significant.
    - dfox 5y ago
      I believe that only significant difference between A14 and M1 (apart from package) is number of cores.
  - Closi 5y ago
wejkfwe 5y ago
So, all the great performance of M1 was achieved due to the poor security?
- saagarjha 5y ago
  They are entirely unrelated.
martini333 5y ago
That demo made me vomit
withinboredom 5y ago
I was actually planning to pick up a new Mac today and I’ve been on the fence over M1 or Intel for months. My biggest con for the M1 is how proprietary it is. With Intel, you know it’s been battle-tested for years. Things like this (at best, is an oversight, at worst, it’s the tip of the iceberg) make the decision a little bit easier…
- rvz 5y ago
  Don't know why you've been downvoted. It all depends on the software that you use everyday (job or whatever). If the software does not run on an M1 Mac or requires involved workarounds to get it 'working' and it breaks on any update or it prevents you from doing your work, then don't waste your time and just skip it for now. Also wait until WWDC, like I said before.
- user-the-name 5y ago
  Intel chips are chock full of these same kinds of mistakes.
- filleduchaos 5y ago
  > With Intel, you know it’s been battle-tested for years. This is quite an interesting statement to make in the wake of Spectre and Meltdown (and vulnerabilities in that class being discovered what seems like every couple of months or so). It's a bit amusing to me how much we overlook clear, even huge flaws in products and processes because they're old - sorry, Battle-Tested™ - while zeroing in on lesser flaws in newer ones.
volta83 5y ago
> in violation of the ARM architecture specification > Apple decided to break the ARM spec by removing a mandatory feature Is there a page documenting all incompatibilities / violations of the ARM architecture specification by the M1?
- saagarjha 5y ago
  I wouldn't be surprised if the language gets loosened in the next revision of the standard, as it has in the past.
1f60c 5y ago
> Was this responsibly disclosed? > > I tried, but I also talked about it on public IRC before I knew it was a bug and not a feature, so I couldn't do much about that part. ¯\_(ツ)_/¯ That seems... unwise to admit publicly.
fnord77 5y ago
> So what's the point of this website? > Poking fun at how ridiculous infosec clickbait vulnerability reporting has become lately. Just because it has a flashy website or it makes the news doesn't mean you need to care.
nazgulsenpai 5y ago
> OpenBSD users: Hi Mark! Ok I nearly fell out of my chair. A+
ncr100 5y ago
Is the risk that malicious software can be split into multiple, obfuscated components? Without such a silicon vulnerability the malicious process would need all its components within a single process/image?
apetresc 5y ago
Out of curiosity, which public IRC channel was this being discussed in, before it was understood to be a bug? That sounds like a fun channel.
- apetresc 5y ago
  Ah, looking more into it, I'm going to guess it was #asahi or #asahi-dev.
  - marcan_42 5y ago
    Yup, here's the log if you're curious :-) https://oftc.irclog.whitequark.org/asahi/2021-02-24#29220558 https://oftc.irclog.whitequark.org/asahi/2021-02-24#29220558
pokot0 5y ago
It seems like a single bit available to all apps but that no one is really using now. I wonder if a easy software mitigation could be just polluting it intentionally.
notaplumber 5y ago
> "OpenBSD users: Hi Mark!" This is Mark Kettenis, who has despite comments made jokingly by marcan, been working with a few other OpenBSD developers to bring-up OpenBSD/arm64 on the Apple M1. At least on the Mac Mini the Gigabit Ethernet works, Broadcom Wi-Fi, and work on the internal NVMe storage is progressing. There was an early teaser dmesg posted in Feburary showing OpenBSD booting multi-user (on bare metal): https://marc.info/?l=openbsd-arm&m=161386122115249&w=2 https://marc.info/?l=openbsd-arm&m=161386122115249&w=2 Mark has also been adding support for the M1 to the U-Boot project, which will not only benefit OpenBSD, but also Asahi Linux. Another OpenBSD developer posted these screenshots and videos on Twitter. https://twitter.com/bluerise/status/1359644736483655683 https://twitter.com/bluerise/status/1359644736483655683 https://twitter.com/bluerise/status/1354216838406823936 https://twitter.com/bluerise/status/1354216838406823936
Simplicitas 5y ago
I wish all CVE were written this way :-)
ulzeraj 5y ago
I love the choice of music. Very appropriate.
2OEH8eoCRo0 5y ago
Security through obscurity + walled garden. Brilliant move.
deleted 5y ago
[deleted]
Iv 5y ago
> So what's the point of this website? > Poking fun at how ridiculous infosec clickbait vulnerability reporting has become lately. Just because it has a flashy website or it makes the news doesn't mean you need to care. > If you've read all the way to here, congratulations! You're one of the rare people who doesn't just retweet based on the page title :-)
- ddtaylor 5y ago
  That's reassuring to read. I opened the page, read a bit of it, pressed play on the video and scrubbed around a bit, got irritated and closed the tab. I figured if it mattered I would wait until better coverage came out.
addaon 5y ago
It seems like there's a partial mitigation available to the OS here. When scheduling a task, write a random value to the two user-writable bits. When the task is unscheduled, if the bits do not match, terminate the task. This effectively makes writing to the register an OS-enforced illegal operation with a 75% chance of being caught within 10 ms if the channel is being used at full bandwidth. (The writer can reduce the chance of it being caught proportional to reduced use of channel bandwidth by resetting it to the OS-chosen value after a bit is transmitted.) The reader can't be detected this way, but since the channel requires cooperation between the writer and reader, catching either is fine. Not a perfect fix, but would help, and would also give visibility into whether this is used in the wild -- e.g., report to Apple via crash reporting mechanism if a process is terminated this way, which would allow prompt discovery of app store apps that abuse the channel.

1067 points by paulgerhardt 5y ago

sneak 5y ago

Marcan's posts, comments, and now websites are always fun to read, and this one is no exception.

arunc 5y ago
Not to miss his YouTube channel where he does live hacking sessions. Invaluable for beginners. https://www.youtube.com/watch?v=hLQKrEh6w7M https://www.youtube.com/watch?v=hLQKrEh6w7M
- nayuki 5y ago
  I love the two puns in the title: "M1RACLES: Bad Apple!! on a bad Apple (M1 vulnerability)"

krrrh 5y ago

TL;DR and he really buried the lede > So what's the real danger? > If you already have malware on your computer, that malware can communicate with other malware on your computer in an unexpected way. > Chances are it could communicate in plenty of expected ways anyway. > That doesn't sound too bad. > Honestly, I would expect advertising companies to try to abuse this kind of thing for cross-app tracking, more than criminals. Pretty sure Apple could catch them if they tried, though (for App Store apps).

bombcar 5y ago
> So what's the point of this website? >Poking fun at how ridiculous infosec clickbait vulnerability reporting has become lately. Just because it has a flashy website or it makes the news doesn't mean you need to care. >If you've read all the way to here, congratulations! You're one of the rare people who doesn't just retweet based on the page title :-) Heh my initial take at the top was confirmed.

mhh__ 5y ago

Do Apple actually maintain a list of errata

sanxiyn 5y ago
I couldn't find one from search and this Linux kernel documentation: https://www.kernel.org/doc/html/latest/arm64/silicon-errata.html https://www.kernel.org/doc/html/latest/arm64/silicon-errata.....
- mhh__ 5y ago
  I also had a look a while back but I was hoping they had one for Apple devs or whatever. Some documentation would be nice...
saagarjha 5y ago
Internally they certainly do.

culturestate 5y ago

I'm almost as impressed that m1racles.com was available as I am with people who are good enough at this kind of reverse engineering that they can do it for fun.

bombcar 5y ago
Quick register all words that start with MI for future vulnerabilities. I’m waiting for M1RAGE and M1TIGATE myself.
- culturestate 5y ago
  You joke but somewhere there's a domainer doing this right now.
  - cmehdy 5y ago
    I'll give them a couple too: M1GHT, M1CRO*, M1ASMA (M1ASTHMA?), M1D*, M1FFED (with some 0xFFED somewhere?), M1GRATE (for some particularly pesky data extraction hack?), M1LES (for some unit conversion bug that makes the first MacOs-based spaceship crash)
    - k_sze 5y ago
      M1GRAIN for something about atomic ops.
      - fooker 5y ago
        M1LF
        jraph 5y ago
        That would be a line feed related parsing vulnerability in a messaging app on M1.
        Cybotron5000 5y ago

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

eyelidlessness 5y ago

I checked this out to find out just... information I guess? I don’t own an M1 but plan to get an ARM Mac when I can budget it. Good to be aware of the landscape. I was not expecting such an entertaining FAQ. Good job, very informative, very amusing!

madis 5y ago
Why would you spend money on crappy and locked down hardware that can't be fixed. A computer that you don't own but basically rent. Get a Lenovo Thinkpad and join the light side, you'll be amazed!
- BusTrainBus 5y ago
  Lenovo is a Chinese company.
  - mukesh610 5y ago
    So?
- ImprobableTruth 5y ago
  Well, the performance is pretty good...
- princekolt 5y ago
  “Aaaaa look at me I am right you are wrong aaaa”
- raxxorrax 5y ago
  > locked down hardware not every register!
- breakfastduck 5y ago
  Whatever your opinions on Apples policies and behavior it's just ignorant to call the M1 'crappy' when it absolutely annihilates any processor in its class and doesn't at all get embarrassed when compared to high end desktop CPUs.

lasagnaphil 5y ago

Holy shit, just as I thought we’ve run out of novel ways of playing Bad Apple, here we are...

breck 5y ago
https://www.youtube.com/watch?v=tO6sfku_1b8 https://www.youtube.com/watch?v=tO6sfku_1b8

timeimp 5y ago

Heh, its "baked in" heh In all seriousness, I wonder what the actual issue is. Could anyone comment as to the implications of only supporting a Type 2 hypervisor that is (as said on the site) "in violation of the ARMv8 specification"?

bombcar 5y ago
One implication is it prevents solutions to things like this. This one is a minor side note but there could be other vulnerabilities that could be resolved if the specifications were followed (I assume).
- marcan_42 5y ago
  You can still solve the issue in VHE mode, since you can still implement a Type 1 hypervisor in VHE mode. It's just that, well, nobody does that, because why would they? That's what non-VHE mode is for. So it's not that not following the spec prevents the workaround, it's just that had they followed the spec it would just take a single kernel command line argument (to force non-VHE mode) to fix this in Linux, while instead, now we'd have to make major changes to KVM to make the non-VHE code actually work with VHE, and really nobody wants to do that just to mitigate this silly thing. Had this been a more dangerous flaw (e.g. with DoS or worse consequences), OSes would be scrambling to make major reworks right now to mitigate it in that way. macOS would have to turn its entire hypervisor design on its head. Possible, but not fun.
  - withinboredom 5y ago
    Are there any legal ramifications for them not following the spec?
marcan_42 5y ago
The implications are just that OSes that assume otherwise won't run; Linux used to work (by chance) until a patch that just about coincided with our project went in that used the non-VHE ("type 1") mode by default, which broke it, and then we had to add an explicit workaround for the M1. It's just a very unfortunate coincidence that precisely that support would allow this bug to be trivially mitigated on Linux. (Wouldn't help macOS, as they'd have to implement this from scratch anyway; it's just that existing OSes that support this mode could use it). The actual issue is just what I described: the hardware implementation of this register neglects to check for and reject accesses from EL0 (userspace). It's a chip logic design flaw. I don't know exactly where it is (whether in the core/instruction decoder, or in the cluster component that actually holds the register, depending on where they do access controls), but either way that's what the problem is.

m1keil 5y ago

This doesn't look like an issue that deserves its own website tbh.

floatingatoll 5y ago
The author agrees with you partway down the page.
pthariensflame 5y ago
I think that was the point. XD
jkaplowitz 5y ago
The content of the website basically makes that point itself. It's mocking the whole concept of these vulnerability websites, while also presenting a real (but not very impactful) vulnerability.
- m1keil 5y ago
  Oh, right. sorry, I sort of bailed on the whole FAQ thing when it was silly joke after joke but I get it now. It's the onion news of CVEs.
  - marcan_42 5y ago
    It's real though, The Onion is largely fake/jokes.
    - rswail 5y ago
      The Onion almost gave up in the 2016-2020 period because their satire was overtaken by the actual headlines.
      - mnw21cam 5y ago
        Ah, but did they write a story about that?

alberth 5y ago

ELI5, anyone. Are the chip registers not protected? What's the mechanism that's allowing this data sharing to happen?

peteretep 5y ago
> So what's the real danger? > If you already have malware on your computer, that malware can communicate with other malware on your computer in an unexpected way. > Chances are it could communicate in plenty of expected ways anyway.
josephcsible 5y ago
There's two bits of a CPU's register that are shared between all of its processes and that any process can write to. The result is that two sandboxed processes that are supposed to be totally isolated from each other can use this to communicate anyway. One example of how this can be exploited is cross-app tracking: if you told one app your name and another your location, they could secretly communicate with each other so both apps end up with both pieces of information.
- herpderperator 5y ago
  Why couldn't a future OS update add access control to these registers?
  - josephcsible 5y ago
    Because the CPU doesn't provide a practical means to do so.
    - herpderperator 5y ago
      Doesn't the kernel control CPU access?
      - kevingadd 5y ago

blendergeek 5y ago

My favorite part of the entire page: > So what's the point of this website? > Poking fun at how ridiculous infosec clickbait vulnerability reporting has become lately. Just because it has a flashy website or it makes the news doesn't mean you need to care. > If you've read all the way to here, congratulations! You're one of the rare people who doesn't just retweet based on the page title :-)

meowface 5y ago
In case anyone was confused by this comment: it's not a hoax/joke site. It's a real bug; just a low-severity one that's intentionally overhyped.
- lamontcg 5y ago
  Heh, I couldn't get through it because of the toxic levels of self promotion and was about to get very ranty about it all.
  - philbert101 5y ago
    Maybe you missed the disclaimer at the top? “CVE-2021-30747 Should you be worried? Probably not.”
    - lamontcg 5y ago
      Yes, I got that from the top comment here.

peteretep 5y ago

"So you're telling me I shouldn't worry? Yes."

sebmellen 5y ago

Actually not a bad song [0]. Thanks to whoever made this, I guess :D [0]: https://www.youtube.com/watch?v=i41KoE0iMYU https://www.youtube.com/watch?v=i41KoE0iMYU

marcan_42 5y ago
I had to use that one for this demo for obvious reasons, but if I'm allowed the shameless plug, I actually make my own music in the same genre (Touhou rearrangements) [0]. I'm actually very much looking forward to moving my music production to M1 and seeing what the real-time performance is like, though that will depend on us having at least a usable Rosetta-like thing on Linux to run x86 Windows apps (which will allow me to bridge the few x86 Windows plug-ins I rely on with yabridge, as I do today on x86) :-) [0] https://www.youtube.com/playlist?list=PL68XxS4_ek4afs0eXwRiYvMML5Y4OYWzx https://www.youtube.com/playlist?list=PL68XxS4_ek4afs0eXwRiY...
- sebmellen 5y ago
  Awesome! I'll take a listen and play it during my all-nighter tonight. Best of luck getting that M1 Mac working, I'm really liking mine so far!
- NobodyNada 5y ago
  That's awesome! I'm definitely thinking about getting an M1 for realtime keys, though I'm all set up in Logic/MainStage so I'll probably stick with macOS for now :) On the Linux side, would qemu user-mode emulation work for that (maybe with a patch to take advantage of the M1's switchable-memory-order thing)?
  - marcan_42 5y ago
    I think qemu would work fine, but it's pretty slow, so I'm hoping it can either be improved or another project more focused on this use case can do it better. If nothing else though, I plan to expose at least the TSO feature of the M1 so qemu can reduce the overhead of its memory accesses.
- 5y ago

kbenson 5y ago

Was this responsibly disclosed? I tried, but I also talked about it on public IRC before I knew it was a bug and not a feature, so I couldn't do much about that part. ¯\_(ツ)_/¯ This whole site is a good read. A great mix of real information, jokes, and a good send-up of how some security releases appear these days (I understand to a degree the incentives that cause those sites to be as they are, and I don't think they area all bad, but it's still good and useful to poke fun them I think).

vmception 5y ago

well this is a new genre of satire

Rantenki 5y ago

I've been stumbling through writing a pile of secure software development lifecycle management and disclosure practices documentation all evening, and desperately needed a bit of levity. This post delivered. Thank you. Also, I am still not sure if this is a disclosure, performance art, or extremely dry comedy, but it certainly covered all the bases.

__d 5y ago

> Newton OS users: I guess those are technically Apple Silicon but... The Newton wasn't really Apple Silicon: The OMP/MP100/MP110/MP120/MP130 ran an ARM610. The eMate300 ran an ARM710. The MP2000/MP2100 ran a DEC StrongARM SA-110 CPU. None of which were designed or manufactured by Apple.

phire 5y ago
At the time, Apple owned 50% of ARM. ARM, the company only existed because Apple wanted them to manufacture a CPU for it's Newton project. While Apple might not have designed the ARM610, but they technically owned it.
- __d 5y ago
  I did say "designed or manufactured" ... but I'll concede the point that they had some ownership of the 610/710, at least. On 27 Nov 1990, ARM was formed with Apple owning 43% alongside Acorn (the designer), and VLSI Technology (the manufacturer). Funny thing: I've found two articles that claim two different purchase prices for that 43%: one $3M [0] and the other $1.5B [1]. That's quite a difference! [0] https://appleinsider.com/articles/20/06/09/how-arm-has-already-saved-apple---twice https://appleinsider.com/articles/20/06/09/how-arm-has-alrea... [1] https://www.cultofmac.com/97055/this-is-how-arm-saved-apple-from-going-bust-1990s/ https://www.cultofmac.com/97055/this-is-how-arm-saved-apple-...
- klelatti 5y ago
  > At the time, Apple owned 50% of ARM. Nope, Apple never owned 50% of ARM. > ARM, the company only existed because Apple wanted them to manufacture a CPU for it's Newton project. Who knows what would have happened had Apple not invested but Apple was never ARM's only customer. > While Apple might not have designed the ARM610, but they technically owned it. If I own some Apple shares reasonably sure that doesn't mean that "technically" I own the M1.
deleted 5y ago
[deleted]
tonyedgecombe 5y ago

deleted 5y ago

[deleted]

slver 5y ago

> If you already have malware on your computer, that malware can communicate with other malware on your computer in an unexpected way. > Chances are it could communicate in plenty of expected ways anyway. This site is basically if Douglas Adams instead had a career in security research.

robertlagrant 5y ago
I still think Apple Watches are a pretty neat idea.

xucheng 5y ago

Given M1 is in iPad Pro now, I think there could will be Apps seriously exploiting this to circumvent Do No Track in iOS 14.5.

edgyquant 5y ago
How? They’d have to communicate with an app that does have those permissions
- xucheng 5y ago
  At the core, DO NOT TRACK prevents Apps having access to the Advertising Identifier. So different Apps cannot aggregate their analytics data about the users. This vulnerability enables different Apps to communicate a super cookie for cross-app tracking. A possible exploit would be to implement this feature in an AD SDK to be used by different Apps.
  - intricatedetail 5y ago
    But does it actually do anything? Apps can surely identify users by other means, e.g. IP, behaviour...
marcan_42 5y ago
Thankfully, Apple should be able to statically analyze apps to look for this on App Store submission, as the App Store does not allow dynamic code (JITs).

denysvitali 5y ago

> I came here from a news site and they didn't tell me any of this at all! > > Then perhaps you should stop reading that news site, just like they stopped reading this site after the first 2 paragraphs. Marcan is a genius, in every aspect. He is on my top list of people I could read all day long without getting annoyed. Pretty much everything he posts on Twitter is interesting and curious. I'm a huge fan! The other person I have similar feelings for is Geohot. These guys are really, really smart.

xmprt 5y ago
I also really liked this line > Wait. Oh no. Some game developer somewhere is going to try to use this as a synchronization primitive, aren't they. Please don't. The world has enough cursed code already. Don't do it. Stop it. Noooooooooooooooo
- ohazi 5y ago
  m1racle-mutex: https://twitter.com/LunaFoxgirlVT/status/1397441284487401478?s=19 https://twitter.com/LunaFoxgirlVT/status/1397441284487401478...
hans1729 5y ago
>The other person I have similar feelings for is Geohot. These guys are really, really smart. Its ok George, we love you and you know it
soedirgo 5y ago
> The other person I have similar feelings for is Geohot. I don't know about that... https://news.ycombinator.com/item?id=25679907 https://news.ycombinator.com/item?id=25679907
- comboy 5y ago
  You gave denysvitali some serious cognitive dissonance.
  - 5y ago

tyingq 5y ago

I suppose you could use it to create a "covert suite" of apps for the M1 iPad that talk to each other where they aren't supposed to. Sharing permission X from app 1 with app 2 that isn't supposed to have permission X, etc.

marcan_42 5y ago
Thankfully Apple can, in principle, statically analyze for this on the iOS App Store, as they do not allow JIT mappings on those devices.
- e_proxus 5y ago
  Can they guarantee no JIT code via static analysis as well? Or could someone sneak in a tiny bit of disguised JIT code just to get to this register? I would assume a huge JITed VM implementation would show up easily in analysis.
  - phire 5y ago
    They don't provide anyway to mark memory as executable.
    - saagarjha 5y ago
      Well, they do, because they have to run your code :P You just can't make a new page of code and mark it executable.
      - marcan_42 5y ago
        The OS only makes pages executable if they come from a signed app. There is no way for the app itself to do that.
        saagarjha 5y ago
        If it makes it more clear, my comment was mostly "if your code page has a valid signature you can mark it as executable".

vignesh_warar 5y ago

>I came here from a news site and they didn't tell me any of this at all! >Then perhaps you should stop reading that news site, just like they stopped reading this site after the first 2 paragraphs. This is my most favorite

bradleybuda 5y ago

Could this be fixed with a microcode update (he asks, not really having any idea what microcode is)?

Operyl 5y ago
Does the M1 even have microcode updates? I haven't seen anything pointing to that yet.
- marcan_42 5y ago
  I don't think so, no. If it has microcode it's probably burned into sequencer tables, not updatable. I was kind of hoping Apple would have some chicken bit register up their sleeve as a last resource fix (e.g. "trap on instruction encodings matching this mask"), but given that they seem to have no useful mitigation for it, I don't think they do.
  - londons_explore 5y ago
    Is it possible Apple have the silicon functionality to fix this, but have decided it isn't worth fixing? After all, process isolation between cooperating processes is nearly impossible to do. If Apple close this loophole, there will be other lower bandwidth side channels like spinning up the fan in Morse code and the other process notices the clock speed scaling up and down...
    - marcan_42 5y ago
      It doesn't really make sense not to fix it if they can in fact do so easily.
      - londons_explore 5y ago
        Except software-silicon patches usually have a limited number of filters, patch slots, etc. Might not be worth using one for this.

planb 5y ago

This is the best thing I've seen on the internet for a long time. Hopefully some people (tech journalists and twitter folks) will "fall for it" and learn along the way...

thysultan 5y ago

Sounds like a killer feature. They're going to announce this at wwdc21.

mxcrossr 5y ago
No definitely a big, but I expect that they will announce the swarm of nanobots they plan to release to fix all the affected chips.

gostsamo 5y ago

> Am I affected? > • OpenBSD users: Hi Mark! Yes, "Hi Mark", whoever you are and no matter that I'm not an OpenBSD user.

psy-q 5y ago
I took it as a reference to The Room. Isn't it? :|
- gostsamo 5y ago
  I'm not aware of the referenced material. :)
  - meowface 5y ago
    https://www.youtube.com/watch?v=ZdzmKwKN3n8 https://www.youtube.com/watch?v=ZdzmKwKN3n8
  - psy-q 5y ago
    Oooo! Depending on your taste you're in for either a very boring movie or the experience of a lifetime. Complete with an associated rabbit hole of mystery surrounding the director: https://en.wikipedia.org/wiki/The_Room https://en.wikipedia.org/wiki/The_Room If you do end up watching and liking it, there is book and a film about the filming of the film to enjoy :D https://en.wikipedia.org/wiki/The_Disaster_Artist https://en.wikipedia.org/wiki/The_Disaster_Artist
  - gostsamo 5y ago
    Thanks both of you for the info.
delroth 5y ago
Context: Mark Kettenis has been porting OpenBSD to the M1 SoC, and is probably the only current user of that code.
- marcan_42 5y ago

tectonic 5y ago

> Wait. Oh no. Some game developer somewhere is going to try to use this as a synchronization primitive, aren't they. Please don't. The world has enough cursed code already. Don't do it. Stop it. Noooooooooooooooo

galgalesh 5y ago
Cross-core communication without going through the kernel seems like a very useful performance feature for games. Am I missing something or is it somewhat likely this will be "abused" by games?
- lilyball 5y ago
  This thing communicates at 1MB/s. A “performance feature” it ain’t.
  - deleted 5y ago
    [deleted]
  - dijit 5y ago
    throughput and latency are different measures. Games usually live in the realm of latency.
    - passivate 5y ago
      That begs the question, what is the latency, and what kind of feature would you anticipate this could be useful for?
  - mukesh610 5y ago
    Synchronization primitives AFAIK don't need to transfer huge amounts of data in a short time. One bit for every "okay" signal would suffice. At the given speed you can perform 8 million syncs per second between two threads.
  - smoldesu 5y ago
    who cares, it's not like you're going to use it to send textures from one thread to another

0xakhil 5y ago

How about randomising/reset these bits from kernel whenever there is a syscall? Not a great workaround but this should limit the effectiveness of leaking. Yeah, there will be tiny perf hit due to extra register read and write.

NobodyNada 5y ago
> Wait, didn't you say on Twitter that this could be mitigated really easily? > Yeah, but originally I thought the register was per-core. If it were, then you could just wipe it on context switches. But since it's per-cluster, sadly, we're kind of screwed, since you can do cross-core communication without going into the kernel. Other than running in EL1/0 with TGE=0 (i.e. inside a VM guest), there's no known way to block it. In other words: this register is shared between cores, so if the two processes are running simultaneously on different cores, they can communicate by reading & writing directly to & from this register, without any operating system interaction.
CJefferson 5y ago
Unfortunately, you can use this to send thousands of bits between syscalls, so the simplest error correction would fix that, with very little effort or overhead.
- marcan_42 5y ago
  The demo already uses error correction (I'm not sure exactly what causes the errors, but I'm guessing the processes sometimes end up briefly scheduled on the other core cluster)

fulafel 5y ago

> It violates the OS security model. You're not supposed to be able to send data from one process to another secretly. I'd argue this is not the case. What mainstream operating systems have made credible attempts to eliminate covert channels from eg timing or resources that can be made visible by cooperating processes across user account boundaries?

londons_explore 5y ago
Indeed. Without this vulnerability, there would still be a million ways to send data between cooperative processes running as different users on Mac OS X. For example, a process could start subprocesses at a deterministic rate and the other end of the covert link observes how fast the pid counter is going up. This is a non-vulnerability, because it targets something there was no effort to protect.
- Cthulhu_ 5y ago
  It's not really a vulnerability as the FAQ states, but it violates the operating system's own application isolation policies. If you don't want your Facebook app to talk to your Instagram app (e.g. different accounts for different purposes), you should be able, as a user, to block communication between the two. This is a backdoor to circumvent that. I mean not that anyone has a native Facebook or Instagram app on their device, but just to name an example.
  - vbsteven 5y ago
    > I mean not that anyone has a native Facebook or Instagram app on their device, but just to name an example. The M1 is used in the iPad Pro so your example is definitely possible. (or your comment was sarcasm in which case: woosh to myself)
angrygoat 5y ago
Yes, exactly. Multics actually tried, here's a memo from 1974 discussing the issue: https://multicians.org/mtbs/mtb696.html https://multicians.org/mtbs/mtb696.html Paged shared libraries, signalling by ramping up and down CPU usage, there are an enormous number of possible covert channels.

deleted 5y ago

[deleted]

Sparkyte 5y ago

Real? I'm confused by a particular infosec quote.

afandian 5y ago

Sorry if I missed it, but what is the defined purpose of the s3_5_c15_c10_1 register? Or is it just general purpose?

Cthulhu_ 5y ago
I googled it for you and err, came up blank, there's just two code references in some ASM code, the rest points to this resource. Weird, I would have thought things like this would have public documentation.
- pthariensflame 5y ago
  https://news.ycombinator.com/item?id=27287519 https://news.ycombinator.com/item?id=27287519
pthariensflame 5y ago
It’s not a standard ARM register; it’s implementation-defined and nobody gave it a meaningful name. It appears to do nothing much.
- exikyut 5y ago
  Then why not unofficially standardize its use in GCC and Clang's register-pooling subsystem?
  - saagarjha 5y ago
    Because GCC and Clang don't get to decide what hardware does with the register…
marcan_42 5y ago
It's an implementation-defined register, which means it's up to Apple to define it. We have no idea what it does; we haven't observed any visible effects from flipping those bits. Given that it's per-cluster, we can infer that it has something to do with cluster-specific logic. Perhaps memory interface or power control. There are hundreds of Apple implementation-defined registers; we're documenting them as we learn more about them [0] [1] [2] [0] https://github.com/AsahiLinux/m1n1/blob/main/tools/apple_regs.json https://github.com/AsahiLinux/m1n1/blob/main/tools/apple_reg... [1] https://github.com/AsahiLinux/docs/wiki/HW%3AARM-System-Registers https://github.com/AsahiLinux/docs/wiki/HW%3AARM-System-Regi... [2] https://github.com/AsahiLinux/docs/wiki/HW%3AARM-System-Registers-Dumps https://github.com/AsahiLinux/docs/wiki/HW%3AARM-System-Regi...

Woodi 5y ago

Wait, did he just, as exploit proof of concept, infiltrated some catch music&&video clip ? With life rendering on same CPU ? :> Anyway - Apple did it again ! In shiny, new hardware for "creative" ppl introduced hardware backdors... Like FireWire and Thunderbird. Seriously, there must be some market for spying on writers and painters. Or anyone who do thing and is rich...

exikyut 5y ago
Bad Apple goes much deeper than that. IMHO this pretty much retires it.

umanghere 5y ago

While Marcan has written in a very entertaining fashion, there is perhaps one application of this vulnerability that wasn't considered. If this can be reproduced on the iPhone, it can lead to 3rd party keyboards exfiltrating data. By default, keyboard app extensions are sandboxed away from their owning applications [0], but they may communicate with the app over this channel and leak data. It's not as easy as I describe because the app would have to be alive and scheduled on the same cluster, but it's within the realm of possibility. [0]: https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/CustomKeyboard.html https://developer.apple.com/library/archive/documentation/Ge...

gostsamo 5y ago
IPhones use A12/13/14 chip and the vulnerability is not confirmed there. Also, the post mentions that if you have two malware apps on your device, they can communicate in many other ways, so I'm not sure what's new here. Edit: fixed name of the chip.
- umanghere 5y ago
  iPhones do not use the A1 chip as of quite a few years ago. Besides, the M1 and the A12+ have significant microarchitectural similarities, to the point that the DTK used the A12Z. Furthermore, the keyboard app extension and the keyboard app are installed as a single package whose components are not supposed to communicate, hence why I brought this up.
  - gostsamo 5y ago
    The only 1 in the name of the chip is typo. The rest I'm still not sure if it is significant.
  - dfox 5y ago
    I believe that only significant difference between A14 and M1 (apart from package) is number of cores.
- Closi 5y ago

wejkfwe 5y ago

So, all the great performance of M1 was achieved due to the poor security?

saagarjha 5y ago
They are entirely unrelated.

martini333 5y ago

That demo made me vomit

withinboredom 5y ago

I was actually planning to pick up a new Mac today and I’ve been on the fence over M1 or Intel for months. My biggest con for the M1 is how proprietary it is. With Intel, you know it’s been battle-tested for years. Things like this (at best, is an oversight, at worst, it’s the tip of the iceberg) make the decision a little bit easier…

rvz 5y ago
Don't know why you've been downvoted. It all depends on the software that you use everyday (job or whatever). If the software does not run on an M1 Mac or requires involved workarounds to get it 'working' and it breaks on any update or it prevents you from doing your work, then don't waste your time and just skip it for now. Also wait until WWDC, like I said before.
user-the-name 5y ago
Intel chips are chock full of these same kinds of mistakes.
filleduchaos 5y ago
> With Intel, you know it’s been battle-tested for years. This is quite an interesting statement to make in the wake of Spectre and Meltdown (and vulnerabilities in that class being discovered what seems like every couple of months or so). It's a bit amusing to me how much we overlook clear, even huge flaws in products and processes because they're old - sorry, Battle-Tested™ - while zeroing in on lesser flaws in newer ones.

volta83 5y ago

> in violation of the ARM architecture specification > Apple decided to break the ARM spec by removing a mandatory feature Is there a page documenting all incompatibilities / violations of the ARM architecture specification by the M1?

saagarjha 5y ago
I wouldn't be surprised if the language gets loosened in the next revision of the standard, as it has in the past.

1f60c 5y ago

> Was this responsibly disclosed? > > I tried, but I also talked about it on public IRC before I knew it was a bug and not a feature, so I couldn't do much about that part. ¯\_(ツ)_/¯ That seems... unwise to admit publicly.

fnord77 5y ago

nazgulsenpai 5y ago

> OpenBSD users: Hi Mark! Ok I nearly fell out of my chair. A+

ncr100 5y ago

Is the risk that malicious software can be split into multiple, obfuscated components? Without such a silicon vulnerability the malicious process would need all its components within a single process/image?

apetresc 5y ago

Out of curiosity, which public IRC channel was this being discussed in, before it was understood to be a bug? That sounds like a fun channel.

apetresc 5y ago
Ah, looking more into it, I'm going to guess it was #asahi or #asahi-dev.
- marcan_42 5y ago
  Yup, here's the log if you're curious :-) https://oftc.irclog.whitequark.org/asahi/2021-02-24#29220558 https://oftc.irclog.whitequark.org/asahi/2021-02-24#29220558

pokot0 5y ago

It seems like a single bit available to all apps but that no one is really using now. I wonder if a easy software mitigation could be just polluting it intentionally.

notaplumber 5y ago

> "OpenBSD users: Hi Mark!" This is Mark Kettenis, who has despite comments made jokingly by marcan, been working with a few other OpenBSD developers to bring-up OpenBSD/arm64 on the Apple M1. At least on the Mac Mini the Gigabit Ethernet works, Broadcom Wi-Fi, and work on the internal NVMe storage is progressing. There was an early teaser dmesg posted in Feburary showing OpenBSD booting multi-user (on bare metal): https://marc.info/?l=openbsd-arm&m=161386122115249&w=2 https://marc.info/?l=openbsd-arm&m=161386122115249&w=2 Mark has also been adding support for the M1 to the U-Boot project, which will not only benefit OpenBSD, but also Asahi Linux. Another OpenBSD developer posted these screenshots and videos on Twitter. https://twitter.com/bluerise/status/1359644736483655683 https://twitter.com/bluerise/status/1359644736483655683 https://twitter.com/bluerise/status/1354216838406823936 https://twitter.com/bluerise/status/1354216838406823936

Simplicitas 5y ago

I wish all CVE were written this way :-)

ulzeraj 5y ago

I love the choice of music. Very appropriate.

2OEH8eoCRo0 5y ago

Security through obscurity + walled garden. Brilliant move.

deleted 5y ago

[deleted]

Iv 5y ago

> So what's the point of this website? > Poking fun at how ridiculous infosec clickbait vulnerability reporting has become lately. Just because it has a flashy website or it makes the news doesn't mean you need to care. > If you've read all the way to here, congratulations! You're one of the rare people who doesn't just retweet based on the page title :-)

ddtaylor 5y ago
That's reassuring to read. I opened the page, read a bit of it, pressed play on the video and scrubbed around a bit, got irritated and closed the tab. I figured if it mattered I would wait until better coverage came out.

addaon 5y ago

It seems like there's a partial mitigation available to the OS here. When scheduling a task, write a random value to the two user-writable bits. When the task is unscheduled, if the bits do not match, terminate the task. This effectively makes writing to the register an OS-enforced illegal operation with a 75% chance of being caught within 10 ms if the channel is being used at full bandwidth. (The writer can reduce the chance of it being caught proportional to reduced use of channel bandwidth by resetting it to the OS-chosen value after a bit is transmitted.) The reader can't be detected this way, but since the channel requires cooperation between the writer and reader, catching either is fine. Not a perfect fix, but would help, and would also give visibility into whether this is used in the wild -- e.g., report to Apple via crash reporting mechanism if a process is terminated this way, which would allow prompt discovery of app store apps that abuse the channel.