Posts by Charles 9 16605 publicly visible posts • joined 10 Jun 2009
"And keeping on voting for only the two officially vetted and sanitized candidates from the two entrenched parties will somehow dis-entrench them?!"
The point is it's a no-win situation. The two parties are SO entrenched it would take a disaster of unmitigated proportions (I'm talking the level of one of them triggering World War III) or a candidate with Messianic levels of charisma. The parties feed on each other. Trying to feed a third party simply causes one of the two incumbents to get stronger, they stay in power, stomp out the third party and allow the other incumbent to recover. Look what's happened to EVERY third party candidate to appear since Ross Perot. Not one state and only token present in the absolute tally.
"At any rate if it could somehow be proven that had the US not legalized gay marriage he would have never killed anyone, I'll bet even the most ardent anti-gay conservatives wouldn't want to see the gay marriage law rolled back as a way to appease people like him."
Point is it's an election year. ANYTHING newsworthy WILL alter the political landscape; it's unavoidable. I'm not using the incident as an example for or against, only as an example of people looking for a way to make a guaranteed statement. Frankly, the only reason we haven't seen a nuke go off in anger is because no one of this level of crazy has managed to get their hands on one...YET.
"In the grand scheme of things, issues like abortion, gay marriage or transgender bathrooms aren't all that important to most of us in the US..."
Until they provide the impetus for the worst mass killing in US history, one that FINALLY trumps Bath Township AND used legally-purchased guns (the killer was a lone wolf sleeper).
"Google has plenty of power, since Android is the only real choice for OEMs who want to sell smartphones given that Apple won't license iOS and Microsoft and RIM are on life support."
They don't have "walking on the sun" power, though, meaning they don't have the power to compel manufacturers to make phones even if the conditions don't favor them. They can always walk out and leave Google to figure out how to make phones without a manufacturer on their side. At least Apple has a hardware division and makes its own phones in-house.
Trouble is every time they try they usually hit a wall: performance demands which necessarily take a hit with things like tagged memory. Who cares about security if the job doesn't get done in time? You can't just get it done right OR get it done fast. You MUST get it right AND fast at the same time or things break...
And yet so much software is still written for it. Something must be going for it even if it's pretty damn complex.
PS. Why would this specifically break setjmp/longjmp? Direct jumping IIRC is not affected by this: only CALL/RET. Do those two functions rely on the stack in an unusual way?
"In what sense are such virtual machines immune from such attacks?"
Well, at some point, the code MUST go through the CPU, meaning it should be able to screen even these. If malicious bytecode or interpreted code causes the compiler or interpreter (both of which are native) to act funny, this should catch it. Anything else and you're looking at high-level malware which will likely have a few other catches involved, but even then if high-level malware is trying to exploit the lower-level stuff, this can still act as a safeguard.
"This is where I begin to wonder, if the part above can be borked by a 2-pronged attack...??? Hackers first find a loophole in the 'shadow watcher' and tackle that (sidestep CET)."
To do that, they'd have to find a hardware exploit since they're talking about something directly in the CPU.
"Zooming out to macro level for a sec... The Bangladesh-Swift Sony hackers, intercepted the return confirm and manipulated that to make it seem like the transfers were legit (hence no exception thrown). Could the same happen here?"
Only again by a hardware exploit since that would involve intercepting a memory bus, something much harder to do than a network or device bus.
"What I'd like to see is a hardware based LOCK system to prevent any manipulation of code whether its on hard-drive or in memory. The whole idea of self-modifying code is a disaster anyway. But Imagine code that was fixed like an original DVD. That's how it should be from disk to memory. Data on disk should be separated from code permanently and at a hardware level, so any weakness in OS can't be exploited."
You're calling for a Harvard architecture. But much as you hate self-modifying code, it's essential in certain restricted environments or those where speed is essential. Without the idea that code is data and data is code, you couldn't have things like a JIT compiler, for example.
"The process of installing apps i.e. pressing a fixed DVD, would need to be a special process. You don't want it to be cumbersome for users but it also can't continue down the path of silent installs."
Problem here is that you run into an Unhappy Medium. Since Users are Stupid (and You Can't Fix Stupid), there's a need for silent installs of mission-critical stuff like security patches. Meaning you have an overlap where NO ONE is happy.
"But if a program wanted to install itself or update code, I'd like to think that the user would be forced to do something physical like insert a master USB key / turn a physical key, something eternal, so that users better appreciate that what we have right now with UAC is oversight done by painting in water."
And then people just lose their keys and complain.
"more than 5 files got modified in the last 0.1 seconds"
This can happen when you copy a bunch of small files. Too much risk of false negatives resulting in click fatigue (think UAC). Also, smarter malware can just "smurf" and encrypt things slowly to stay under the radar.
"warn against running executables in zip files"
They already do that as far as it goes. It warns against running files just downloaded (shows the signature if it has one), warns against running things off a network, and so on.
"And how about getting rid of the feature in Windows that hides the file extension, so "file.doc.exe" doesn't show as "file.doc"?"
That's mainly to prevent unintentional extension altering, which casual users may not have the skill to undo. Anyway, e-mail programs and archive managers (the main conduits for this trick) show the extensions.
"I'm pretty sure that better Antivirus hooks and cleverer email programs (so obviously not Outlook then) are the key to reducing malware attacks."
Smarter malwares target and disable these or just go above them straight to the kernel where they can't be dislodged. Some even go into the BIOS, MBT, or EFI, making them nuke-proof.
But in the end, as you say, until a better human comes along, this is the best we can do.
A direct push before a register pass still allows for this. It's one reason modern chips keep larger numbers of registers. Excessive recursion will overflow the stack no matter what. There's also concepts like placing parameters in a structure and passing a pointer to it by register (rearranges the parameter transfer a bit but makes for a cleaner stack).
"Because in (almost?) all programming language implementations the stack also contains data (local variables)."
And last I checked, there are plenty of alternative ways around that. If the parameters are popped into registers or local memory when the function starts, that gets around it. Passing by register for low-parameter-count functions is an option, too. If this is the price for having a hardened stack, it may be worth paying. As I think about it, do CPUs these days also check for 1:1 stack use by functions (checking that SP at CALL = SP after RET) to guard against stack misalignment?
What you propose is basically a variant of Intel's idea, BTW (the shadow stack is your call stack). They probably can't do a full separation for legacy reasons since the logic in most CPU architectures is that RET pops the return address.
As for catching overflows, that's a nontrivial solution since functions may be required to work on items outside of its local context (pointer dereferencing, for example), creating conflicting issues of context. Due to the architecture, bounds checking has to be left to the code itself, especially when speed efficiency is required.
"Inventory stock taking is mandatory for insurance purposes."
Oh? Then explain the article El Reg had just last week: Computerised stock management? Nah, let’s use walkie-talkies.
And as noted before, what if they keep the stolen phones in faraday cages until their IMEIs are reprogrammed so that Apple can't see them anymore?
Given they were taken from a Genius Bar (where the phones go to get repaired), odds are the necessary credentials to unlock them were taken, too. Otherwise, the phones can't be verified fixed. Plus once they're taken, the thieves probably know a way to reprogram the IMEI and/or can then fence them off to foreign parts where blacklisting isn't enforced.
Yes it would because now all the drivers go to Google, not the manufacturers, meaning Google can now push updates that don't have to go through the manufacturers (who actually have incentive NOT to do so: Planned Obsolescence). If Google don't do it, they could end up on the hook for the next big exploit.
Only one problem. Linux on ARM lacks a lot of driver support, especially for those key mobile chips, which are protected by the chip makers under patents and NDAs. That's why the code for them is delivered as binary blobs only. The key element here is that these blobs need to go to Google, not the device manufacturers. This would allow Google to bypass the device makers and push updates anyway.
"Chip vendors would not give Google the blobs and Google would not waste their own time maintaining firmware for devices they didn't produce. Google might as well produce all the devices themselves which they don't want to do."
But they may HAVE to do it. Think about it. The Stagefright exploit is in the Android code, not the driver code or anywhere else, but in the part of the code that belongs squarely to Google. If the lawyers play their cards right, they can assert that Android is not fit for purpose unless Google can find a way to get past the manufacturers and patch it and anything else that comes along. Either Google has to FORCE manufacturers to send updates (which they won't as they have perverse incentive NOT to; they'd sooner drop out), they have to take control themselves, or Google is likely to face severe civil and maybe even criminal liability. Ask the bean counters which will be worse for the bottom line.
"Why would they need the code from the chip makers? They would give the chip makers an API and they would supply blobs that implement it just like they do now."
Except these blobs would go straight to Google, not to the manufacturers. That's the reason to take it proprietary: to take control of the OS away from the manufacturers and put it square in Google's corner the same way iOS is all Apple. Thanks to things like Stagefright, Google's potentially on the hook (since the exploit code is in Android itself, NOT in the driver blobs) unless they can control the update channel, and the only way to control the update channel is to take control away from the manufacturers. There's no other way around it because the manufacturers in this case will be actively interfering (because they want a Captive Market so they can tell customers, "Your phone is obsolete. Time for a new one *ka-ching!*").
You're talking Compaq v. IBM. The catch here is that Compaq provably used clean-room techniques to duplicate the BIOS featureset and then release their own API for it. According to Oracle, Google flat-out copied the header files directly which could well be under pay-to-see restrictions like the Red Book for audio CDs, which you have to BUY a copy to read.
OK, who pays for the second carrier when it's so remote that the ONLY way a carrier will be willing to roll out is by an exclusivity contract? Now you're going to have places with NO coverage because it's not worth it to cover the place otherwise.
Remember, a lot of utility monopolies are de facto, not de jure, a simple result of utilities having high upfront costs that pretty much limit viability in smaller markets.
The other poster is saying you can turn this fetish around by having the browser (in your sleep) look for grotesque imagery. Very few people will be able to tolerate highly-varied grotesque imagery for very long. Sure, you can have people into gore or grandpas who would actually get turned on by granny porn, but having all these fetishes in the same person? Unlikely. Thus you need the filter (otherwise, you'll need to check the late night meal selection as well as make sure the toilet isn't prone to clogging).
The thing with Qi is that you don't need a matching cradle for each and every device you own (Lose the cordless phone? The base is now useless, and vice versa). At least you're not a slave to the manufacturer. Pick whatever suits you, put it down, and it goes to work. Breaks? Easy enough to get another one. Not only that, it saves wear and tear on your USB socket.
So you're basically saying, "Live with it." As evidenced by the dominance of Windows, especially in the consumer sphere, lots of people apparently already do, thank you very much. If that means people are stupid, then people are stupid. After all, the people most likely to call cigarettes "cancer sticks" are the smokers, so that means you can't win.
We'll live with it. You can live with it, too. After all, You Can't Fix Stupid.
I'm just saying that for many people the application comes before the OS, regardless of what anyone else may say or do. If you wish to make people change their OS, you have to solve the application problem first, and while things like WINE and VMs provide some outs, it's not a 100% solution or even a 50% solution. Hardware can have Windows-only drivers and are too custom to be supported elsewhere (like industrial C&C interfaces--very custom stuff probably running on antiquated hardware: two strikes against virtualization). It's basically the Network Effect.
"And, again, "but, but I can't run this game on anything but Windows" just means you can't run that game. The price for running Windows has always been that one gives up freedom and sponsors crime."
Well, then, if you expect people to stop sponsoring "a criminal organization" as you put it, you need to put forth some alternative options. Telling people to stop committing crime is a waste of breath if there are no honest options available.
"This could be prevented by replacing the operating systems of donated computers with suitable open source alternatives that allow greater user control. For example, Ubuntu is freely available, regularly maintained, and was conceived based on African values. Why not?"
Probably because they need specific applications to work...Windows-ONLY applications. Unless you can deliver the total package (OS AND Applications), you won't be able to get people to jump ship.
"What we are seeing here is a major limitation of the existing web/internet protocols. IP (v4 and v6) has no real concept of network quality and so is unable to feedback to a source that it is trying to feed a 1mbps data stream into a 56kbps pipe."
What you are seeing is a major limitation of a network where there's no overlord. Plain and simple, if someone insists on being sent, they'll impersonate a high-priority packet or just wrap the whole business in encryption so you can't tell what's what (and since at least some encrypted connections are high-priority like time-sensitive financial information, you can't de-priorititize encrypted traffic in bulk). About the only way you could defuse this is to create a completely-stateful internet where everything can be identified (but then that defeats the anonymity factor that makes the Internet so appealing at times).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
