| |||||||||||||
|
| |||||||||||||
Kernel prepatch 3.3-rc4
Linus has released the 3.3-rc4 prepatch, a
couple of days later than he would have liked. "This time the reason
for the delay is that we spent several days chasing down a nasty floating
point state corruption that happens on 32-bit x86 - but only if you have a
modern CPU (why are you using 32-bit kernels?) that supports the AES-NI
instructions. And then you have to enable support for them *and* use a
wireless driver that uses it. The most likely reason for that is using the
mac80211 infrastructure with WPA with AES encryption (ie usually
WPA2)." There's lots of other fixes as well, of course; the
short-form changelog can be found in the announcement.
(Log in to post comments)
Ubuntu Posted Feb 19, 2012 15:59 UTC (Sun) by cesarb (subscriber, #6266) [Link]
> but only if you have a modern CPU (why are you using 32-bit kernels?)
If you go to Ubuntu's download page, it recommends the 32-bit version. I always ignore them and get the 64-bit version; it works perfectly on every computer I have tried.
Ubuntu Posted Feb 19, 2012 19:02 UTC (Sun) by tajyrink (subscriber, #2750) [Link]
If the plans haven't changed since November news, the tide is now changing in that Ubuntu 12.04 LTS download pages will recommend 64-bit over 32-bit. Probably with some piece of advise regarding older computers, though.
Even Intel Atom based netbooks have been 64-bit for two years now.
Ubuntu Posted Feb 19, 2012 19:40 UTC (Sun) by gevaerts (subscriber, #21521) [Link]
The 32-bit version of what? The kernel, or the entire distribution? It's entirely reasonable to run 32 bit userspace on a 64 bit kernel.
Ubuntu Posted Feb 19, 2012 21:49 UTC (Sun) by ssam (subscriber, #46587) [Link]
i believe fedora discussed using 64bit kernels in their 32bit edition.
Ubuntu Posted Feb 20, 2012 0:08 UTC (Mon) by ewan (subscriber, #5533) [Link]
Not on x86 it isn't. Historically it might have made sense to avoid the pointer expansion and lose very little, but the difference between x86_32 and x86_64 isn't just the 'bitedness' it's the register set too, so doing that on x86 means throwing away a good chunk of performance, not just the ability to address enormous amounts of memory.
Ubuntu Posted Feb 20, 2012 2:48 UTC (Mon) by kevinm (guest, #69913) [Link]
The "X32" ABI aims to give you the best of worth worlds here - using the x86-64 instruction set but with 32 bit pointers in a 32 bit virtual address space.
Ubuntu Posted Feb 20, 2012 6:41 UTC (Mon) by slashdot (guest, #22014) [Link]
Are Ubuntu or Fedora planning to ship x32 versions?
Ubuntu Posted Feb 20, 2012 8:11 UTC (Mon) by error27 (subscriber, #8346) [Link]
Probably not, given that it hasn't been merged into the kernel yet. :P Peter Anvin just sent an RFC patch for x32 support to LKML yesterday.
Ubuntu Posted Feb 20, 2012 12:03 UTC (Mon) by cladisch (✭ supporter ✭, #50193) [Link]
X32 is not a different architecture, it's just a different interface to access the same 64-bit kernel. (The kernel has to ensure that all pointers returned to userspace are below 4 GB, but otherwise it doesn't need to care how applications manage their memory.)
Therefore, x32 does not need a separate version. I'd expect that eventually, most applications that do not need to access much memory will be compiled as x32 instead of amd64.
Libraries need to be available for both amd64 and x32 (plus i386 for 32-bit compatibility).
Ubuntu Posted Feb 20, 2012 12:29 UTC (Mon) by slashdot (guest, #22014) [Link]
Well, it still requires to compile all packages except the kernel specifically for it, and thus requires a distribution decision to carry an extra architecture.
Distributions could potentially drop 64-bit versions of some programs, but I don't think it's practical, since most software has unbounded memory usage depending on how it's used and how large the documents it's told to open are.
A 32-bit x86-64 kernel could also be a possibility (mostly for 1-2GB virtual machines, or netbook/tablets), although I'm not sure if anyone will ever work on that.
Ubuntu Posted Feb 20, 2012 12:52 UTC (Mon) by gioele (subscriber, #61675) [Link]
> The "X32" ABI aims to give you the best of worth worlds here - using the x86-64 instruction set but with 32 bit pointers in a 32 bit virtual address space.
Doesn't this introduce security problems? Isn't ASLR practically moot with 32-bit pointers? Wikipedia quotes "… 16 bits of address randomization can be defeated by a brute force attack within minutes" [1].
[1] benpfaff.org/papers/asrandom.pdf
Ubuntu Posted Feb 20, 2012 13:26 UTC (Mon) by slashdot (guest, #22014) [Link]
Theoretically it should still be possible to load code at arbitrary 64-bit addresses even with a 32-bit ABI given toolchain support (64-bit PLT/GOT and 64-bit C++ vtables).
You'd still need some code in the lower 4GB to support function pointers, but the dynamic linker can generate and position the thunks dynamically, allowing full randomization with byte granularity (you just need to add a new relocation type that causes generation of the thunk).
Ubuntu Posted Feb 20, 2012 13:29 UTC (Mon) by slashdot (guest, #22014) [Link]
Alternatively, if you are willing to redefine function pointers to point to the 64-bit address of code it's even easier, but that would require changes in software that assumes otherwise.
Ubuntu Posted Feb 20, 2012 22:01 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
remember, this is 32 bit address space for applications, the kernel still has access to the full 64 bit address space.
Ubuntu Posted Feb 21, 2012 10:11 UTC (Tue) by gioele (subscriber, #61675) [Link]
> the kernel still has access to the full 64 bit address space.
But ASLR is a feature that is used to protect user-level code. If an application lives in a 32-bit address space it must be able to access all the libraries in that address space, either directly or via some kind of trampoline. If so, then the attacker's code will also live in the 32-bit address space and be equally able to find the code it needs.
|
|
||||||||||||