Windows 9, 128-bit ?

[jimmyb]

also I think you're better off combatting buffer overflow attacks with instruction/data memory flags and/or going to Harvard architectures.

 

[Unknown-One]

which is to say it will deter all the zero people attempting to brute force on a 64b address space.

Which is to say it immediately breaks any brute-force attack that worked on a 32bit OS.

 

[DLGenesis]

with that amount of memory i believe having everything loaded into memory would only increase computer speeds.

 

[jimmyb]

Which is to say it immediately breaks any brute-force attack that worked on a 32bit OS.

Ok.....? So does a 64b OS, which we already have.

 

[Dogs]

There are features that can take advantage of the entire 64bit (and 128bit) address space, even if you only have a couple of gigabtes of RAM installed. Address Space Layout Randomization (ASLR) uses the entire address space, and randomly assigns chunks of it to physical resources. This makes it impossible to attempt exploits that target specific memory addresses.

Of course, as anybody who actually knows what they are talking about at all is aware of, that's a completely irrelevant point, because we're still only on 48-bit address spaces, so clearly the CPU data-path width is not the limiting reactant here

...In fact, what you pointed out below is a double-edged sword:

ASLR can be defeated by scanning the entire address space with some intelligent pattern-matching, which is easily-done on 32bit systems (only 4GB of addresses to scan). This becomes MUCH more difficult on 64bit systems (16 Exabytes of addresses to scan, even if there's only 4GB of physical RAM installed). As you can imagine, 128bit would make ASLR even more effective (and no, the OS doesn't need to be 128bit native to handle 128bit addressing)

...If 64-bit and 128-bit address spaces are too large to naïvely scan, then they're far too large to effectively manage with structures like page tables. The overhead of managing such a large address space is so enormously large that it simply wouldn't be practical to implement them for the sake of ASLR.

We should also point out here that if you're able to scan the address space to find out which address your shell code lives at, you've to some extent already figured out how to run arbitrary code anyways. It's not like you can very easily tell a web server to scan for your payload and return to you the address so that you know what to overwrite the stack's return address with. The situations where an attacker would have been stopped by ASLR on a 64-bit address space but not stopped by ASLR on a 32-bit address space sound pretty contrived and unrealistic to me.

There are also benefits that have nothing to do with address space... Some operations (like high-grade encryption / decryption) are legitimately faster to compute with 128bit registers.

Fortunately you can stick two 64-bit registers together and call it a 128-bit one, and it's something the instruction set already supports, so there isn't really anything to gain there. Of course if we take into consideration Amdahl's law, a performance increase will only be as large as the portion of the program it targets. Unless encryption/decryption are the majority of what your program does, there isn't much performance gain to be had either way.

also I think you're better off combatting buffer overflow attacks with instruction/data memory flags and/or going to Harvard architectures.

Realistically the former over the latter, though.

 

[Unknown-One]

Ok.....? So does a 64b OS, which we already have.

Nope, those exploits will still attempt to run on a 64bit OS thanks to Windows having complete 32bit backwards compatibility through the WoW layer.

Difference is, they'll never complete on a 64bit system because there's simply too much address space to churn through in a reasonable period of time.

Of course, as anybody who actually knows what they are talking about at all is aware of, that's a completely irrelevant point, because we're still only on 48-bit address spaces, so clearly the CPU data-path width is not the limiting reactant here

Even if ASLR was for some reason limited to 48bit, that's still a LOT more entropy than a 32bit address space allows. So no, that point was not irrelevant by any standard.

...If 64-bit and 128-bit address spaces are too large to naïvely scan, then they're far too large to effectively manage with structures like page tables. The overhead of managing such a large address space is so enormously large that it simply wouldn't be practical to implement them for the sake of ASLR.

Not sure what you're on about here. A founding principal of ASLR is that more bits of entropy = more secure and harder to brute-force. The additional entropy afforded by the 64bit address space is part of what makes ASLR on 64bit Windows more secure than ASLR on 32bit Windows.

Fortunately you can stick two 64-bit registers together and call it a 128-bit one, and it's something the instruction set already supports, so there isn't really anything to gain there.

Yes, I already covered this a few posts back. That's something that SSE has allowed for the last 15 years or so.

And if you're combining registers to run 128bit code, then obviously there WAS some benefit to running 128bit for the task at hand... which, again, was my original point (we'll see 128bit used WHERE APPROPRIATE, but it's unlikely that we'll ever see an end-to-end 128bit x86 OS)

 

[pxc]

I've changed my mind. 64-bits isn't enough anymore. Give me a 65-bit OS now!

 

[AndreRio]

those high huge number of bits like 128bit, 256bit ++ will become necessary as we grow in amount of data gatered!? we are going to need huge memory capacity computers, to map the universe, or like making artificial intelligence possible. I think we are already headed that way. today things like 1gigabyte will be like 1kilobyte in the future. in a way, it is important and will become necessary.

 

[Tsumi]

those high huge number of bits like 128bit, 256bit ++ will become necessary as we grow in amount of data gatered!? we are going to need huge memory capacity computers, to map the universe, or like making artificial intelligence possible. I think we are already headed that way. today things like 1gigabyte will be like 1kilobyte in the future. in a way, it is important and will become necessary.

The point isn't whether or not higher bit levels will be used or not. The point is whether or not the higher values are necessary at this point in time, which they aren't.

 

[Dogs]

Even if ASLR was for some reason limited to 48bit, that's still a LOT more entropy than a 32bit address space allows. So no, that point was not irrelevant by any standard.

It is irrelevant, though, because it doesn't apply in any way, shape or conceivable form to the jump from 64-bit to 128-bit.

Not sure what you're on about here.

Do you not understand how page tables work? If you have a 128-bit virtual address space, you have to keep track of the status of those addressable bytes of memory through one mechanism or another. Given that there are 2^128 of those, I don't care what mechanism you plan on using...it won't be a manageable task for today's hardware. Even if there were a benefit from a security standpoint to be had, that benefit is completely obliterated by the fact that a 128-bit address space is completely unmanageable.

A founding principal of ASLR is that more bits of entropy = more secure and harder to brute-force. The additional entropy afforded by the 64bit address space is part of what makes ASLR on 64bit Windows more secure than ASLR on 32bit Windows.

The point of ASLR isn't about making memory difficult to find. It's about making it non-deterministic. ASLR will be largely effective regardless of how large the address space is, because the main purpose of it is to make the location of payloads and the location of the stack unpredictable. They don't have to be uncomputable searches...it just needs to be something you can't reliably locate first try. In nearly every attack using a stack buffer overflow vulnerability, you're going to be unable to sit there and scan the system to find your payload address, since doing so implies you already have the ability to run arbitrary code on the system. The point of ASLR is to eliminate the attacker's ability to predict where their shellcode lives or predict where the stack lives. If they can predict where they need to go, it's easy to inject that address and jump there. If they can't, they can only guess, and guessing is generally always a one-shot thing anyways. If you guess wrong, things will most likely blow up, and unless the show is being run by complete idiots, that will be cause of observation and investigation. Certainly you're not going to be able to try every address until you find your payload, because you will have encountered a fatal error as soon as you jump the program counter to an address that doesn't make sense.

Yes, I already covered this a few posts back. That's something that SSE has allowed for the last 15 years or so.

Right, so where is the benefit in having a 128-bit data path, then? The very limited amounts of code which use the 128-bit registers can already do so effectively.

And if you're combining registers to run 128bit code, then obviously there WAS some benefit to running 128bit for the task at hand... which, again, was my original point (we'll see 128bit used WHERE APPROPRIATE, but it's unlikely that we'll ever see an end-to-end 128bit x86 OS)

Like I said before, you will only see as much benefit as the optimized code is used. If it's not used very much, you won't see very much benefit. Your original statement was that there are benefits to moving to 128-bit that aren't memory related, and the proceeded to give two examples that offer no tangible benefit. The point is, you haven't made any sort of point here.

 

[TCM2]

The point of ASLR isn't about making memory difficult to find. It's about making it non-deterministic. ASLR will be largely effective regardless of how large the address space is, because the main purpose of it is to make the location of payloads and the location of the stack unpredictable. They don't have to be uncomputable searches...it just needs to be something you can't reliably locate first try. In nearly every attack using a stack buffer overflow vulnerability, you're going to be unable to sit there and scan the system to find your payload address, since doing so implies you already have the ability to run arbitrary code on the system. The point of ASLR is to eliminate the attacker's ability to predict where their shellcode lives or predict where the stack lives. If they can predict where they need to go, it's easy to inject that address and jump there. If they can't, they can only guess, and guessing is generally always a one-shot thing anyways. If you guess wrong, things will most likely blow up, and unless the show is being run by complete idiots, that will be cause of observation and investigation. Certainly you're not going to be able to try every address until you find your payload, because you will have encountered a fatal error as soon as you jump the program counter to an address that doesn't make sense.

Thanks for clearing that up so elaborately. The half-knowledge here is really annoying.

 

[jimmyb]

Not sure what you're on about here.

My point here is there are significantly diminishing returns. By your own admission 64b address space is already sufficient.

 

[Unknown-One]

Like I said before, you will only see as much benefit as the optimized code is used. If it's not used very much, you won't see very much benefit. Your original statement was that there are benefits to moving to 128-bit that aren't memory related, and the proceeded to give two examples that offer no tangible benefit. The point is, you haven't made any sort of point here.

So what are YOU saying, exactly? That 128bit isn't needed and we should rip the ability to run 128bit mode out of SSE / AVX? Because that's what it sounds like you're rooting for.

I'm going to stick with the camp that says 128bit will be used when appropriate (and encryption is very appropriate, even if you don't seem to think so).
As an example, Bitlocker uses AVX support to prop-up real time full disk encryption. Microsoft obviously felt there was tangible benefit there.
If gaming is more your thing, check out PCSX2. It calls up SSE fairly often because it's emulating the 128bit registers of the PS2's EmotionEngine CPU.

See? Used when-appropriate in normal 32bit and 64bit x86 programs.

By your own admission 64b address space is already sufficient.

Never said that. It should be obvious that, as computers get faster, so do brute-force attacks.

Eventually, that leaves even a 64bit address space easily scan-able.

 

[jimmyb]

We should also point out here that if you're able to scan the address space to find out which address your shell code lives at, you've to some extent already figured out how to run arbitrary code anyways.

I think executable base locations are often not randomized, so you can return to your payload then search for more useful functions in that limited space. Alternatively you can brute force outside the executable by overflowing multiple times (assuming you don't crash the target process) - I think this is probably quite tricky though.

 

[-Dragon-]

Eventually, that leaves even a 64bit address space easily scan-able.

Current DDR3-2133 = 17GB/s, assume socket 2011 for 68GB/s total, 64 bits is 18 billion billion bytes, total scan time, 252,645,135 seconds or 8 years. RAM speed doesn't exactly double too often, but there was a 4 year gap between DDR2 and DDR3 being released and the highest speed DDR3 is twice as fast as the highest speed DDR2 so lets say RAM speed doubles every 4 years, and lets assume people have to reboot every 30 days to install updates, then we have 28 years before RAM is fast enough to be able to scan the full 64-bit range before the computer has to be rebooted for updates and everything moves around again. 4 years per doubling is quite generous too as it's 2014 and we still don't have DDR4 yet, DDR3 has been out since 2007, and I don't think we've even doubled RAM speed in that time. Also I'm not sure over 20 days really counts as "easily scanable" since the computer would be mostly useless the entire time. It's another 20 years before we get it down to less than a day and 16 years past that before it's down to less than an hour.

64 bit address space might be easily scanable in about 64 years.

Neat how that worked.

 

[cthulhuiscool]

I don't blame ya for the question, I was very bitter when my 24 exabytes ram in my gaming rig capped at 16.

 

[B00nie]

It appears to me that people are missing the whole point about 128-bit architectures. The whole point is _not_ the maximum theoretical available memory, it's about instruction widths. If you have a 128-bit CPU you can run more code in parallel using the same clock cycles. This increases computing power as die scaling and clock speed has hit practical walls.

 

[jimmyb]

If you have a 128-bit CPU you can run more code in parallel using the same clock cycles.

Are you really suggesting the ability of modern processor and OS to exploit instruction level parallelism is restricted by the size of registers and/or address space????

 

[-Dragon-]

It appears to me that people are missing the whole point about 128-bit architectures. The whole point is _not_ the maximum theoretical available memory, it's about instruction widths. If you have a 128-bit CPU you can run more code in parallel using the same clock cycles. This increases computing power as die scaling and clock speed has hit practical walls.

No, it's not.

AVX-512

512-bit data instructions.

Expanded register encoding allowing 32 512-bit registers.

All with a 64-bit CPU!

 

[Unknown-One]

Current DDR3-2133 = 17GB/s, assume socket 2011 for 68GB/s total, 64 bits is 18 billion billion bytes, total scan time, 252,645,135 seconds or 8 years.

That's assuming the attack forcibly cycles every single virtual address through physical memory.

If that doesn't need to take place, the attack can be carried out MUCH faster (the limiting factor becomes CPU cache speed rather than RAM speed)

Edit:
For reference, the L1 cache on a modern intel processor (Haswell arch) can handle I/O at 64 bytes per-clock (SiSoft Sandra reports L1 cache bandwidth of 945 GB/s on a Core i7 4770k)
This is double the cache bandwidth afforded by Iveybridge (yes, cache bandwidth doubled in a single generation). With leaps like that taking place, scanning the entire address space suddenly isn't impractically far-off...

If the entire job could be contained within L1 cache, we're already looking at only ~182 days to scan the entire range, not 8 years.

 

[jimmyb]

So what are YOU saying, exactly? That 128bit isn't needed and we should rip the ability to run 128bit mode out of SSE / AVX? Because that's what it sounds like you're rooting for.

As far as the industry jargon goes, 128b+ SIMD instructions aren't really the same thing as 128b CPUs and OSes; these are instructions which operate on vectors of 64/32/16b words and (outside of Sony marketing) have never been used to describe a CPU architecture.

The bitness of an ISA is traditionally defined by the largest supported integer word size and/or the number of address size. Very often this is the same.

I'm going to stick with the camp that says 128bit will be used when appropriate (and encryption is very appropriate, even if you don't seem to think so).
As an example, Bitlocker uses AVX support to prop-up real time full disk encryption. Microsoft obviously felt there was tangible benefit there.

Again, SIMD extensions aren't what makes a CPU or OS 128b. If you disagree, then I'm pleased to tell you that we *already* have 512b computers and operating systems!

Never said that. It should be obvious that, as computers get faster, so do brute-force attacks.

Eventually, that leaves even a 64bit address space easily scan-able.

Are you seriously advocating 128b processors based on their ability to avoid buffer overflow attacks when:
1) This is already infeasible on 64b processors and will be for some time
2) There are many existing and proposed safeguards which don't require such obscene architectural changes.

?

 

[-Dragon-]

Even 100x faster you're still looking at a search time of over a month.

 

[Unknown-One]

As far as the industry jargon goes, 128b+ SIMD instructions aren't really the same thing as 128b CPUs and OSes

Never said they were (in fact, I said quite the opposite. That we'd probably never see an end-to-end 128bit x86 implementation). Are you even reading? I've been agreeing with you for over a page now and you keep missing it :-/

Simply said 128bit was being used only where appropriate

Again, SIMD extensions aren't what makes a CPU or OS 128b. If you disagree, then I'm pleased to tell you that we *already* have 512b computers and operating systems!

Again, never said this would make the OS 128bit (I quite clearly mentioned that I was talking about normal 32bit and 64bit applications making use of 128bit). Again, 128-bit only when appropriate to do so.

You're arguing over points I'm not making.

Even 100x faster you're still looking at a search time of over a month.

And? We're already down to 182 days (potentially). At this rate, another couple generations could get that under 30 days.

That's not far off... and that's the point. Sheer size only protects you until performance catches up with you.

And at 182 days... well, kind of timescale already makes this a potential problem for some workstation, and a lot of servers.

Are you seriously advocating 128b processors based on their ability to avoid buffer overflow attacks when:
1) This is already infeasible on 64b processors and will be for some time
2) There are many existing and proposed safeguards which don't require such obscene architectural changes.?

Seriously, ONE MORE TIME. Who said I was advocating a switch to a fully end-to-end 128bit x86 implementation? I'm not, never have been.

Such a change isn't necessary if all you want is a larger virtual address space. You can have a 64bit processor, running a 64bit OS, that can address 128bits of (virtual) memory. Non-symmetrical addressing isn't exactly an exotic concept.
Such a change also isn't necessary to run 128bit instructions (as has been already been discussed ad nauseum in this thread).

Keep the OS 64bit, use 128bit where appropriate. Like I've been saying from the beginning...

 

[jimmyb]

Never said they were (in fact, I said quite the opposite. That we'd probably never see an end-to-end 128bit x86 implementation). Are you even reading?

Sorry. Are you instead advocating a 128b address space?

 

[schizrade]

No, it's not.

AVX-512

512-bit data instructions.



All with a 64-bit CPU!

This whole thread reminds me of the RISC v CISC crap from 15-20 years ago. Then we realized we can strap shit onto CPU's and extend architectures, and none of it mattered anymore.

 

[jimmyb]

This whole thread reminds me of the RISC v CISC crap from 15-20 years ago.

The RISC/CISC debate has evolved somewhat, but is still going strong in my opinion. There is a lot of current research and engineering effort being devoted to moving away from super complex CPUs found in desktop systems.

 

[TCM2]

That's assuming the attack forcibly cycles every single virtual address through physical memory.

If that doesn't need to take place, the attack can be carried out MUCH faster (the limiting factor becomes CPU cache speed rather than RAM speed)

What attack FFS?

If you have the ability to scan memory, you don't need to attack anymore - you're on the box.

An exploit can either jump or not. If it jumps and hits the wrong address, the program likely segfaults. If the system admin is not a complete tool, segfaulting processes have a rate limit.

 

[wonderfield]

I've changed my mind. 64-bits isn't enough anymore. Give me a 65-bit OS now!

I'll use the extra bit to store a boolean indicating whether I like you at any given moment.

GUESS WHAT VALUE IT HAS NOW.

 

[Armenius]

Guys, come on. Stop thinking in binary terms.

We need to evolve and start thinking ternary .

What is that?! A "two?" Blasphemy! Burn him at the stake!

 

[wonderfield]

I'll stop thinking in terms of 0s and 1s when CPUs stop loving 0s and 1s. They love that shit! (Especially 0)

 

[Dogs]

So what are YOU saying, exactly?

What I'm saying is that none of the things you've said so far has substantiated your claim that larger address spaces are useful.

 

[Unknown-One]

What I'm saying is that none of the things you've said so far has substantiated your claim that larger address spaces are useful.

Again, when did I claim that the ONLY advantage was additional address space? Point = missed.

I chimed in initially because I was tired of seeing everyone make that assumption. From my very first post on the subject:

Why does everyone seem to think 64bit and 128bit are only good for addressing additional physical RAM?
[snip]
There are also benefits that have nothing to do with address space... Some operations (like high-grade encryption / decryption) are legitimately faster to compute with 128bit registers.

And yet you're still hung-up on address space related features...

For the record, I don't see what you don't find substantial about being able to use additional bits of entropy. Seems pretty clear-cut, aside from the the whole "diminishing returns" argument (which is self-defeating since computers continually get faster).

 

[TCM2]

being able to use additional bits of entropy

Just. Stop.

 

[MrCrispy]

I thought this thread was started as a joke, since obviously no one would take it seriously.

But apparently I am wrong

 

[drescherjm]

I thought this thread was started as a joke, since obviously no one would take it seriously.

But apparently I am wrong

I was surprised that tomshardware would publish such a rubbish article before I noticed that the article was from October 9, 2009 when there was a chance of having an IA-128. Although Itanium would never ever be used in a desktop windows OS so that part still did not make sense. I actually went back to check the date to make sure it was not April 1. That is when I saw 2009.

 

[jimmyb]

Who said I was advocating a switch to a fully end-to-end 128bit x86 implementation? I'm not, never have been.

Ok so you're not advocating an end-to-end 128b architecture.

And yet you're still hung-up on address space related features...

And you're not totally advocating 128b address space? I can't tell. As noted the benefits are so negligible especially when considered in the context of the additional hardware and software complexity (where it is a resounding no).

Some operations (like high-grade encryption / decryption) are legitimately faster to compute with 128bit registers.

But you are advocating larger registers for operations like encryption, which incidentally already exist in 64b CPUs via SIMD and AES ISA extensions.

I guess I'm not totally sure what your point is.

 

[Dogs]

Again, when did I claim that the ONLY advantage was additional address space? Point = missed.

I chimed in initially because I was tired of seeing everyone make that assumption. From my very first post on the subject:

And yet you're still hung-up on address space related features...

You said, and I quote:

Why does everyone seem to think 64bit and 128bit are only good for addressing additional physical RAM?

There are features that can take advantage of the entire 64bit (and 128bit) address space, even if you only have a couple of gigabtes of RAM installed.

.....and then went on to try and substantiate your claim with completely invalid claims. I.E. you made a claim you couldn't support. Thus, I identified the shortcomings in your logic. What part are you missing here?

For the record, I don't see what you don't find substantial about being able to use additional bits of entropy. Seems pretty clear-cut, aside from the the whole "diminishing returns" argument (which is self-defeating since computers continually get faster).

Because attacks don't rely on being able to arbitrarily scan every addressable byte of memory until they find the address they're looking for. ASLR thwarts attacks where the address of the routine of interest (be it some exploitable library function or your payload) is known or easy to predict in a non-randomized layout. Attacks which aren't thwarted by ASLR on a 48-bit address space aren't naïve brute-force attacks, so they're not going to be thwarted on a 64-bit or 128-bit address spaces either.

 

[Unknown-One]

Ok so you're not advocating an end-to-end 128b architecture.

Exactly, the current arrangement (where 128bit, and larger, registers can be exposted via extensions) is just fine.

64bit CPU, 64bit OS, 128bit used when appropriate.

And you're not totally advocating 128b address space? I can't tell.

I was merely conceding, to all the people who kept yapping about using more RAM as if it were somehow the only benefit of moving to 128bit, that there were some uses for a larger address-space.

But you are advocating larger registers for operations like encryption, which incidentally already exist in 64b CPUs via SIMD and AES ISA extensions.

Yes, exactly! Already exists, which is a point I've been re-stating over-and-over for pages now...

I guess I'm not totally sure what your point is.

That I've been trying to agree with you from the beginning, maybe?

The only difference is that I'm not viciously opposed to larger address spaces being an option.

 

[odoe]

I think this thread has run its course.