Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No More Blue Fridays

brendangregg.com

Post reply on HN
Print view View original

271–280 of 282 posts

Re: No More Blue Fridays

#271

Post by philistine »

nullindividual wrote: post #106
philistine wrote: post #99

Earlier quoted context omitted.

Apple took the lead on this front. It has closed easy access to the kernel by apps, and made a list of APIs to try and replace the lost functionality. Anyone maintaining a kernel module on macOS is stuck in the past. Of course, the target area of macOS is much smaller than Windows, but it is absolutely possible to kick all code, malware and parasitic security services alike, from accessing the kernel. The safest kern…

I don't think Microsoft has a choice with regards to kernel access. Hell, individuals currently use undocumented NT APIs. I can't imagine what happens to backwards compat if kernel access is closed. Apple's closed ecosystem is entirely different. They'll change architectures on a whim and users will go with the flow (myself included).

See Satya Nadella has recently said that Microsoft will now put security above any other value at Microsoft. He specifically even singled out backwards compatibility.

https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...

Microsoft is a big boat. It takes a long time to turn if the captain orders it. But the captain has ordered it. I expect the sacrosanct nature of back compat to eventually die. Windows will never turn into the moving target that macOS is, but I expect a lot of old stuff to just stop working, when security concerns dictate they should be removed.

Re: No More Blue Fridays

#272

Post by nkozyra »

olddustytrail wrote: post #224
nkozyra wrote: post #221

Earlier quoted context omitted.

Can you elaborate? What I see about Linux is that Crowdstrike was in the process of adopting eBPF which is ostensibly immune to kernel panics, but that issue shows their eBPF implementation specifically causing a kernel panic.

Yes, the elaboration is that the same link you posted is included in the article you're supposed to have just read.

I've read it three times now. The only thing they say about it is this:

"This doesn't mean that eBPF has solved nothing, substituting a vendor's bug for its own. Fixing these bugs in eBPF means fixing these bugs for all eBPF vendors, and more quickly improving the security of everyone."

Which is exactly what I'm asking about. If eBPF has some inherent advantage, why did it fail in precisely the same way alreay?

Re: No More Blue Fridays

#273

Post by WatchDog »

stackskipton wrote: post #74
shahahqq wrote: post #38

Earlier quoted context omitted.

I hope though that Microsoft will double down on their eBPF support for Windows after this incident.

Doubt it. Microsoft is clearly over Windows. They continue to produce it but every release feels like "Ugh, fine, since you are paying me a ton of money." Internally, Microsoft is running more and more workloads on Linux and externally, I've had .Net team tell me more than once that Linux is preferred environment for .Net. SQL Server team continues to push hard for Linux compatibility with every release. EDIT: Window…

SQL Server has supported Linux since 2017

Re: No More Blue Fridays

#274

Post by amluto »

School-Cotton wrote: post #261
amluto wrote: post #252

> In the future, computers will not crash due to bad software updates, even those updates that involve kernel code. In the future, these updates will push eBPF code. eBPF is fantastic, and it can be used for many purposes and improve a lot of things, but this is IMO overselling it. Assuming that BPF itself it free of bugs, it’s still a rather large sprawl of kernel hooks, and those hooks invoke eBPF code, which can c…

How is it possible to panic using bpf_probe_read_kernel ? Can you give an example that works on the current kernel version?

I'm not sure that "panic" is the right word here. bpf_probe_read_kernel boils down to copy_from_kernel_nofault, which checks for an "allowed" address and then does the access. Any page faults turn into error returns instead of OOPSes. x86 disallows user addresses, the vsyscall page, and non canonical addresses.

Doing this from bpf assumes that all "allowed" addresses are side-effect-free and will either succeed or cleanly fault. Off the top of my head, MMIO space (including, oddities like the APIC page on CPUs that still have that) and TDX memory are not in this category.

Re: No More Blue Fridays

#275

Post by another2another »

kjellsbells wrote: post #227

Lets suppose that eBPF solves this particular problem, eventually, for Windows. Doesn't sidestepping the entire class of Crowdstrike-style fubars require that Microsoft then mandate that no, backward compatibility will not be offered? Back compat seems to be such a shibboleth in the Windows world, but comes at an incredible price. The reasons cited all seem to boil down to keeping some imagined customers' obscure LOB…

>Surely Microsoft would like to shake out the last diehards running some VB5 app on a patched up PC in a factory. >Isn't it more beneficial to everyone to start sunsetting acres of ancient NT code and approaches and streamline the entire attack surface?

If your code somehow still relies on some buggy behaviour to work, then MS shouldn't do anything to preserve that anymore - apparently they used to, but I'm not so sure nowadays.

However 'ancient NT' code should probably still function just fine since the Win32 API hasn't changed much for a while, and MS don't actively deprecate function calls (unlike Apple who seem to do it a bit on a whim recently). I would put this down to the API being pretty well designed in the first place.

Re: No More Blue Fridays

#276

Post by jolux »

tptacek wrote: post #217
Analemma_ wrote: post #210

Earlier quoted context omitted.

This is a weird reading of history. Microsoft has spent tons of effort getting as much code out of the kernel as possible: Windows drivers used to be almost all kernel-mode, now they're nearly all in userspace and you almost never need to write a kernel-mode Windows driver unless you're doing something with deep OS hooks (like CS was, although apparently even that wasn't actually necessary). The safeguards on kernel…

A thing I think a lot of people don't include in their premises about Crowdstrike is that they're probably the most significant aftermarket endpoint security product in the world (they are what Norton and McAfee were in 2000), which means they're more than large enough for malware to target their code directly, which creates interesting constraints for where their code can run. I'm not saying I'd run it (I would not)…

> I'm not saying I'd run it (I would not), just that I can see why they have a lot of kernel-resident code.

What would you run instead, or is there a different way of thinking about the problem it addresses that obviates the need?

Re: No More Blue Fridays

#277

Post by titzer »

rapidlua wrote: post #251
titzer wrote: post #198

WebAssembly is a better choice for sandboxing kernel code. It has a full formal specification with a mechanized proof of type safety, many high-performance implementations, broad toolchain support, is targetable from many languages, and a capability security model.

Hardly. For starters, wasm doesn’t guarantee that a piece of code terminates in bound time. There are further security guarantees in ebpf such as any lock acquired must be released.

You can apply additional static checks to Wasm, e.g. control flow analysis, and reject programs without obvious loop bounds or unbalanced locking operations. Or you could apply dynamic techniques like tracking acquired locks and automatically releasing them, or charging fuel (gas). The latter is quite common for blockchain runtimes based on Wasm.

Re: No More Blue Fridays

#278

Post by ninju »

So a couple of questions

1) Is CrowdStrike Falcon using eBPF for their Linux offering?

2) Would the faulty patch update get caught by the eBPF verifier?

Re: No More Blue Fridays

#279

Post by nequo »

CodeWriter23 wrote: post #225
nequo wrote: post #118

Earlier quoted context omitted.

It is an outage for the monitoring system, not the system that it monitors.

I think a reasonable protocol is to stop using any apps when your cyber protection crashes. Why have that suite at all otherwise?

I agree for some systems. For others, stopping the system has bigger consequences than not having cyber protection for a few hours because of a bug that’ll get fixed. For example, hospitals, or possibly Delta Airlines.

Re: No More Blue Fridays

#280

Post by fsflover »

jolux wrote: post #276
tptacek wrote: post #217

Earlier quoted context omitted.

A thing I think a lot of people don't include in their premises about Crowdstrike is that they're probably the most significant aftermarket endpoint security product in the world (they are what Norton and McAfee were in 2000), which means they're more than large enough for malware to target their code directly, which creates interesting constraints for where their code can run. I'm not saying I'd run it (I would not)…

> I'm not saying I'd run it (I would not), just that I can see why they have a lot of kernel-resident code. What would you run instead, or is there a different way of thinking about the problem it addresses that obviates the need?

Not the parent, but security through compartmentalization seems like a more robust approach. See: Qubes OS.
Post reply on HN