fwiw apple shouldn't boast that macs are inherently more reliable than windows machines.

every time you update your computer you run the risk of bricking the machine.

macs are just as vulnerable to this as windows machines.

a better approach imho would be to offer to help microsoft and otherwise stfu.

@davew but the issue is that both Microsoft and Apple have procesees in place to avoid this scenario. CrowdStrike didn’t.

In Apple’s case, they have been working to force people out of the kernel for years, infuriating developers and ISVs, but Microsoft appeased them.

And given this, CrowdStrike-class bugs on MacOs would merely crash a user process, but brings down the system on windows.

@Migueldeicaza @davew More details specifically on Crowdstrike moving its macOS implementation off of kernel and into user space (in 2020):

https://www.crowdstrike.com/blog/crowdstrike-supports-new-macos-big-sur/

CrowdStrike Supports New macOS Big Sur

The CrowdStrike Falcon® platform offers full support for Big Sur with full-feature parity and protection.

crowdstrike.com
@michaelgemar @davew oh thank you for sharing this link! Very detailed on what macOS forced people to do.

@michaelgemar @Migueldeicaza @davew Oh, so both macOS and Linux have support for running these security tools entirely in userspace (Linux has eBPF, and CrowdStrike supports it in their user mode installation).

So this issue really is unique to Windows, where the only way to do this is with a kernel driver that has the possibility of bricking your machine.

@unlambda @michaelgemar @davew i am not sure if Linux fully has it, but CrowdStrike bricked Linux servers last month with a similar problem:

https://access.redhat.com/solutions/7068083

Same one for Debian systems in April:

https://news.ycombinator.com/item?id=41005936

Kernel panic observed after booting 5.14.0-427.13.1.el9_4.x86_64 by falcon-sensor process. - Red Hat Customer Portal

eBPF program causes kernel panic on kernels 5.14.0-410+ . Below is an example of a kernel panic on the falcon-sensor process, observed after booting on kernel version 5.14.0-427.13.1.el9_4.x86_64. [ 462.396258] BUG: unable to handle page fault for address: ffff9a4bdb0f2d88 [ 462.396291] #PF: supervisor write access in kernel mode [ 462.396309] #PF: error_code(0x0002) - not-present page [ 462.396327] PGD 14e203067 P4D 14e203067 PUD 0 [ 462.396345] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 462.397204] CPU: 1 PID: 6496 Comm: falcon-sensor-b Kdump: loaded Not tainted 5.14.0-427.13.1.el9_4.x86_64 #1 [ 462.397838] Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference Platform, BIOS VMW71.00V.21100432.B64.2301110304 01/11/2023 [ 462.398482] RIP: 0010:backtrack_insn+0x408/0x800 [ 462.399131] Code: 30 00 0f 85 64 fd ff ff 41 ba 01 00 00 00 b9 01 00 00 00 45 8d 48 ff 44 89 d0 d3 e0 85 c2 74 0f 89 c6 f7 d6 21 d6 89 74 bb 0c 09 44 8b 0c 83 c1 01 83 f9 06 0f 84 71 01 00 00 44 89 d0 8b 54 [ 462.400531] RSP: 0018:ffffbdf980977a80 EFLAGS: 00010246 [ 462.401231] RAX: 0000000000000002 RBX: ffff9a47db0f2d80 RCX: 0000000000000001 [ 462.401937] RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 [ 462.402631] RBP: ffff9a47db0f0000 R08: 0000000000000000 R09: 00000000ffffffff [ 462.403325] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000058 [ 462.404026] R13: ffff9a47db0f0a90 R14: ffff9a47ea2f6000 R15: ffffbdf982a5f300 [ 462.404722] FS: 00007f8228020740(0000) GS:ffff9a48b5e40000(0000) knlGS:0000000000000000 [ 462.405432] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 462.406152] CR2: ffff9a4bdb0f2d88 CR3: 000000012b41a000 CR4: 00000000003506e0 [ 462.406901] Call Trace: [ 462.407611] [ 462.408306] ? srso_return_thunk+0x5/0x5f [ 462.408999] ? show_trace_log_lvl+0x26e/0x2df [ 462.409686] ? show_trace_log_lvl+0x26e/0x2df [ 462.410372] ? __mark_chain_precision+0x166/0x630 [ 462.411058] ? __die_body.cold+0x8/0xd [ 462.411742] ? page_fault_oops+0x134/0x170 [ 462.412429] ? srso_return_thunk+0x5/0x5f [ 462.413135] ? kernelmode_fixup_or_oops+0x84/0x110 [ 462.413823] ? exc_page_fault+0xa8/0x150 [ 462.414512] ? asm_exc_page_fault+0x22/0x30 [ 462.415210] ? backtrack_insn+0x408/0x800 [ 462.415909] ? copy_array+0x4d/0xb0 [ 462.416621] ? __pfx_verbose+0x10/0x10 [ 462.417321] ? __pfx_disasm_kfunc_name+0x10/0x10 [ 462.418023] __mark_chain_precision+0x166/0x630 [ 462.418725] check_cond_jmp_op+0x738/0xbd0 [ 462.419432] ? is_state_visited+0x450/0x740 [ 462.420157] do_check+0x85b/0xac0 [ 462.420854] do_check_common+0x2a9/0x340 [ 462.421566] bpf_check+0xf7c/0x10a0 [ 462.422250] ? srso_return_thunk+0x5/0x5f [ 462.422929] ? __kmem_cache_alloc_node+0x1c7/0x2d0 [ 462.423578] ? __x86_indirect_jump_thunk_r15+0x20/0x5e [ 462.424234] bpf_prog_load+0x636/0x970

Red Hat Customer Portal
@Migueldeicaza @unlambda @michaelgemar @davew If I understand correctly, their older version had a kernel driver, the newer one uses ebpf, because the needed hooks weren't present in older kernels. I'm sure someone will correct me if I got that wrong.

@Migueldeicaza @davew And, as a follow up, although it does appear that one still *can* install kernel extensions on the latest versions of macOS, the process is *quite* complex (and clearly not suitable for mass deployment):

https://www.sweetwater.com/sweetcare/articles/kernel-extensions-on-mac-with-apple-silicon/

@michaelgemar @davew yes they still have some, they have been gradually moving kernel features to user space bridges and removing the kernel features. This process started a few years back and is going to take a few more to be complete.

This last two years they did file systems.

On the CrowdStrike case, they fully moved to user space on macOS

@Migueldeicaza @michaelgemar @davew I think the timing of the CrowdStrike incident is interesting when you consider current world events. This is happening in the context of several different wars in which I can imagine cyber attacks eventually being used. We are actually kinda lucky that we had this very visible attack that seems mostly harmless.