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

201–210 of 282 posts

Re: No More Blue Fridays

#201

Post by jrockway »

MawKKe wrote: post #187
riskable wrote: post #158

Earlier quoted context omitted.

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

Embrace, extend, ...

This doesn't really seem like their strategy anymore. It's not like Edge directly interprets Typescript, for example. While they embraced and extended Javascript, any extinguishing seems to be on the technical merits rather than corporate will.

In the case of security scanners that run in the kernel, we learned this weekend that a market need exists. The mainstream media blamed Crowdstrike's bugs on "Windows". Microsoft would likely like to wash its hands of future events of this class. Linux-like eBPF is a path forward for them that allows people to run the software they want (work-slowers like Crowdstrike) while isolating their reputation from this software.

Re: No More Blue Fridays

#202

Post by adolph »

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…

Sounds like they need a nice Hackintosh for that validated FDA regulation app-OS-HW combo.

Re: No More Blue Fridays

#204

Post by whynotminot »

hello_moto wrote: post #200
whynotminot wrote: post #180

Earlier quoted context omitted.

> You can guess, but you cannot be 100% sure. I worked in the cyber security space for a decent chunk of my career, and the most frustrating part was cyber security engineers thinking their problems were unique and being completely unaware of the lessons software engineering teams have already learned. Yes, you need to tune your canary deployment groups to be large and diverse enough to give a reliable indicator of d…

>if you follow industry best practices for software deployment, this is already something that should be considered. This is a relatively solved problem -- this is not new. You have to ask the customer if they're okay with that citing "our software might failed and brick your machine". I'd like to see any Sales and Marketing folks say that ;) > I think that question is being asked right now by every company using Cro…

> You have to ask the customer if they're okay with that citing "our software might failed and brick your machine".

I think you’re still missing the point of Canary deployments. The question your sales team should ask is “would you like a 5% chance of a bug harming your system, or a 100% chance?”

> It's like: previously Cybersecurity vendors are shy to ask customers to setup Canary systems because that's just "one-more-thing-to-do"

You should by shy because it is not your customer’s job to set up canary deployments. Crowdstrike owns the software and the deployment process. They should be deploying to a subset of machines, measuring the results, and deciding whether to roll forward or roll back. It is not the customers job to implement good release engineering controls for Crowdstrike (although after this debacle you may well see customers try).

Re: No More Blue Fridays

#205

Post by haberman »

muth02446 wrote: post #163

```The verifier is rigorous -- the Linux implementation has over 20,000 lines of code -- with contributions from industry (e.g., Meta, Isovalent, Google) and academia (e.g., Rutgers University, University of Washington). The safety this provides is a key benefit of eBPF, along with heightened security and lower resource usage. ``` Wow, 20k is not exactly encouraging. Besides the extra attack surface, who can vouch fo…

I had exactly the same thought. I don’t know if that 20k number was supposed to inspire confidence, but for me it did the opposite. It would have inspired confidence if it was 300 lines of code.

My impression is that the WebAssembly verifier is much simpler.

Re: No More Blue Fridays

#206

Post by tptacek »

lucianbr wrote: post #85
tptacek wrote: post #75

Earlier quoted context omitted.

The claim isn't that eBPF generally prevents kernel crashes. It's that it prevents crashes in the subset of programs it's designed for, in particular for instrumentation, which Crowdstrike is (in this author's conception) an instance of.

I have quoted the claim verbatim from the article. It is obviously the claim of the article.

It's referring to Windows security software. If you have a lot of context with eBPF, which Gregg obviously does, the notion that eBPF will subsume the entire kernel doesn't even need to be said: you can't express arbitrary programs in eBPF. eBPF is safe because the verifier rejects the vast majority of valid programs.

Re: No More Blue Fridays

#208

Post by wiresurfer »

Hey Brendan,

> If your company is paying for commercial software that includes kernel drivers or kernel modules, you can make eBPF a requirement.

Windows soon, may still be atleast a year ahead. Would that be a fair statement? atleast being the operating keyword here.

Specifically in the context of network security software, for eBPF programs to be portable across windows/linux, we would need MSFT to add a lot more hooks and expose internal kernel stucts. Hopefully via a common libbpf definition. Otherwise, I fear, having two versions of the same product, across two OSs would mean more secuirty and quality issues.

I guess the point I am trying to make is, we would get there, but we are more than a few years away. I would love to see something like cilium on vanilla windows for a Software defined Company Wide network. We can then start building enterprise network secutiry into it. Baby steps!

---

btw, your talks and blog posts about bpftools is godsent!

Re: No More Blue Fridays

#209

Post by vitus »

queuebert wrote: post #167
kevincox wrote: post #88

Earlier quoted context omitted.

They aren't over windows. They continue to be incredibly interested in and actively developing how much money they can suck from their users. Especially via various forms of ads. But yeah, kernel features are few and far between.

I believe the term you are looking for is "rent seeking". Other than visual changes, what new functionality does Windows 11 actually have that Windows XP didn't have? (I'm being generous with XP, because actually 95 was already mostly internet ready.) Yet how many times have many of us paid for a Windows license on a new computer or because the old version stopped getting updates?

> Other than visual changes, what new functionality does Windows 11 actually have that Windows XP didn't have?

Modern crypto ciphersuites that aren't utterly broken? Your best options for symmetric crypto with XP are 3DES (officially retired by NIST as of this year) and RC4 (prohibited in TLS as of RFC 7465).

(And if you think 3DES isn't totally broken by itself, you're right... except for the part where the ciphersuite in question is in CBC mode and is vulnerable to BEAST. Thanks, mandated ciphersuites.)

Re: No More Blue Fridays

#210

Post by Analemma_ »

wongarsu wrote: post #188
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 has invested in solving this for at least two decades, probably longer. They are just using a different (arguably worse) approach to this than the Unix world. In Windows 9x anti-malware would just run arbitrary code in the kernel that hooked whatever it wanted. In Windows XP a lot of these things got proper interfaces (like the file system filter drivers to facilitate scanning files before they are accessed…

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 code are for the tiny sliver of use cases left that need it, it is not Microsoft patching individual holes on the leaky ship.

They haven't yet gone as far as Apple in banning third-party kernel-mode code entirely, but I wouldn't be surprised if it's coming.

Post reply on HN