nordrand has been removed from the kernel as it had become overloaded by meaning both a) and b)
Under most circumstances, a) is harmless. You mostly want that off when the CPU exhibits some performance hiccups when asked.
Under some circumstances, b) is outright dangerous. Some applications can work without seeded pool at some slightly reduced performance, but could be made to fail miserably if they had been made to believe that the pool was seeded yet it was not. This happens with hash tables when you skip some of the accounting because it seems no longer relevant. It really would not be relevant, once even a determined attacker should be unable to reliably trigger the worst-case-performance.
As far as I know that is correct; the kernel was written in a way such that one bad source doesn’t poison the pool. Still, if you know one source is bad, might as well take it out.
You don't know if it's bad. Microcode updates might fix it, or break it for that matter. Revision history can be difficult if not impossible to comprehensively catalog.
What it is is unreliable. And that's fine so long as you have other entropy sources. OpenBSD is really good about this. Quite a few drivers for various chipsets and cards exist just to read their RNGs, not actually use them for their primary function (which can be a bummer if you want to use the the device, get your hopes up when you see the driver exists in the tree, then discover the only capability it supports is reading the RNG). If you have a CPU with a known bad rdrand, odds are OpenBSD is still sourcing strong randomness from some other chip in your system (PSP, NIC, etc). And because feeding bad (as opposed to malicious[1]) entropy is harmless[2], they don't have to maintain a pile of conditions. Nobody is worse off, and overall everybody is better off, including having stronger getrandom/getentropy output, by not trying to be clever.
[2] Presuming nothing is relying on an entropy estimator. I can't remember if Linux finally moved past the entropy estimator nonsense. IIRC they did add a software jitter RNG that runs early to try to set a minimum entropy floor, regardless of hardware sources.
> that's fine so long as you have other entropy sources
Well, if you literally have nothing else, then you don't have an option anyway, so the whole question is moot.
Except yeah if literally the only way to collect entropy in your system is the platform's opaque RNG, then sure this means your risk assessment should list that as a SPOF. But by definition these cases only have that option, so you can't do anything else.
In reality, you can probably do something else in all but the most extreme embedded environments.
> if you know one source is bad, might as well take it out.
Yes and no. Mostly no.
In a simplified model, it's only useless if it adds zero bits of entropy. But if a source that's supposed to add 128 bits of entropy only adds 16, well, it's still 16.
I would never trust RDRAND on its own. If nothing else because it's always subject to a microcode backdoor. But if I already have something I'm happy with the entropy of, sure, I'd XOR it with RDRAND output. It cannot make it worse.
Why? That would actually reduce randomness. The value of adding sources to the entropy pool has a floor of zero. Worst case scenario, it just provides no extra entropy.
this is generally true however if an adversary is able to control a source it becomes dangerous if they can preview the results or inspect the other sources.
Right, so your starting point is that the attacker has read-only access to ALL entropy sources, and in that scenario it's worse if the attacker has read-write access to one entropy source.
Yes. I don't find this a particularly interesting scenario, though. Sure, we can come up with stuxnet-like airgap attacks where we on-device, but not remotely, can read entropy sources. AND we can modify the output of RDRAND. And there keys have been generated for data we can later intercept. But despite that control (potentially on a CPU microcode level) we are unable to stegonographically leak it?
if your algorithm controls a source of entropy and can inspect the other sources, it can craft its source to bias the result. a fanciful attack but it means you should at least discriminate what you put into the pool.
Can you link to the paper you're thinking of? Maybe people are just talking past each other here. A biased random source can't bias the kernel random pool in any straightforward kind of way.
What's you point? That if you had run your own DC in that region (because that was your business requirement) then you'd have better missile defense than AWS?
Or maybe AWS or DIY, you are always responsible for geographic diversity?
Anyone losing data over this lost it because they'd literally told AWS to only store it in one place.
You don't need better missile defense than AWS. You don't need missile defense at all because you won't be a target. 99.999999% of the land has no missile threat on it. You are actively increasing the threat to your business by running it on the same servers that military contractors run their software on.
> You don't need missile defense at all because you won't be a target.
No, you don't need it because you have offsite backups. And this is completely disconnected from whether you use AWS or DIY.
> you won't be a target.
Of missiles, maybe in this particular conflict, sure. But running a DC is not your core business, so which DC is more likely to be subject to burglary, power outages, diesel shortages (Amazon will have better negotiators than you), fire suppression, hell, private fire departments if needed, etc…
Was missiles or copper thieves the biggest threat, even there, in 2020? Would AWS or every small company be better at protecting against the latter?
I feel like this is hindsight bias, and in a different scenario you'd be saying "not hosting your infrastructure in a DC without AWS level diesel backup contracts is even better".
Which I already said, and you ignored.
Anyway, it's all moot, because the military will now also spread out.
You can go with "Joe's pizza and cloud services", hoping there aren't enough military workloads there, but where are you more likely to have an outage?
> In a war where schools and bridges and aid convoys and bread lines are targeted
Yes but that's clearly not this war. This is a missile war where high-value strategic military targets are the priority. The US and Israel hit some prisons, damaged some hospitals, and ofc killed 168 schoolchildren. They also targeted residential areas to assassinate important leaders. But Iran has not returned that. They've stuck pretty strictly to military targets with very few exceptions
If this was a war where bridges were a target, Iran would not be so successful. There's simply a too limited amount of missiles. Also only 20% of Saudi Arabia has citizenship while almost the whole rest is basically indentured servants. It's not like they could provoke a popular uprising or anything. There's no strategic value in hitting "bread lines"
What CARVER score would you give an AWS data center? I would probably put it around the 40 to 50s. Where would you put your own individual company by itself on the CARVER matrix as it relates to enemy forces? Pretty damn low.
Which is why your job as a responsible company you should have verified your offsite backups on 28th Feb.
Just like you would if wildfires started breaking new records in Oregon, if that's where your (for some reason sole) cloud region is.
It should already be set up, of course, but from a data point of view this is when you're thankful that at least this raised risk came with a heads up.
An American-run data center is much more likely to be targeted than some locally-owned and run company that isn't obviously connected to a foriegn power or the state that hosts it.
The point is that AWS has the same problem as Wildberries.
There is no difference at all between Wildberries and AWS data centers.
If you don't know what Wildberries is then go watch their facilities systematically destroyed on YouTube - centralisation is a target.
If your organization runs on AWS then you should have a contingency plan for the data center being destroyed by drones. Is that on your risk management plan?
> If your organization runs on AWS then you should have a contingency plan for the data center being destroyed by drones.
If your organization runs on servers in your basement you should have a contingency plan for flooding, fire, copper thieves, diesel shortages, etc… etc… etc…
Or are you basically saying that the only safe place is outsourcing your ops to a mid sized operator? Too small and nobody will pay for the every day risks. Too big and it's a war target? Ok, let's continue that plan. Now military users move their workloads to the mid sized operators for the exact same reason you did. Oh no, we're back at square 1.
A plan of putting all your eggs in one basket is never good. And it's completely orthogonal to AWS vs the non-AWS options.
Pretty basic stuff.
> If you don't know what Wildberries is
Not exactly esoteric knowledge. But it's also not the same thing. Wildberries could not "back up" their inventory to an offsite location with the footprint of a suitcase.
> If your organization runs on AWS then you should have a contingency plan for the data center being destroyed by drones. Is that on your risk management plan?
Sure, if you discard ALL other risks, that happen every day, leaving only war as the remaining risk to manage, then your risk management plan makes sense.
But the other risks are still there. Your DC operator going bankrupt and having their power cut is a risk that didn't go away.
Sure. But given that the affected customers would by definition not have offsite backup, the comparison is against a smaller operator that has way more risk of fires, theft, bankruptcy, incompetence, earthquakes, power delivery, and all the other risks.
Sure, fewer customers per location, but the critique here is of customers who chose AWS, the fair comparison is NOT against those who chose to be in 6 different non-AWS DCs, but against those who chose to be in ONE non-AWS DC. Decentralized aggregated across customers or not, the customers who chose unluckily still lose data.
How about not bombing other countries and then acting surprised when retaliation happens? I mean clearly the problem isn't AWS as such - it is the problem that someone leading a country is totally clueless about the world. Only personal profit is in the interest of the orange clown.
I get your main point, but just wanna point out that AWS is one of the largest military contractors in the world. They hold multi-billion dollar contracts from the DoD, USAF, CIA, and more. An estimated $4B a year in military spending goes to AWS
As someone who did train one of the traditional martial arts for a few years, I appreciate the comparison.
I don't know how much weight your "just" is meant to carry, but I remember a culture of cope and excuses about why "my" flavor wasn't the winner of any MMA event.
But at least I got some exercise, strength, and flexibility out of it.
I think it's an interesting analogy, not to be dismissed so easily.
I don't see him saying the point is volume of code. I see AI generating code, and if I question it, it can justify design choices pretty well. I can give it bug symptoms, and it can find and fix the bug. Usually.
But yes, the analogy breaks down in the fact that I understand what it's saying and understand when it's wrong, because I learned it in the first place.
Or maybe it doesn't break down completely. If an MMA (AI) tells me to move in a way where I know I'll lose my balance, or over extend, I will say no, because of my previously acquired experience.
In a rug pull, the thing you own (usually some kind of digital asset) goes down in value, leaving you with less money than you started with, whereas theft leaves you no longer possessing the asset itself.
A few extra steps. Usually, the rug pull doesn't involve directly taking something that belongs to other people, but instead, selling your own thing in a dishonest way.
Do we really need the latest kernel on them, though? As in, is it worth it?
In 100 years, if we need to run kernel 6.12 to use a 3c509, is that all that bad? It's not like being "stuck" on an old IRIX without the proprietary dev CD where you have a catch 22 problem.
An old system version that's completely open is whatever the sysadmin version of "turning complete".
Sure, port the open system to the hardware that does not have an open system. But I question the value of keeping it up to date.
All else being equal, sure it'd be cool. But all else is not equal. So yes, ripping out old code is the right move for Linux, in my opinion.
The other open question is, will there still be operational 3c509s 100 years from now?
Another way I put it, with a heavy sigh, is: "There will come a day—and odds are, it's not far off now—when the last working real Amiga will stop working for the last time."
Did you read my comment or you just reply for the sake of it?
I release the code so that people and companies that feel like contributing to the community can use it. Companies that want to take without giving back however are mildly inconvenienced by copyleft.
> I chose to do it for free to help other people. And picking a MIT license does the opposite.
I have no idea what this is supposed to mean. I want to help other people, then giving them the means to do what they want with no real restrictions is "the opposite" of that?
> Companies that want to take without giving back
So this is not about helping anyone else, but about mandating a behavior, even if that behavior is "pay it forward".
Distributing (however defined by a given license) unmodified software that is presumably widely available to customers may be a requirement but is also a profoundly uninteresting legal requirement.
I don't think we're disagreeing about anything. I wasn't giving a legal opinion but lawyers, especially at large firms, are a lot more conservative about some matters than I might be for a personal project. If you have deep pockets and provide any path to those pockets, someone could sue you.
I used to work for a very open source-friendly company and, while AGPL wasn't broadly verbotten and I can't quote any publicly available documents, its use was not encouraged in general. (And outside of Linux which was what it was, permissive licenses became much more common for new projects.)
https://www.techradar.com/home/smart-home/samsung-launches-a...
reply