181–190 of 282 posts
Earlier quoted context omitted.
Perhaps not verified, but some smart people do have convincing arguments: https://youtu.be/wAzEJxOo1ts?si=UNNxAN27VV1E6mcP&t=505
Any article/blog/text-that-can-be-read?
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…
The basic logic flags any loop ("back-edge").
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?
Off the top of my head, limiting myself to just NT kernel stuff: WSL and Hyper-V, pseudo-terminals, condvars, WDDM, DWM, elevated privilege programs on the same desktop, font driver isolation, and limiting access to win32k for sandboxing.
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 safegu…
Earlier quoted context omitted.
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 widel…
Nit: In many languages, doesn't this depend on what foo() does? e.g:
foo() {
exit(0);
}Earlier quoted context omitted.
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…
Earlier quoted context omitted.
Yes, we know eBPF must attach to equivalent events to Linux, but given there are already many event sources and consumers in Windows, the work is to make eBPF another consumer -- not to invent instrumentation frameworks from scratch. Just to use an analogy: Imagine people do their banking on JavaScript websites with Google Chrome, but if they use Microsoft Edge it says "JavaScript isn't supported, please download and…
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?
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, later replaced by minifilters), and the 64 bit edition of XP introduced PatchGuard [1] to prevent drivers from modifying Microsoft's kernel code. Additionally Microsoft is requiring ever more static and dynamic analysis to allow drivers to be signed (and thus easily deployed).
This is a very leaky security barrier. Instead of a hardware-enforced barrier like the kernel-userspace barrier it's an effort to get software running at the same protection level to behave. PatchGuard is a cat-and-mouse game Microsoft is always loosing, and the analysis mostly helps against memory bugs but can't catch everything. But MS has invested a lot of work over the years in attempts to make this path work. So expecting future actions isn't unreasonable.
Earlier quoted context omitted.
This claim about SQL Server: Is it due to disk access being slower from NT kernel compared to Linux kernel?
I had read previously from an unverified SQL Server engineer that the thing they wanted most (with Linux support) was proper containerization (from a developer perspective). Apparently containers on Windows just don't cut it (which is why nobody uses them in production). Take it with a grain of salt though. I don't think they'd ever admit that filesystem performance was an issue (though we all know it is; NTFS is ove…
ext2, which is forwards compatible with ext3 and ext4, is slightly older than NTFS
Meta: > eBPF (no longer an acronym) […] Any reason why the official acronym was done away with?