post operating system design faults
>>106424793idgi
signalsfork not returning file descriptorpthead timed functions using REALTIME clock despite using delay not timestamp so they can block indefinitely due to NTP time changes
>>106425434tsmt shartysister o algo or something
>>106424793The only design fault is with your kiked brain sharty troon.https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
>>106425400But anon, if you want to use a Realtime thread you should be using delays?
>zoophiles calling random users zoophiles
>>106426660>daaaah I'm not smrt e-nuff 2 design an unpickable lock, therefore nobody iscnile incompetence ladies and gentleman
If this is the kind of attack the US military had in the 60s then I'm 100% certain that all microcode is compromised.
>>106424793Is this the power of FOSS image editors?
>>106426880>60sI'd imagine the concern was more that traitors would attempt to eavesdrop on what other users were doing on timeshared machines
>>106426844How does any other language solve this problem if they have a compromised compiler(Assuming that language's compiler is written in the same language)?
>>106426762what sort of mental illnesses push people to create and participate in sites like that?
>>106426880It was a hypothetical at a time where computer science and security as a field were still developing. They didn't "have" an attack back then, it was just an epiphany when considering from a security perspective, what would happen is any particular part was arbitrarily compromised.
>>106424793I don't understand your stupid ass zoomer/basedteen memes.
>>106429148The same attack can be implemented in ucode there is no defense against this attack you have to find a way to analyze the cpu at runtime
>>106429159Do you have the paper? I'm sure someone would have tried implemented it during multics dev cycle after receiving the critique.
>>106429167It's basically a code that goes like "hey pedos come to our site we have a bunch of edgy teenagers that want to be groomed"
>>106429171Microcode is by design invisible to execution, the cpu doesn't support breaking into it. There is no analyzing it without a level of technical sophistication, that if reached, would most likely allow you to make your own backdoor free cpus anyway.But it's meaningless to have when you have just a regular hardware backdoor running separately and sifting through the data of the execution core anyway. They're both equally invisible, equally potent, and one is significantly easier to integrate, produce and modify.>>106429176I don't but that's what the discussion around it seems to signify.But probably, it's not out of the question.
>>106429167Killing a joke but,I think it's supposed to show that you'd shoot that one pillar to bring down the whole thing in Angry Birds. Mixes that>one package being thanklessly maintained by a guy in Nebraska since 2003meme with this and then adds some philosophy over what parts of that structure stand for to the piggies and the birds.If it weren't s0ijak retardation, it's a pretty good joke. Got a chuckle out of me.
>>106425400>fork not returning file descriptorwhy the fuck would you want a file descriptor
>>106429424to poll() on completion instead of that fucking wait() monstrosity
>>106429632>that fucking wait() monstrosityelaborateit works fine here
>>106429721It has plenty little issues that just disappear with file descriptors.One is the whole zombie state. Since fork() wait() use global PID numbers and those are reused, there would be a potential race condition where child process would exit and someone created new process that would reuse the PID. If you use file descriptors you get level of indirection that can handle died state without keeping zombie and can be garbage collected like resources that use file descriptor.Second is just the ownership. It's obvious who is owning process - anyone with file descriptor to it.You can dup() it, pass it over socket, whatever just like any other resource.And foremost the event loops and mixing process management with I/O polling. With wait() it's two competing mechanisms and it's not nice. You need signals (already an ugly hack) just to interrupt poll() and you also get the whole self-pipe/ppoll race condition bullcrap.
>>106430809btw Linux has pidfd interface since v5.6. I recall there were some additions to make it full-featured, not sure if that was in this or later version. I don't really have to draw the full picture here since it already exists, check manpages if interested.I just wish this was portable and in unix/posix since early versions, since it's the better way to manage processes.
>>106426760you are confusing real-time scheduling with REALTIME clock_id (the UTC calendar datetime clock).To illustrate what I mean: take C++ std::condition_variable::wait_for(). It could look like it is suppposed to block for up to the passed time limit. But no, it takes current time and adds delay to it and waits until absolute timestamp using REALTIME clock_id. So if NTP modifies the time, the wait can block indefinitely. This is not mentioned in documentation, sadly.pthread has a setclock attribute for condition variables so you can set MONOTONIC like a sane person would want, but curiously other pthread objects that you can wait on (namely mutex and rwlock) don't have this attribute and can only wait on REALTIME.
>>106430809>child process would exit and someone created new process that would reuse the PIDthat'd be a bug in your OSPIDs of unreaped child processes shouldn't be reused
>>106430962that why zombie state exists, so solve this potential race condition - just like I wrote.
>>106430988you didn't write shit
