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

11–20 of 282 posts

Re: No More Blue Fridays

#11

Post by lordnacho »

StevenWaterman wrote: post #6
asynchronous wrote: post #5

Is there a reason for the lack of naming+shaming Crowdstrike in this blogpost? Was it to not give them any more publicity, good or bad?

If you consider kernel programming to be inherently unsafe, then you would consider this to be inevitable, meaning it's not really the specific company's fault. They were just the unlucky ones.

They could have helped their luck by doing some of the common sense things suggested in the article.

For instance, why not find a subset of your customers that are low risk, push it out to them, and see what happens? Or perhaps have your own fleet of example installations to run things on first. None of which depends on any specific technology.

Re: No More Blue Fridays

#12

Post by prmoustache »

CoastalCoder wrote: post #4

> If your company is paying for commercial software that includes kernel drivers or kernel modules, you can make eBPF a requirement. Are they saying that device drivers should be written in eBPF? Or maybe their drivers should expose an eBPF API? I assume some driver code still needs to reside in the actual kernel.

These tool wouldn't need kernel drivers, only to target the eBPF userspace API: https://www.kernel.org/doc/html/latest/userspace-api/ebpf/in...

Re: No More Blue Fridays

#13

Post by brendangregg »

StevenWaterman wrote: post #6
asynchronous wrote: post #5

Is there a reason for the lack of naming+shaming Crowdstrike in this blogpost? Was it to not give them any more publicity, good or bad?

If you consider kernel programming to be inherently unsafe, then you would consider this to be inevitable, meaning it's not really the specific company's fault. They were just the unlucky ones.

Right, and we wanted to talk about all security solutions and not make this about one company. We also wanted to avoid shaming since they have been seriously working on eBPF adoption, so in that regard they are at the forefront of doing the right thing.

Re: No More Blue Fridays

#14

Post by efee22 »

dijit wrote: post #9
xg15 wrote: post #2

> 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. Assuming every security critical system will be on a recent enough kernel to support this...

And assuming there's no bugs in the BPF code... Oh wait: https://news.ycombinator.com/item?id=41031699

RHEL kernel.. right. Imho, I'd trust an upstream stable kernel far more than a RHEL one for production which has dozen of feature backports and an internal kABI to maintain.. granted RH has a QA team, but it is still impossible to test everything beforehand.

Re: No More Blue Fridays

#15

Post by kayo_20211030 »

This isn't right. If I need a system to run with a piece of code, then it shouldn't run at all if that piece of code is broken. Ignoring the failure is perverse. Let's say that the driver code ensures that some medical machine has safety locks (safeguards) in place to make sure that piece of equipment won't fry you to a crisp; I'd prefer that the whole thing not run at all rather than blithely operate with the safeguards disabled. It's turtles all the way down.

Re: No More Blue Fridays

#16

Post by ForOldHack »

asynchronous wrote: post #10
StevenWaterman wrote: post #6

Earlier quoted context omitted.

If you consider kernel programming to be inherently unsafe, then you would consider this to be inevitable, meaning it's not really the specific company's fault. They were just the unlucky ones.

I still hold true that testing even improperly would have caught this before it hit worldwide. But I suppose you are right, that doesn’t help the argument being made here.

Wasnt that the job of AI/co-pilot/clippy /D.E.P? "Would you like me to try and execute a random blank file?"

And of course QA.

I was unaffected, but was fielding calls from customers.

My update Tuesday is the week after, so in-between MS and my updates, I am very suspicious of everything.

I was also unaffected by 22H2, and spent time fielding calls.

Re: No More Blue Fridays

#18

Post by shrx »

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 interesting comment at the top:

    /* bpf_check() is a static code analyzer that walks eBPF program
     * instruction by instruction and updates register/stack state.
     * All paths of conditional branches are analyzed until 'bpf_exit' insn.
     *
     * The first pass is depth-first-search to check that the program is a DAG.
     * It rejects the following programs:
     * - larger than BPF_MAXINSNS insns
     * - if loop is present (detected via back-edge)
    ...
I haven't inspected the code, but I thought that checking for infinite loops would imply solving the halting problem. Where's the catch?

Re: No More Blue Fridays

#19

Post by [deleted] »

StevenWaterman wrote: post #6
asynchronous wrote: post #5

Is there a reason for the lack of naming+shaming Crowdstrike in this blogpost? Was it to not give them any more publicity, good or bad?

If you consider kernel programming to be inherently unsafe, then you would consider this to be inevitable, meaning it's not really the specific company's fault. They were just the unlucky ones.

[deleted]

Re: No More Blue Fridays

#20

Post by dtx1 »

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 have no insight into this particular project but you could work around the halting problem by only allowing loops you can proof will not go infinite. That would of course imply rejecting loops that won't go infinite but can't be proven not to.
Post reply on HN