That the process/thread enters kernel mode and then is suspended waiting for IO or for some other event. As long as the thread is running your code (or, is scheduleable) it's not blocked. And then the async implementation can ensure your code cooperatively gives up the CPU for other code.
No, if the memory-mapped page you're accessing is in RAM, then you're just reading the RAM; there is no page fault and no syscall and nothing blocks.
You could say that any non-register memory access "blocks" but I feel that's needlessly confusing. Normal async code doesn't "block" in any relevant sense when it accesses the heap.
It will at the very least notice that the read data does not match the stored checksum and not return the garbage data to the application. In redundant (raidz) setups it will then read the data from another disk, and update the faulty disk. In a non-redundant setup (or if enough disks are corrupted) it will signal an IO error.
An error is preferred to silently returning garbage data!
> Clearly the sync between devices works, so they have solved this problem.
Presumably they don't use CSV to sync, they're using a saner json/etc. data structure that they're not letting us export ourselves. Seriously, being limited to CSV in this day and age...
The second link doesn't mention "as-is", the first one does. I'll assume that's what you meant. It says,
> Though manufacturers cannot so easily escape liability, sellers can escape liability by informing the customer before the purchase that a product must be taken "as-is,” which means how the product was found when it was purchased in-store. “As-is” works because the buyer has an opportunity to inspect the product and decide whether to buy it given its condition.
On that analogy, Github and RedHat aren't liable, but the original author of the software still is.
If I build an unsafe boiler, and gift it to you, and then it explodes and kills you - am I not liable because it was a gift and not a sale? Can I disclaim away any liability and "fitness for purpose" when I gift you the boiler?
ETA: the first couple of Google results say that no, product liability can't be disclaimed away - particularly when there is no contract or opportunity for bargaining. I am very much not a lawyer but this sounds correct to me (i.e. this is what the law is).
Regardless, the vulnerability is in the driver, not the CPU / microcode. Also in the WHQL process that signed such a 'fake' driver. Until the signature is revoked, it might be possible for an attacker to manually install the signed driver on other system configurations too.
> But even better, it has a security descriptor allowing Everyone + Low IL R/W Access, and an IOCTL interface with absolutely no Probes/SEH, which yes, dereferences wild pointers. They don't even bother checking for input size or output sizes.
If that's true of the driver, then it's a sec vuln regardless of what the MSR bit does or doesn't do, no?
Governments that issue patents on math/algorithms/software already claim the power to forbid you to use them. They just need to patent all public encryption algorithms, in perpetuity.
It would be less than 3x the length, not 10x. The mountains are a problem; it could go around but would still need to dig a lot. And it doesn't seem feasible politically right now, but it could be a really cool project.
(If it was built, then a side-canal to irrigate the Dead Sea would be a relatively cheap value-add.)
If you've heard of KOffice, this is a fork from 2010 which didn't inherit the project name but eventually became the official / only KDE office suite project.
> That a lot of parents who cannot work from home, like say cashiers or construction workers who still have to go out, do not even really know right now how to manage their kids.
And further confusing the issue, many other parents / families who are forced to stay home do know how to interact with their children productively, and those children have a much better time of it.
Even assuming purely good intentions, the government would want to use the key very often (hundreds or thousands of concurrent investigations) and in many large unrelated organizations (eg police + FBI + NSA + CIA + DOD + ...). It would be impractical to authorize each individual use, let alone authorize it by several parties each time.
Instead we'd see 'ongoing' authorizations on the level of an investigation, a person or team, or a whole sub-organization (modulo clearance / position in that organization). And so you'd have copies of the complete key going around.
Yes, by giving the government access to one or both of the end devices. (Which is probably already a thing somewhere legally, and very likely is the factory state for some Android phones.)
Note that banning E2EE implies banning encrypted p2p communications entirely. E2EE is a concept that applies only to centralized comms providers where all messages go through a server.
Practically speaking, it's impossible to ban every encrypted protocol (TLS, SSH, ...). It's also (probably) impossible to ban IP communications that don't have an "approved server" participating.
However, comms providers / social networks to date at least manage, authenticate, and introduce users at the serverside. Fully distributed projects have problems with spam. So governments would have to ban comms providers from "allowing" their clients to talk to each other directly and not via the backend. That's a hefty technological restriction, which would block a wide range of protocols (webrtc/SIP, torrents, probably a bunch of other Very Important things I'm not thinking of right now).
The immune system presumably has a limited capacity of circulating antibodies. By introducing new antibodies, do we reduce the amount of previous antibodies, and does this reduce their immune response? Is there a concept or metric of "antibody dilution"?