Lots of bugs in 32-bit x86 Linux entry code • Hacker News Board

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

#21

Post by skissane » Thu, Dec 12, 2019, 10:19 PM UTC

> We need real CI resources

It would be easy to boot the 32-bit kernel in a VM as part of a CI pipeline and then run some automated tests to catch issues like this.

(Unless by "real" he means non-virtualised? Is there anything about these bugs that would only reproduce on bare metal?)

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

#22

Post by swills » Thu, Dec 12, 2019, 10:25 PM UTC

dang wrote: post #2

Url changed from https://lwn.net/Articles/805539/ , which points to this. Submitted title was "Essentially no upstream development resources dedicated to x86_32 Linux"

Thank you!

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

#23

Post by topbanana » Thu, Dec 12, 2019, 10:32 PM UTC

cptskippy wrote: post #16

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.

Completely off topic but... Althlon64 was a swift kick in the nuts for Intel, but AMD really didn't followup until Ryzen. I wonder if they're going to stick around and fight this time.

They've got momentum on their side now, but intel won't bow down without a fight. I expect we'll see some real innovation over the next five years.

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

#24

Post by TD-Linux » Thu, Dec 12, 2019, 10:38 PM UTC

skissane wrote: post #21

> We need real CI resources It would be easy to boot the 32-bit kernel in a VM as part of a CI pipeline and then run some automated tests to catch issues like this. (Unless by "real" he means non-virtualised? Is there anything about these bugs that would only reproduce on bare metal?)

I think the issue is not the hardware needed but simply the cost of the extra compute. Linux doesn't have an "official" CI server but relies on third parties running it, and none of them want to spend $ on compute for an architecture they will never use.

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

#25

Post by gdxhyrd » Thu, Dec 12, 2019, 10:38 PM UTC

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.

Sure, but the ones that pay the bills are servers and companies which don't care one bit about i386.

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

#26

Post by vetrom » Thu, Dec 12, 2019, 10:40 PM UTC

skissane wrote: post #21

> We need real CI resources It would be easy to boot the 32-bit kernel in a VM as part of a CI pipeline and then run some automated tests to catch issues like this. (Unless by "real" he means non-virtualised? Is there anything about these bugs that would only reproduce on bare metal?)

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.

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

#27

Post by bonzini » Thu, Dec 12, 2019, 10:44 PM UTC

vetrom wrote: post #26

skissane wrote: post #21

> We need real CI resources It would be easy to boot the 32-bit kernel in a VM as part of a CI pipeline and then run some automated tests to catch issues like this. (Unless by "real" he means non-virtualised? Is there anything about these bugs that would only reproduce on bare metal?)

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.

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

#28

Post by gdxhyrd » Thu, Dec 12, 2019, 10:45 PM UTC

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...

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

#29

Post by ShinTakuya » Thu, Dec 12, 2019, 10:47 PM UTC

cpeterso wrote: post #18

"I strongly suspect that there is at least one bug left." :)

That was a cheeky statement by the author if I've ever seen one.

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

#30

Post by jdsully » Thu, Dec 12, 2019, 10:50 PM UTC

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...

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.