Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lots of bugs in 32-bit x86 Linux entry code

lwn.net

Post reply on HN
Print view View original

31–40 of 110 posts

Re: Lots of bugs in 32-bit x86 Linux entry code

#31

Post by inetknght »

bonzini wrote: post #27
vetrom wrote: post #26

Earlier quoted context omitted.

Not always. Cache speculation bugs for example I dont think are covered by emulations. (At least not explicitly. If the mmu model is the same and transparent enough I suppose those could 'pass through' but only if they're implemented on the same plat form.

You can certainly exploit Meltdown from a VM. The hypervisor tries hard to stay out of the way, and on a properly configured VM the vmexits should be few enough while running compute-bound code that microarchitectural side channels are very well exploitable.

For clarity, in this context I think @ vetrom was talking about emulation, not a virtual machine. A virtual machine makes use of the native instruction set (relying on the hardware) to create a machine within a machine and naturally can only create virtual machines of identical hardware capabilities (or a subset thereof). Emulation does all of that in software and could emulate even a completely different architecture.

Re: Lots of bugs in 32-bit x86 Linux entry code

#32

Post by Dylan16807 »

inetknght wrote: post #31
bonzini wrote: post #27

Earlier quoted context omitted.

You can certainly exploit Meltdown from a VM. The hypervisor tries hard to stay out of the way, and on a properly configured VM the vmexits should be few enough while running compute-bound code that microarchitectural side channels are very well exploitable.

For clarity, in this context I think @ vetrom was talking about emulation, not a virtual machine. A virtual machine makes use of the native instruction set (relying on the hardware) to create a machine within a machine and naturally can only create virtual machines of identical hardware capabilities (or a subset thereof). Emulation does all of that in software and could emulate even a completely different architectur…

Okay, but the original comment said VM and almost every desktop and server has a processor that can natively run x86 in a VM.

Re: Lots of bugs in 32-bit x86 Linux entry code

#33

Post by opencl »

heavyset_go wrote: post #4
human_banana wrote: post #3

Maybe because nobody uses 32-bit x86 anymore?

There were 32-bit netbooks being sold the last time I looked in 2015.

The really fun part was when they launched the first 64 bit Atom CPUs (Bay Trail) and then a bunch of them got shipped with only 32 bit UEFI and cannot boot in 64 bit mode.

Re: Lots of bugs in 32-bit x86 Linux entry code

#34

Post by acqq »

bryanlarsen wrote: post #6
human_banana wrote: post #3

Maybe because nobody uses 32-bit x86 anymore?

No, that's the i386 architecture, which is still well supported AFAICT. x86_32 is a funny architecture that requires 64 bit chips but uses 32 bit pointers. http://www.h-online.com/open/features/Kernel-Log-x32-ABI-get...

No, see the source from Linux kernel:

https://github.com/torvalds/linux/blob/master/arch/x86/Kconf...

For all x86 processors, now there is a name "X86_32" which "depends on !64BIT" (i.e. 64BIT flag has to be off).

and there is a name "X86_64" which "depends on 64BIT" (i.e. 64BIT flag being on).

Under new convention X86 is a common prefix for both 32 and 64-bit kernels for x86 processors, and the suffix _32 means the kernel uses only 32bit instructions, and _64 that it uses 64bit instructions.

And also, there's handling of an old arch name "i386" which is recognized to mean 64BIT is off and if only "x86" is seen as arch name then there is a prompt that asks 64BIT yes or no. It also notes that the old name used for kernel with 64BIT off was "i386" and the old name used for kernel with 64BIT on was "x86_64".

Finally, the support for X32 ABI (allowing running executables which use 64-bit instructions but only "short" 32bit pointers in 64-bit kernel https://en.wikipedia.org/wiki/X32_ABI) is enabled in my 64-bit distro:

    ~$ sudo grep -P G_X86_X?\\d{2}= /boot/config-$(uname -r)
    CONFIG_X86_64=y
    CONFIG_X86_X32=y
The first line means this is a 64bit kernel for x86 processors, the second that X32 support is enabled on that kernel.

In short, there are two kinds of X86 kernels:

X86_32 -- formerly known as i386

X86_64 -- formerly known as x86_64

and an option for existence of X32 ABI in X86_64 called CONFIG_X86_X32.

Re: Lots of bugs in 32-bit x86 Linux entry code

#35

Post by zozbot234 »

opencl wrote: post #33
heavyset_go wrote: post #4

Earlier quoted context omitted.

There were 32-bit netbooks being sold the last time I looked in 2015.

The really fun part was when they launched the first 64 bit Atom CPUs (Bay Trail) and then a bunch of them got shipped with only 32 bit UEFI and cannot boot in 64 bit mode.

They have to _boot_ with a 32-bit UEFI bootloader, but can run a 64-bit kernel and userland. Fedora Linux even allows for this while keeping secure boot on; Debian supports it as well but the interaction with secure boot is buggy, so you need to turn it off. Not sure about other distros, however.

Re: Lots of bugs in 32-bit x86 Linux entry code

#36

Post by jandrese »

gdxhyrd wrote: post #28
jdsully wrote: post #5

I remember being an early adopter of 64-bit Linux with my Athlon64 back in the day. Lots of stuff was broken and I got a lot of debate on whether it was any faster or worthwhile at all. It's really cool to see the technology curve go full circle.

Worthwhile? We had PAE for a long time, sure, but I think it was fairly obvious when the Athlon 64 appeared that 4GB was not going to cut it, given some people already had 1GB at home...

PAE was always a terrible hack though. It caused so many problems that I'm super glad native 64 bit became the norm shortly before it would have had to become widespread.

Re: Lots of bugs in 32-bit x86 Linux entry code

#37

Post by srgpqt »

jdsully wrote: post #30
gdxhyrd wrote: post #28

Earlier quoted context omitted.

Worthwhile? We had PAE for a long time, sure, but I think it was fairly obvious when the Athlon 64 appeared that 4GB was not going to cut it, given some people already had 1GB at home...

At the time 1GB was a ton of memory and few applications would use anywhere near that. A 64-bit kernel took on fairly quickly but actually compiling 64-bit applications took a lot longer. Consensus at the time was the memory overhead of larger pointers outweighed the benefits of extra registers.

1GB is still a lot of memory. If anything, we've only learned to squander all available memory.

Re: Lots of bugs in 32-bit x86 Linux entry code

#38

Post by vokep »

srgpqt wrote: post #37
jdsully wrote: post #30

Earlier quoted context omitted.

At the time 1GB was a ton of memory and few applications would use anywhere near that. A 64-bit kernel took on fairly quickly but actually compiling 64-bit applications took a lot longer. Consensus at the time was the memory overhead of larger pointers outweighed the benefits of extra registers.

1GB is still a lot of memory. If anything, we've only learned to squander all available memory.

This. The basic stuff they did back then didn't magically inflate. Except, it seems from afar that thats exactly what happened. But it didn't, and it doesn't have to look like that from afar.

Re: Lots of bugs in 32-bit x86 Linux entry code

#39

Post by derefr »

srgpqt wrote: post #37
jdsully wrote: post #30

Earlier quoted context omitted.

At the time 1GB was a ton of memory and few applications would use anywhere near that. A 64-bit kernel took on fairly quickly but actually compiling 64-bit applications took a lot longer. Consensus at the time was the memory overhead of larger pointers outweighed the benefits of extra registers.

1GB is still a lot of memory. If anything, we've only learned to squander all available memory.

Go ahead and buffer 4k video streams to disk, I dare you :) There's a reason that even modern appliance platforms like Apple/Android TV need multiple GBs of memory, and it ain't bloat.

Re: Lots of bugs in 32-bit x86 Linux entry code

#40

Post by devit »

jandrese wrote: post #36
gdxhyrd wrote: post #28

Earlier quoted context omitted.

Worthwhile? We had PAE for a long time, sure, but I think it was fairly obvious when the Athlon 64 appeared that 4GB was not going to cut it, given some people already had 1GB at home...

PAE was always a terrible hack though. It caused so many problems that I'm super glad native 64 bit became the norm shortly before it would have had to become widespread.

It's not a terrible hack, it's just 32-bit virtual addresses with a larger physical address space.

It only caused problems because some kernels used to expect that all physical memory is mapped at all times (and some hardware could only DMA to 32-bit physical addresses, but that's a problem with 64-bit CPUs as well).

Post reply on HN