419 posts • joined 23 Jan 2015
Re: Internet to be regulated by Parliament
What is he saying is that such decisions should be outside the hands of private companies, or a group of them. I can hardly see how you can complain.
Re: Spoofing GPS is only optional
I see the problem--she did not zoom in far enough:
Not every country is happy to have foreigners popping in on a lark. Just saying.
Okay, I'm more than just a bit confused by this discussion. To review, I spent a decade doing microprocessor validation at AMD & IBM for a decade starting in the mid 90's. As I understand it, Spectre works by poisoning the branch prediction mechanism to cause a speculative memory fetch involving a value in a register which was read from an address controlled by an attacker. Timing of subsequent reads from the possible locations of the speculative read reveals the contents of the attacked address.
What about this requires a cache flush operation? All you need to do is to execute enough reads on the caches aliases. That seems a lot more difficult to detect than a straight cache flush operation.
Light at the end of the tunnel? Oncoming train.
Not all governments are as enlightened as you appear to believe based on this post. Offshore & anonymous accounts are a way to dodge the control of oppressive governments as well.
Or do you intend to outlaw cash like they did gold?
Re: A multinational is a multinational.
Economics of scale & especially network effects are a real thing. Certainly, almost any company will engage in monopoly abuse when it gets the chance.
Same thing if the company is of class Government, by the way. I am particularly nervous on that point.
A multinational is a multinational.
I'm going to keep hammering this. If a company does business in region X, then it is going to have to abide by the laws of region X. If the laws of region X and region Y are incompatible, it is going to have to choose which region it wants to do business with.
The EU & the US have significantly different views of things like the source of rights. These differences are reflected in their laws. It does not matter how hard the multinationals lobby, or even how many politicians they buy off, these differences are deep.
For all their flaws, however, the multinationals really do provide goods and services more cheaply than smaller counterparts would. That is how they exist. Breaking up their operations will have real costs.
So, it is convenient for people to lie and say that a company can comply both with EU & US laws.
Don't watch sausage, or law, being made.
That was at home. At school.... :)
Re: If you have cold dead fingers
When I was at AMD, they used Outlook. Made me want to scream. Ran Eudora at home. Then I went to IBM. Which owned Notes. <starts rocking furiously>
Re: Reinventing a more limited wheel
No, and that is precisely the point. If you think that
results = [(x, f(x), x/f(x)) for x in input_data if f(x) > 0]
is in any way equivalent to
results = [(x, y, x/y) for x in input_data if (y := f(x)) > 0]
then I don't want you on my team, and may I never be affected by any your code.
There is absolutely no way to ensure that f(x) is idempotent. If you don't understand that, then step away from the keyboard.
Re: Pen testers are not risk assessors
Even red teaming has rules. The best military Red Teamer the US had resigned in protest in response to the rules that the Navy was forcing on him.
More to the point, pentesting & red teaming almost certainly DO have rules against, for instance, personal enrichment, as well as NDRs. I recently read in these comments that an auto manufacturer commissioned a red team to try to take down a production line. (They succeeded.) That is a rule--only take down that specific line.
Re: Pen testers are not risk assessors
In every pursuit, there are competent, moral actors, and there are the incompetents and the charlatans. We regularly see people dumping on devops and agile here because of the later. Occasionally the cops. Twenty years ago, the term "software engineer" got the same treatment. Pen testing is no different.
The nature of pen testing is such that caveat emptor is ALWAYS going to be a major issue. Research the organization you are considering, and run away if red flags pop up.
I read an article fifteen or so years ago about bacteria evolving to become "nice" as their ability to spread is constrained. The primary example is diarrhea. At the time, it was near-fatal in India, required hospitalization in Mexico, and was almost completely benign in the US. Why? Because of sanitation practices. In an extreme case, there is a frog that can hibernate for years. With 50% of its blood volume the bacteria.
Attackers want money. What they DON'T want is to go to jail. Ransomware is pretty good for money, but it presses all the right buttons to get people to come after you, hard. OTOH, crypto mining is stealing electricity. This is a much more stable solution.
Re: Wrong Question!!
I would say that the proper question is, "When is the last time you did a DR exercise, what were its parameters, and what were the results?"
"No plan survives contact with the enemy" (Napoleon) That is, plans are mostly worthless until they have been executed, preferably more than once.
Only under orders.
When I was in the Air Force, we were to enter a room to do periodic maintenance. Only the day lock (a five push-button job) had been changed. It was about 0230, and the lead was trying to decide if he should wake up the day shift supervisor or just put off the PMI. I informed him that I could go through the lock.
"Is that an order?"
It took less than a minute.
As I keep saying, cloud providers can provide resiliency that is entirely beyond the reach of SMB, and for a reasonable price.
But my immediate question for banks, is: what exactly are your uptime requirements? It's not at all clear to me that they even need three nines. As others have mentioned, the web front end might be nice and cloudy, but the core business operates off a distinctly 18th-century model of availability. Unless and until I can have final clearance of a check from a major bank in seconds, the banking system is not the least bit interested in five- or six-nines of resiliency.
If some bank(s) WERE attempting to bring banking into a modern era, then some sort of cloud-based solution would be required. See previous discussion regarding the necessary issues, but suffice it to say that the EU is almost big enough to set up a complete system. (FTR, I say the same thing about the US--you really want to span eight or nine time zones minimum.)
And how do you know that every string generated by https://www.grc.com/passwords.htm isn't dumped straight into a database somewhere? Possibly with the IP address of the client?
There are scores or hundreds of near-trivial applications & libraries that can be used to generate high security strings. You don't need web scale for this.
"Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the government for a redress of grievances."
Check that final clause. I just pray you're not a US citizen.
To my understanding, this should not be the case. What they require is the hash vector that exists at the end of some block, whatever state is being carried by the chain, and the following blocks.
Re: @AC ... The cat is pretty well out of the bag already
The m16 was specifically designed by NATO to NOT kill, on the theory that the invading Soviet troops would tend for their wounded. It earned the moniker "Widowmaker" in Viet Nam because the troops using it ended up themselves dead so often.
Yes, you can kill with a .22. Also, with bare hands. But the recommendation for effective self defense? My sensi was maximal rank, and he kept a .38 at the house. Well, more than one.
Re: Great outcome, but what about over here?
Glad to see someone already did the Sam Colt. I'll see you with Dr. Who: https://www.youtube.com/watch?v=TNxh4uxLkco
Re: If its mission critical
That is rather my point. You don't have to build the hard drive yourself. You don't have to understand the REALLY crazy stuff the bios is doing. What you need to understand is the MTBF & failure recovery mode for the service provided by this foreign piece of equipment that you have brought into your data center and trustingly plugged into your network. (And RAIDs themselves do fail. That's why the big boys don't use them, by the way.)
Same thing with cloud services. If you know how to use them, they provide facilities for resilience that would bankrupt an SMB to match. If you don't, well...
Re: If its mission critical
But why do you trust disk drives that someone else has built?
If it's mission critical, then you must do a thorough rundown of what can go wrong, and ensure that each of them are properly handled. (Generally in pairs.)
Let's start with an electrical outage. If your in-house servers are all in the same city, then you do NOT have resiliency against electrical outages, and probably not against cable cuts.
How many ISPs are you connecting through? If the answer is one, again, you do NOT have resiliency.
I'm not really in the mood to repeat (from last week) the list of things that can take you down that I learned while an SRE at Google.
For smaller operations, cloud can get you levels of reliability at far, far lower prices than DIY. It does require that you know what you are doing. And yes, if G is being stupid about the way that they are handling billing problems, then stay away.
Re: Simply fit all computers with sundials.
Ahh, water clocks. I am informed that Dark Start power generation sites in the US often use them to get there frequency right should they need to restart the grid.
We had some National Agency dedicated to the Security of our communications. I bet they would have figured out that this sort of thing was a likely problem years ago...
Seriously, if our governments were half as interested in protecting us as they say, this sort of thing would not pass initial review.
Re: I would think that the situation is simple
I saw the proposal on the cypherpunks mailing list precisely to that effect--that if crypto is a munition, that the 2nd amendment would apply.
“Pervasive Monitoring is an Attack”
Sweet. The end of Google & much of Facebook.
Don't hold your breath, though.
Re: Solving the wrong problem?
If that is the case, then why is Ansible constantly adding computational capabilities to their "text file"? Loops (with local variables), conditionals, macro expansions which are inherited from a Turing-complete language, but NO. NO TESTS. WE DON'T DO THAT.
Ansible is particularly problematic because you have to fight it to test the very complex logic that is encourages you to put into these files. At least Chef encourages testing.
Solving the wrong problem?
I worked with Chef or a year and a half, and later with Ansible. With a year and a half at Google as well.
While these tools can be very useful, I have become convinced that they are just "wrong". The tagline "infrastructure as code" is used by all of them. It is an excellent tagline, but what does it mean? When you move a problem into the space of "code", the proper workman is a programmer. If the code is big enough, you want a software engineer. Okay. So the proper users of these tools are SWEs. Not operations engineers. This matters a lot, because the tools of a SWEs are programming languages, libraries, and service APIs. Not DSLs.
You were right to bring me into the room. The problem is not going to be solved by really good hackers (no offense to the Ops Engineers that will instruct me in the fundamentals of their crafts in order for me to function in this space)--you need a SWE. Now, give me the tools that I use in my craft, and let me do my job.
I'm not much of a believer in coin, but this is some pretty weak sauce.
First of all, a great number of the coin hacks have been because people don't understand security. Wallets getting stolen, or their owner being threatened with catastrophic loss of blood, are not failures of coin in any meaningful sense. Exchange owners scamming out is nothing but old fashion commodities fraud. It's not until you get into exchange hacking and/or "smart" contract exploits that you are talking about anything particular to coin, and I would argue that most or even all exchange hacking is no different than hacking of any other commodity exchange being hacked.
The difference, then, is almost entirely down to a lack of professionalism and/or threat awareness.
The one remaining hacking issue is "smart" contract exploits. Yes, this is a big and unique risks. And it would be almost nonexistent if the safe arithmetic operations were cheap instead of the unsafe ones. So yes, Etherium has a serious problem because it failed to define a VM that was safe in default mode for certain core operations.
I remain highly skeptical about the dangers of deflation for currencies that are divisible to the extent that most coin is. I think that the mechanics are quite different.
Far more serious to me are the fact that these markets are so small & thin that they are highly volatile & easily manipulated. Furthermore, if they ever DO get large enough to be considered a threat to the fiat currencies, less than 1% of the US budget and you set up enough mining rigs to own a majority. Oops.
Speaking of the fiat issuers, until you can keep the soldiers off your lawn by paying in coin, don't bet against the fiat currencies.
K8 != K8s
I always assumed
That if you want to HaveIBeenPwned, that the response would be, "You have now".
Re: 30-40% gain from HT.
As always, "it depends." I worked on the STI consortium's Cell microprocessor, which had a 2-threaded PPC core. I can easily see 30-40% gains in workloads, which is different from system level improvements. The wait time for an L1 cache hit is typically 3-4 cycles. L2 will likely run you near 20. That, by itself, is a lot of time try to fill in with computations for a single thread.
Then there is the matter of floating point instructions. They ran the numbers, and the SPUs were designed with enough registers (128, AIR) to keep six threads of computations running on a single thread of execution. So a floating-point intensive workload will quite easily see even speed improvements >50% for two threads.
General system speed improvements will drop substantially (I very much believe the 10-15% there) because of cache contention, and a lot of l2 fetches will just drain your execution units regardless.
Re: Core issues
I wasn't really complaining, other than to point out that Intel's refusal to implement the same solution for TLBs that it did for caches may be entirely understandable from a technical standpoint.
The only work that I ever have done that worried about TLB architecture parameters was as an employee of a manufacturer. But, as my job was validation, I tended to work from public documents. I did not work at Intel, however, and they were at the time notorious for being tight with their information. AMD, by comparison, put out cycle-accurate simulators for people to play with.
This article did an excellent job of explaining TLBs. The one thing that they did not explain is exactly how TLBs on modern processors tend to be architected. It is VERY believable to me (with my 10-years out of date experience) that Intel's TLBs simply cannot be easily split the way that you can split a much, much larger data caches.
That doesn't mean that they are justified in refusing to accept this as a legitimate side channel.
My memory is that we've had side channel attacks due to data-dependent pathing for over a decade. As I recall (from these pages), the attack was RF monitoring. At the time, this was not considered too serious, as it required 1) physical access and 2) processors that were "boring"--that is NOT putting too much noise on the line with things like hyperthreading & out of order execution.
But there were even earlier discussions (from cypherpunks, as I recall) about data-dependent pathing being a side channel gimme. Literally, this has been talked about for twenty years. I was under the impression that the hard-core crypto implementations had taken this into account.
As I mentioned earlier, this class of attacks is much, much harder too pull off if you are running four or more threads.
> 3 steps
Yeah, no. Sure, that can work for a small organization, but you don't want to try that for more than a few hundred repos. The bandwidth costs alone will absolutely kill you.
This is a bulk data move, and the fine folks at Google are super-motivated to make this go down well. In fact, the folks are Azure are also well motivated, because if they get blamed for a mess, then they will be charged with vendor lock-in, not to mention the general concern in the industry involving u$ and quality.
1) Gitlab gets its servers up and running in Google. Checks indicate that they function properly.
2) Google provides Azure with physical media to transfer the data.
3) Azure safety scans the physical media provided by Google, and creates backups.
4) The backup physical media is transfered to the Google datacenters.
5) The Google safety scans the physical media, and plugs it in.
6) If you are quick, Gitlab sets upstream branches on the Google repos to point to Azure, and updates them periodicaly. If you are not quick, it might be cheaper to do a second physical transfer with a delta.
7) MAGIC: Gitlab has its Azure servers redirect to the Google servers as the repos come up to date.
8) Gitlab updates its DNS records to point to the Google servers.
9) Gitlab shuts down the Azure servers.
10) Azure securely overwrites or destroys the SANs with private repos. The public ones might be turned into mirrors, or just overwritten.
At least, that's my first guess. :P
> Post it notes in a locked draw, I challenge anyone to defeat this fool proof method over the internet.
You're using an internet-connected lock, correct? All the cool kids are doing it!
A quick scan suggests that in California, fraud is a tort. So monetary damages, but not prison. Shame. However, if a substantial part of their business is found to be fraudulent, then RICO (the Federal anti-mafia statute) might kick in...
Re: Will this actually stop them selling our movements?
This has no (direct) implications on the actions of the data mongers. It would be truly extraordinary for the judiciary to insert itself a that level. The court will come in when a law or regulation gets challenged. Not before.
Re: Thermal considerations?
I like the way you think--but the designers are WAY ahead of you. For instance, Apple laptops would sleep between keystrokes--in 2000. I know that the AMD Athlon would power down the parts of the FPU not in use _every cycle_. That's not as big a deal as clock distribution, but I know I heard designers talking about powering down the clocks to the FPU when the fpu enable bit was not set.
Yes, crazy, really crazy, power saving measures became a thing near the death of bipolar (transistor) gates. The design teams saw no reason to ignore those lessons when MOSFET happened. Much has changed in the ten years since I moved on, but I am completely confident that they are only adding techniques when it comes to power savings.
Are your IoT gizmos, music boxes, smart home kit vulnerable to DNS rebinding attacks? Here's how to check
My ISP-provided subnet is on 192.168.0. Mine is .57. Not immune, but not gonna but heads with the ISP .0 or .1 either.
Buffer overflows header parsing?
19-something or the other call....
I can't do this any more. This is just demoralizing.
Re: SRE view
If your goal is five nines, you need to engineer for 6. That's 30 seconds per year on average. If you are down for an hour, you've blown your budget for more than a century. What's the mean time between a multi-state event of hurricane, artic blast, or volcano/earthquake? These things only sound outlandish until you run the numbers.
Re: 5 hours isnt bad actually
If there is any SRE in the room, 5 hours is ridiculous in this case.
1) EVERY microprocessor has an internal temperature sensor that signals thermal runaway, and even WinBloze is not stupid enough to ignore this. This condition can be read from the OS. It is insanely irresponsible for this alarm not to be aggregated to the dashboards under the limited set of "IGNORE EVERYTHING ELSE AND LOOK HERE" alerts.
2) Same thing with the aircon units. If any of these fail, there should be claxons in the data center, and an alert in the previously noted set for the operations center(s).
3) As soon as the problem was identified as aircon, jobs should have been migrated away from the datacenter as quickly as possible as the root cause analysis proceeds. (I would hesitate to try to automate this. Deciding which DC to move jobs to can be a real art.) This also requires that the jobs in question can in fact be migrated between DCs. It is irresponsible to sell cloud without education customers about the need to support involuntary DC moves.
4) Note: SRE does not alert on RED. SRE alerts on YELLOW. In other words, unless there was a catastrophic failure of the air con, the alerts in 2 happen before the aircon actually fails. Likewise, the alerts in 1 happen before any servers actually shut down.
5) If we assume that 1 & 2 are implemented as 4 specifies, then as servers are drained of applications, they are shut down. If the aircon failure is only partial, the heat budget of the dc can balance while a lot of jobs are still running. (And if the dc is set up to include passive cooling, there is only ever a partial aircon failure.)
6) None of the above involves any level of management approval, or even knowledge unless some enterprising first-liner decided to read through some playbook.
In other words, and aircon failure in a properly instrumented dc in a mature cloud offering has a decent chance of having 0 customer impact. This is the job of SRE.
I'm surprised that IRC wasn't mentioned in the article. It has been used for CnC for a long time, and it suffers from the same weakness. The channel being used can be blocked (and regularly is).
This is not abuse of blockchain. This is a primary use case.
Non-forgeable non-traceable communications (when the attacker is a major nationstate) is one of the primary goals of the cypherpunks. That such communications can be used for evil purposes is regrettable.
Oops. Bit of a memory tick after a decade. MySQL replication could NOT handle curtime() & the like. We wrote the triggers to do that. :D
"SQL Server greybeards"? Hardly in this case. We had a MySQL server doing almost this exact thing in 2008. Our farm was in various Texas cities when I started, most states when my turn came in the buy out & shut down cycle. The difference? No troubles replicating all types of data for MySQL.
(In 2009, I wrote code to use federated views to constrain which columns we exported. I learned all about those triggers.)
Re: not as secure as optical media?
That policy looks pretty bad if someone fat-fingers the lock. Or if someone sets the lock when they lack authority. Or if they set it based on a misunderstanding. Or if a regulation or law changes that requires something else. Or if they are a bad actor.
OTOH, it would be easy to move such a policy to the cloud by simply requiring prepayment for the storage of & access to the data...
Yes. These chips don't have the ability to phone home any more than existing ones. That is--they don't. As for the pre-boot "management engine" root kits, that's another matter entirely.