No More Blue Fridays • Hacker News Board

Re: No More Blue Fridays

#151

Post by dwattttt » Mon, Jul 22, 2024, 4:20 PM UTC

remram wrote: post #148

benfortuna wrote: post #102

Earlier quoted context omitted.

Keep in mind they don't just allow any old code to execute in the kernel. They do have rigorous tests (WHQL), it's just Crowdstrike decided that was too burdensome for their frequent updates, and decided to inject code from config files (thus bypassing the control). The fault here is entirely with Crowdstrike.

How rigorous are the tests if faulty data can brick the machine?

Not rigorous enough to have detected this flaw in the kernel sensor, although effectively any bug in this situation (an AV driver) can brick a machine. I imagine WHQL isn't able to find every possible bug in a driver you submit to them, they're not your QA team.

Re: No More Blue Fridays

#152

Post by odo1242 » Mon, Jul 22, 2024, 4:23 PM UTC

Xunjin wrote: post #100

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…

> The safest kernel is the one that cannot be touched at runtime. Can you expand what you mean here? Because depending on the application you are running, you will need at least talk with some APIs to get privileged access?

Yeah, Apple doesn’t allow any user code to run in kernel mode without significant hoops (the kernel is code signed) and tries to provide a user space API (e.g. DriverKit) as an alternative for the missing functionality.

Some things (FUSE) are still annoying though.

Re: No More Blue Fridays

#153

Post by School-Cotton » Mon, Jul 22, 2024, 4:27 PM UTC

rwmj wrote: post #144

School-Cotton wrote: post #120

Earlier quoted context omitted.

eBPF programs cannot crash the kernel, assuming there are no bugs in the eBPF verifier. There have been such bugs in the past but they seem to be getting more and more rare.

This isn't really true. eBPF programs in Linux have access to a large set of helper functions written in plain C. https://lwn.net/Articles/856005/

I don't see how this contradicts what I said. Indeed, there are helpers, but the verifier is supposed to check that the eBPF program isn't calling them with invalid arguments.

Re: No More Blue Fridays

#154

Post by mirashii » Mon, Jul 22, 2024, 4:27 PM UTC

kevin_nisbet wrote: post #52

I hate to dispute with someone like Brendan Gregg, but I'm hoping vendors in this space take a more holistic approach to investigating the complete failure chain. I personally tend to get cautious when there is a proposal that x will solve the problem that occurred on y date, especially 3 days after the failure. It may be true, but if we don't do the analysis we could leave ourselves open to blindspots. There may als…

Just because you have not been aware of the discussions on this topic that have been happening for years, doesn't mean that they haven't been happening. This isn't some new analysis formed 3 days after an incident, this is the generally accepted consensus among many experts who have been working in the space, introducing these new APIs specifically to improve stability, security, etc. of systems.

Re: No More Blue Fridays

#155

Post by nullindividual » Mon, Jul 22, 2024, 4:28 PM UTC

becurious wrote: post #143

nullindividual wrote: post #106

Earlier quoted context omitted.

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).

But Apple doesn’t have the industrial and commercial uses that Linux and Windows have. Where you can’t suddenly switch out to a new architecture without massive amounts of validation costs. At my previous job they used to use Macs to control scientific instrumentation that needed a data acquisition card. Eventually most of the newer product lines moved over to Windows but one that was used in a validated FDA regulate…

> validated FDA regulated environment stayed on the Mac

Given how long it takes to validate in a GxP environment, and the cost, this makes sense.

Re: No More Blue Fridays

#156

Post by jkrejcha » Mon, Jul 22, 2024, 4:28 PM UTC

lolinder wrote: post #67

shrx wrote: post #18

From the article: > If the verifier finds any unsafe code, the program is rejected and not executed. The verifier is rigorous -- the Linux implementation has over 20,000 lines of code [0] -- with contributions from industry (e.g., Meta, Isovalent, Google) and academia (e.g., Rutgers University, University of Washington). [0] links to https://github.com/torvalds/linux/blob/master/kernel/bpf/ver... which has this inter…

I'm not able to comment on what this code is doing, but as for the theory: The halting problem is only unsolvable in the general case. You cannot prove that any arbitrary piece of code will stop, but you can prove that specific types of code will stop and reject anything that you're unable to prove. The trivial case is "no jumps"—if your code executes strictly linearly and is itself finite then you know it will termi…

Adding on (and it's not terribly relevant to eBPF), it's also worth noting that there are trivial programs you can prove DON'T halt.

A trivial example[1]:

    int main() {
        while (true) {}
        int x = foo();
        return x;
    }

This program trivially runs forever[2], and indeed many static code analyzers will point out that everything after the `while (true) {}` line is unreachable.

I feel like the halting problem is incredibly widely misunderstood to be similar to be about "ANY program" when it really talks about "ALL programs".

[1]: In C++, this is undefined behavior technically, but C and most other programming languages define the behavior of this (or equivalent) function.

[2]: Fun relevant xkcd: https://xkcd.com/1266/

Re: No More Blue Fridays

#157

Post by kaliszad » Mon, Jul 22, 2024, 4:29 PM UTC

"These security agents will then be safe and unable to cause a Windows kernel crash."

Unless of course there is a bug in eBPF (https://access.redhat.com/solutions/7068083) @brendangregg and the kernel panics/ BSoDs anyway which you mention later in the article of course.

Re: No More Blue Fridays

#158

Post by riskable » Mon, Jul 22, 2024, 4:32 PM UTC

brendangregg wrote: post #81

surajrmal wrote: post #73

Earlier quoted context omitted.

This assumes eBPF becomes the standard. It's not clear Microsoft wants that. They could create something else which integrates with dot net and push for that instead. Also this problem of too much software running in the kernel in an unbounded manner has long existed. Why should Microsoft suddenly invest in solving it on Windows?

Microsoft have been driving the work to make eBPF an IETF industry standard.

...just like they did with Kerberos! And just like with Kerberos they'll define a standard then refuse to follow it. Instead, they will implement subtle changes to the Windows implementation that make solutions that use Windows eBPF incompatible with anything else, making it much more difficult to write software that works with all platforms eBPF (or even just its output).

Everything's gotta be different in Windows land. Otherwise, migrating off of Windows land would be too easy!

In case you were wondering what Microsoft refused to implement with its Kerberos implementation it's the DNS records. Instead of following the standard (they wrote!) they decided that all Windows clients will use AD's Global Catalog to figure out which KDC to talk to (e.g. which one is "local" or closest to the client). Since nothing but Windows uses the Global Catalog they effectively locked out other platforms from being able to integrate with Windows Kerberos implementation as effectively (it'll still work, just extremely inefficiently as the clients won't know which KDC is local so you either have to hard-code them into the krb5.conf on every single device/server/endpoint and hope for the best or DNS-and-pray you don't get a Domain Controller/KDC that's on an ISDN line in some other country).

Re: No More Blue Fridays

#159

Post by throw0101d » Mon, Jul 22, 2024, 4:32 PM UTC

Meta:

> eBPF (no longer an acronym) […]

Any reason why the official acronym was done away with?

Re: No More Blue Fridays

#160

Post by bfrog » Mon, Jul 22, 2024, 4:32 PM UTC

I wonder if microkernels ever had this kind of bullshit. Had it been a microkernel, would we all be sitting twiddling our thumbs on friday? Hot take: No.