Sign in to follow this  
Followers 0

Hosting, 32 or 64?

20 posts in this topic

Posted

Quick question, I have purchased a 'blank' VPS which I can use any of the linux templates to install. It will be used for hosting a few websites, a small game server and teamspeak. Would 32bit or 64bit be better for these applications? Instinct tells me 32 bit, it's CentOS 5.

 

I am no Linux expert but I know my way around CentOS the best, so I'd rather stick with that distro and to what I know.

 

Thanks!

Share this post


Link to post
Share on other sites

Posted

If you have more than 4GB of RAM, you need x64. X32 only reads up to ~3.5 of your RAM.

Share this post


Link to post
Share on other sites

Posted

If you have more than 4GB of RAM, you need x64. X32 only reads up to ~3.5 of your RAM.

It's a 3GB VPS, so perhaps best with 32bit? Is there any difference in performance?

Share this post


Link to post
Share on other sites

Posted

If you have more than 4GB of RAM, you need x64. X32 only reads up to ~3.5 of your RAM.

 

That is factually incorrect, but mostly by technicality. Most modern Linux distributions compile their 32-bit x86 kernels with PAE support. Pysical Address Extension is a feature of the processor than, when used by the operating system, allows it to map more than 4GB of RAM into a 32-bit address space. So, for example, if Debian Jessie were installed with the linux-image-3.10-3-486 kernel it would be 32-bit and thusly only able to address up to 4 GB of RAM. However Debian Jessie were installed with the linux-image-3.10-3-686-pae kernel it would still be 32-bit but would be able to address up to 4 PiB of RAM thanks to PAE.

 

Then there is the issue of the x32 architecture versus i386, i486, i586, and i686. Despite the fact that some people use x32 as shorthand for 32-bit x86 processors (i.e. i386-i686), it has distinct meaning in Linux. In the kernel x32 refers to another ABI for the x86 architecture which attempts to squeeze extra performance out of modern AMD64 (64-bit x86) processors by using CPU instructions and registers introduced in AMD64 while retaining the 32-bit pointers found in i686. This theoretically allows it to maintain a lower memory footprint while simultaneously taking advantage of architecture improvements that directly improve performance. However x32 is still very much in the experimental stage, and Debian and Gentoo are the only distributions I am aware of that have working ports of it. Despite its current experimental status, the point stands that it is incorrect to refer to 32-bit x86 processors as x32 when you actually mean to reference i686 (with or without PAE).

 

It's a 3GB VPS, so perhaps best with 32bit? Is there any difference in performance?

 

It is a common misconception to think that the one-and-only thing that 64-bit processors offer over their 32-bit counterparts is the ability to address more than 4GB of RAM. There are substantial architectural improvements in AMD64 over i686 that programs compiled for that architecture will be able to take advantage of. While there are still relatively few applications for Windows that take advantage of those architectural improvements outside of heavy computational programs and the operating system itself, that is not the case in Linux. Virtually every program in modern Linux distributions has been compiled to take advantage of the 64-bit x86 ISA. Web servers, such as Apache and nGenx for example, often see a substantial performance boost on 64-bit systems. Despite the fact that CentOS 5 uses an extremely old kernel and userland which will not perform nearly as well as a more modern software stack, I still recommend it above i386 CentOS if your hardware is capable of supporting it. That said, CentOS 6 would be a huge improvement if your VPS provider allows it. Personally, however, I would go with Debian 7 because it generally performs much better than CentOS, especially on the relatively weak machines VPS providers usually supply.

Share this post


Link to post
Share on other sites

Posted

Xorangekiller, does a 64-bit systems offer better security over a 32-bit one?

Share this post


Link to post
Share on other sites

Posted

Xorangekiller, does a 64-bit systems offer better security over a 32-bit one?

 

Inherently? No.

 

It is another common misconception that 64-bit systems offer better security than 32-bit ones, but that has more to do with how Microsoft decided to implement 64-bit Windows than anything else. When Microsoft introduced Windows Vista x64 it was the first mainstream 64-bit operating system Microsoft had ever offered. Of course it stood on the shoulders of Windows XP x64, Windows Server 2003 x64, and the IA64 versions of Windows, but Microsoft never pushed those on the average consumer. Since the market penetration of 64-bit versions of Windows was so low, Microsoft felt more comfortable introducing additional security measures into the kernel in their 64-bit edition than in their 32-bit one. Considering the trouble hardware manufactures had developing drivers for the new graphics architecture and audio subsystem introduced in Windows Vista - and the negative PR the lack of good drivers generated for Microsoft soon after launch - it was probably a good decision to make the most heavy-handed security improvements exclusive to Windows Vista x64.

 

One of the most notable improvements introduced in Windows Vista x64 was mandatory driver signing, which was designed to counteract rootkits that assumed kernel-level privileges by installing themselves as drivers. To Microsoft's credit, this - along with the slew of other x64-only security measures introduced in Windows Vista - made it much more difficult for malware to assume complete control of the system. Since these security improvements have been carried through to newer 64-bit versions of Windows, namely Windows 7 and Windows 8, and even slightly improved with new Windows releases, "64-bit" has become almost synonymous with "more RAM and better security" in some tech circles. And for a good reason at that: as I have explained, 64-bit versions of Windows are definitely more secure at a low level than their 32-bit counterparts. However, that is not inherently an effect of the processor, but rather a design decision Microsoft made in Windows.

 

Linux has historically had much better kernel-level security than Windows. Additionally, Linux has incorporated new kernel security mechanisms over time just like Windows. However the port to AMD64 was far less substantial for Linux than for Windows because there was no need to worry about making changes that would break out-of-tree kernel modules. Unlike Windows, Linux makes no attempt to maintain a stable ABI between major kernel releases. Instead, it is up to module maintainers to either get their code merged into mainline Linux or to keep up with subsystem changes themselves (much like NVIDIA does for their proprietary graphics driver). Therefore any security improvements developed during the Linux AMD64 port applied equally to all kernel flavors, including i686. The same is true for most other operating systems that have been ported to AMD64. Windows is the outlier, but its large consumer marketshare helps to perpetrate the myth among techies that the AMD64 ISA has inherent security benefits.

Share this post


Link to post
Share on other sites

Posted

That is factually incorrect, but mostly by technicality. Most modern Linux distributions compile their 32-bit x86 kernels with PAE support. Pysical Address Extension is a feature of the processor than, when used by the operating system, allows it to map more than 4GB of RAM into a 32-bit address space. So, for example, if Debian Jessie were installed with the linux-image-3.10-3-486 kernel it would be 32-bit and thusly only able to address up to 4 GB of RAM. However Debian Jessie were installed with the linux-image-3.10-3-686-pae kernel it would still be 32-bit but would be able to address up to 4 PiB of RAM thanks to PAE.

 

Then there is the issue of the x32 architecture versus i386, i486, i586, and i686. Despite the fact that some people use x32 as shorthand for 32-bit x86 processors (i.e. i386-i686), it has distinct meaning in Linux. In the kernel x32 refers to another ABI for the x86 architecture which attempts to squeeze extra performance out of modern AMD64 (64-bit x86) processors by using CPU instructions and registers introduced in AMD64 while retaining the 32-bit pointers found in i686. This theoretically allows it to maintain a lower memory footprint while simultaneously taking advantage of architecture improvements that directly improve performance. However x32 is still very much in the experimental stage, and Debian and Gentoo are the only distributions I am aware of that have working ports of it. Despite its current experimental status, the point stands that it is incorrect to refer to 32-bit x86 processors as x32 when you actually mean to reference i686 (with or without PAE).

 

I only knew x32 vs x64 from Windows. I always knew for x32 to only support ~3.5GB. Wasn't aware of that PAE stuff. Thanks for lecturing me. :)

Share this post


Link to post
Share on other sites

Posted

Inherently? No.

 

It is another common misconception that 64-bit systems offer better security than 32-bit ones, but that has more to do with how Microsoft decided to implement 64-bit Windows than anything else. When Microsoft introduced Windows Vista x64 it was the first mainstream 64-bit operating system Microsoft had ever offered. Of course it stood on the shoulders of Windows XP x64, Windows Server 2003 x64, and the IA64 versions of Windows, but Microsoft never pushed those on the average consumer. Since the market penetration of 64-bit versions of Windows was so low, Microsoft felt more comfortable introducing additional security measures into the kernel in their 64-bit edition than in their 32-bit one. Considering the trouble hardware manufactures had developing drivers for the new graphics architecture and audio subsystem introduced in Windows Vista - and the negative PR the lack of good drivers generated for Microsoft soon after launch - it was probably a good decision to make the most heavy-handed security improvements exclusive to Windows Vista x64.

 

One of the most notable improvements introduced in Windows Vista x64 was mandatory driver signing, which was designed to counteract rootkits that assumed kernel-level privileges by installing themselves as drivers. To Microsoft's credit, this - along with the slew of other x64-only security measures introduced in Windows Vista - made it much more difficult for malware to assume complete control of the system. Since these security improvements have been carried through to newer 64-bit versions of Windows, namely Windows 7 and Windows 8, and even slightly improved with new Windows releases, "64-bit" has become almost synonymous with "more RAM and better security" in some tech circles. And for a good reason at that: as I have explained, 64-bit versions of Windows are definitely more secure at a low level than their 32-bit counterparts. However, that is not inherently an effect of the processor, but rather a design decision Microsoft made in Windows.

 

Linux has historically had much better kernel-level security than Windows. Additionally, Linux has incorporated new kernel security mechanisms over time just like Windows. However the port to AMD64 was far less substantial for Linux than for Windows because there was no need to worry about making changes that would break out-of-tree kernel modules. Unlike Windows, Linux makes no attempt to maintain a stable ABI between major kernel releases. Instead, it is up to module maintainers to either get their code merged into mainline Linux or to keep up with subsystem changes themselves (much like NVIDIA does for their proprietary graphics driver). Therefore any security improvements developed during the Linux AMD64 port applied equally to all kernel flavors, including i686. The same is true for most other operating systems that have been ported to AMD64. Windows is the outlier, but its large consumer marketshare helps to perpetrate the myth among techies that the AMD64 ISA has inherent security benefits.

 

TL;DR - Go with x64

 

Okay in all honesty, thanks. Got some pretty good new info that I didn't know yet about Linux from your posts :) Thumbs up mate!

 

Oh on a side note. I was probably one out of the 3 persons who actually used x64 XP lol :p Back then wen't into a shop while in the UK to buy a legit copy of it and they told me a price of around

Share this post


Link to post
Share on other sites

Posted

I only knew x32 vs x64 from Windows. I always knew for x32 to only support ~3.5GB. Wasn't aware of that PAE stuff. Thanks for lecturing me. :)

 

Windows actually does not have an x32 flavor. Furthermore its 32-bit x86 flavor does not support PAE, although there are unofficial binary kernel patches you can find online for enabling it. Also, a true x32 implementation, such as the one found in Linux, inherently supports more than 4GB of RAM because PAE is a requisite part of the AMD64 ISA which x32 makes use of.

1 person likes this

Share this post


Link to post
Share on other sites

Posted

There is little to no reason to go 32bit on a server unless you're looking for backward compatibility. Generally speaking, most servers are 64bit now due to the need for more RAM (among other things) and you'll find that the 64bit software is the mainstream supported version and 32bit exists for legacy reasons. 64bit support is more than just enhanced RAM allocation amounts as I'm sure was adequately covered earlier by xorangekiller :)

 

On the desktop 64bit is lagging as mainstream due to the limited memory and calculation pressure...

 

Keep in mind, Microsoft doesn't even publish a 32bit version of Windows Server and almost none of their server software has a current 32bit version. I know the OP mentioned Linux, so Windows isn't all that important, but I'm sure you get the idea.

Share this post


Link to post
Share on other sites

Posted

x64 does offer at least one security benefit with enhanced ASLR. ASLR randomizes code/data in memory, so that it is difficult for malware, say trying to infect the user from a web page, to guess where the functions are that it needs to break out of containment. The problem with 32-bit, is that the malware can fill the entire 4GB address space pretty easily which can cause the malware code to execute when you mean to execute some other function. With x64 this is basically impossible, most systems have not even the tiniest fraction of memory installed that x64 can address, so trying to fill the address space from malware will result in the system or target app running out of memory and crashing, which sounds bad, but is definitely better for most people than being compromised fully. x64 can also greatly increase speed in at least some circumstances, I know that a file duplicate finder I made that was based on SHA512 was 2x as fast in x64 as 32-bit for example. (obviously you don't get that benefit very often, otherwise everyone would be talking about it..)

Share this post


Link to post
Share on other sites

Posted

x64 does offer at least one security benefit with enhanced ASLR. ASLR randomizes code/data in memory, so that it is difficult for malware, say trying to infect the user from a web page, to guess where the functions are that it needs to break out of containment. The problem with 32-bit, is that the malware can fill the entire 4GB address space pretty easily which can cause the malware code to execute when you mean to execute some other function. With x64 this is basically impossible, most systems have not even the tiniest fraction of memory installed that x64 can address, so trying to fill the address space from malware will result in the system or target app running out of memory and crashing, which sounds bad, but is definitely better for most people than being compromised fully. x64 can also greatly increase speed in at least some circumstances, I know that a file duplicate finder I made that was based on SHA512 was 2x as fast in x64 as 32-bit for example. (obviously you don't get that benefit very often, otherwise everyone would be talking about it..)

 

I think I adequately dispelled this myth in my second post in this thread, but just to reiterate: there is no inherent security benefit to the AMD64 processor architecture or the software explicitly compiled for it. Like I pointed out in that post, Microsoft introduced more security features in their 64-bit version of Windows than its 32-bit counterparts, but that is in no way tied to the ISA. ASLR is a security feature of the Windows operating system, not something the processor provides as a consequence of using the AMD64 instruction set. In fact, Linux has a kernel security feature very similar to ASLR that is present in all flavors, including i686 and ARM variants.

Share this post


Link to post
Share on other sites

Posted

I think I adequately dispelled this myth in my second post in this thread, but just to reiterate: there is no inherent security benefit to the AMD64 processor architecture or the software explicitly compiled for it. Like I pointed out in that post, Microsoft introduced more security features in their 64-bit version of Windows than its 32-bit counterparts, but that is in no way tied to the ISA. ASLR is a security feature of the Windows operating system, not something the processor provides as a consequence of using the AMD64 instruction set. In fact, Linux has a kernel security feature very similar to ASLR that is present in all flavors, including i686 and ARM variants.

 

I was addressing this:

 

Xorangekiller, does a 64-bit systems offer better security over a 32-bit one?

 

Which is, that 64-bit *systems* do offer better security than 32-bit ones. Also this is not a MS technology, never said it was, Mac/Linux/Windows all have ASLR, and all can benefit from x64's increased virtual address space over 32-bits', I know Windows 8 has HeASLR (high entropy ASLR) for using the x64 address space to benefit ASLR, I assume Linux and Macs do too by now.

Share this post


Link to post
Share on other sites

Posted

I was addressing this:

Which was the same post I addressed with the post I last referenced.

 

Which is, that 64-bit *systems* do offer better security than 32-bit ones. Also this is not a MS technology, never said it was, Mac/Linux/Windows all have ASLR, and all can benefit from x64's increased virtual address space over 32-bits', I know Windows 8 has HeASLR (high entropy ASLR) for using the x64 address space to benefit ASLR, I assume Linux and Macs do too by now.

I know that ALSR is not a Microsoft-specific technology. In fact, that was part of my point. However, I think you are confusing features offered by the operating system and features offered by the processor (instruction set). The reason I brought up Linux support of ALSR was to point out the fact that it is available on processor architectures which are not 64-bit. The increased address space of 64-bit processors - by itself - only gives the operating system access the ability to access more RAM. That is a huge benefit in-and-of itself, but most 64-bit processor architectures released to-date have also incorporated instruction set improvements beyond their capability to address more than 4GB of RAM. The x32 ABI in Linux would not exist if that were not the case. However even those extra instructions do not mean that the architecture inherently offers better security. For example, ARMv7 offered more instructions over ARMv6 but they are both 32-bit ISAs. Similarly, the increased address space offered by the 64-bit ARMv8 ISA is not the only improvement offered by the new architecture. Hence it is categorically incorrect to claim that 64-bit systems inherently offer better security, although practical operating system design decisions - such as the one that Microsoft made with the 64-bit version of Windows to incorporate extra security features - could mean that the 64-bit version of one operating system offers more security features than the 32-bit version of that same operating system. However that has nothing to do with the fact that the processor offers a larger address space.

 

Share this post


Link to post
Share on other sites

Posted

The question was about 64-bit *systems*, not ISAs. A 64-bit system gives an address space larger than the ram amount that will be installed in any system any time soon, thus making x64 ASLR resilient to attacks that 32-bit ASLR is not, therefore 64-bit *systems* offer improved security. Again, the original question did not mention ISA, but did mention systems. You seem to be trying to paint this as being like OS specific features like MS driver signing, when all OSes that use virtual addressing benefit from x64 ASLR, it is not something that is patented by one company and deployed in one OS, therefore it applies to x64 systems. Things like driver signing, although restricted to Windows x64, could be done in 32-bit OSes, you *can not* however increase the entropy of 32-bit ASLR to 64-bit levels on a 32-bit OS, so again, a x64 system security benefit.

1 person likes this

Share this post


Link to post
Share on other sites

Posted

Okay, J_R_G, I now see your point. You are right, 64-bit operating systems can theoretically make better use of ASLR due to the larger address space. However until we start using significantly more than 4GB of RAM, which I suppose some big iron enterprise machines do, the benefit is negligible at best. Also, 32-bit systems with PAE can still make use of > 4GB address space for ASLR.

Share this post


Link to post
Share on other sites

Posted

Thanks for ceding that much. However I would say wrong on both points that followed. It relies on you running out of physical memory, before you reach the virtual address space limit. So 1GB, even 256MB would be just as good as 192GBs, so long as you are far south of the x64 virtual address limit (16 EB) which everyone will be for probably 30 years. Also PAE can use > 4GBs of RAM, but you get only 4GBs per process, so filling that process' 4GBs up with exploit code would result in a infection regardless of how much was installed and usable in the system for other processes. I take it you're an user of a PAE OS..? :)

Share this post


Link to post
Share on other sites

Posted

However until we start using significantly more than 4GB of RAM

 

 

Hrm, my main workstation has 16GB of ram, and my server has 32GB of ram, which I max out on a regular basis....  Most of my clients have 16GB in their servers, with one having 128GB of memory, and considering there are mainstream boards that support 128 GB of quad channel DDR3, I think we're at the standardization point now that most off the shelf OEM systems come with 8GB or more.   So I would say we've passed the point of "starting to use significantly more than 4GB of ram".

Share this post


Link to post
Share on other sites

Posted

I take it you're an user of a PAE OS..? :)

 

Actually, no. I have two personal machines. The primary one is AMD64 (Core i5) and the other is ARMv7 (Exynos 5). As for your point about how PAE relates to ASLR, it depends somewhat on the implementation. I admit that while I am somewhat familiar with the implementation in Linux; I only know about the implementation in Windows on a superficial level.

Share this post


Link to post
Share on other sites

Posted

http://www.linuxquestions.org/questions/linux-general-1/32-bit-os-and-4gb-memory-limit-707762-print/

 

If you have a PAE enabled kernel it (the kernel) can access (I believe) 36 bits of address space (64GB). However, since it's a 32 bit system, any one process can only access 32 bit space (4GB).

 

Because the process is restricted to 4GBs, the malware only has to worry about finding/overwriting addresses in that 4GBs, which is not a problem in most cases.

Even if you're referring to the kernel, 64GBs is not much breathing room, that's just $500 worth of RAM.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.