Let me rephrase, is a huge pile of C code, running in privileged mode in a shared address space, highly concurrent, using its own homegrown memory model based on volatile instead of the one the language spec defines and the compilers implement, dealing with untrusted data, implementing many complex protocols, data formats, & functionality, managing a bunch of "objects" with complex ownership and lifetime semantics, embedding its own JIT — secure?
@bugaevc >Is Linux secure?
No, as it contains proprietary malware and has drivers that automatically load up malware cleverly disguised as peripheral software.
@Suiseiseki Depends on your threat model. You're talking about the operating system, but @bugaevc's points all apply to Linux-libre's kernel.
Proprietary userland tends to be malware, but proprietary OEM software tends to just be buggy and unauditable. If you consider proprietary software to be inherently malicious, then your CPU (with its proprietary firmware and proprietary logic circuitry) is malicious and GNU Linux-libre is insecure.
@wizzwizz4 >proprietary software >your CPU (with its proprietary firmware and proprietary logic circuitry) is malicious
My CPU is all hardware, as circuitry is hardware and the microcode in ROM is hardware.
Malicious circuits are rare due to the physical evidence created.
As far as I can tell, the proprietary software intel previously provided for my CPU and motherboard is malicious, but I don't run that.
Firmware is microprocessor instructions in an external ROM chip that can be trivially cut out and replaced - if it can be updated with software, it's software, otherwise it's hardware, aside from one corner firm case, where replacing the instructions consists of trivial soldering.
@Suiseiseki Yeah, that's Richard Stallman's version of the software / not-software distinction, and while it's the only way to be a free software zealot while still using commodity hardware, it's not useful.
Nobody has reverse-engineered a modern x86 chip from looking at the circuitry. All the high-level behaviour of an x86 chip is controlled by microcode: the CPU comes with microcode written by Intel, and there are precious few threat models where it makes sense not to use microcode updates.
@wizzwizz4@Suiseiseki
It's just a weird cope created by GNU so people can say they run 100% free software, even when they in fact do not. Whether or not you update your microcode you will be running fully proprietary software. This changes nothing in regards to your freedom. If you think all proprietary software is bad and shouldn't be used at all then do not use any modern x86 machine lol.
@robinadams the complexity of today's Linux and the kernel it replaced is humongous. But it's certainly possible (and has been done) to write something that provides basic syscall-level ABI compatibility.
WHOA. That's what they're replacing iptables with? Madness.
Don't get me wrong, I love Linux, and have done so for over 20 years.
But tell me you're an over-engineered, scope-conquering (because creeping wasn't enough) madhouse exaproject without telling me you're an over-engineered, scope-conquering madhouse exaproject.
@bugaevc Oh definitely, I'm not pretending it's a silver bullet. Do you have something specific in mind? Moving more services into userspace maybe? I've read microkernels tend to be super slow compared to modular ones like Linux because of all the cross-modes communication that has to be done.
Feel free to ignore my questions BTW, I'm just scratching an itch, I have nothing to bring to the table as I don't know that much about kernels.
@KekunPlazas I won't pretend to be a Linux security expert either, but: writing all things in a thread- and memory-safe language from the start, and ensuring "pervasive correctness" in handling all the potential edge cases. Running safety-critical code (parsing untrusted input such as TCP/IP packets) with reduced privileges, which doesn't have to mean full microkernel-like context-switching to a userland process with all the copying of data over and flushing TLB.
@KekunPlazas whether microkernel-based systems can be fast is unclear. Newer nanokernels certainly have a very low-latency IPC path, but we have to see somebody build a more complete OS built on top, and evaluate that. (Genode might be that, I haven't looked closely.) People say that QNX was fast; I haven't looked into it either. But there's definitely an unavoidable performance cost associated with constant context switching.
> Kernel proper - This is mostly written in C. Things like the memory manager, object manager, etc. are mostly written in C. The boot loaders are written in ASM, but set up a C environment rather quickly.
>
> Drivers - that said, a lot of newer kernel mode drivers are actually written in C++ (however, its style is more akin to "C with classes". Lower level code has been much slower to adopting anything past C++98)
@bugaevc@veer66 I know this is a tangent but how many of these "just so" factoids are still actually true/relevant, because I'm not a Windows expert but I've seen a bunch of claims based on the behavior of WinNT 4 that aren't true for post Vista or post Win10, both of which made significant changes to the driver and security model, eg. using virtualization to isolate drivers and components. I don't think Win32 is as privileged as described on current NT.
Add comment