Quotes of the week [LWN.net]

Quotes of the week

Posted Jun 14, 2012 9:33 UTC (Thu) by Felix.Braun (guest, #3032)
Parent article: Quotes of the week

What is the upside of running a x86_64 kernel on a machine with, say, 2 Gigs of RAM? I was under the impression that i386 can handle up to 3 Gigs just fine, with the advantage that pointers only consume half the memory on i386.

to post comments

Quotes of the week

Posted Jun 14, 2012 12:12 UTC (Thu) by richmoore (guest, #53133) [Link] (3 responses)

IIRC the syscall convention for x86-64 is much faster.

Quotes of the week

Posted Jun 14, 2012 13:08 UTC (Thu) by k3ninho (subscriber, #50375) [Link] (2 responses)

And you get twice the CPU register count.

Quotes of the week

Posted Jun 14, 2012 21:44 UTC (Thu) by ballombe (subscriber, #9523) [Link] (1 responses)

and much faster multiprecision arithmetic too!

Quotes of the week

Posted Jun 15, 2012 23:18 UTC (Fri) by faramir (subscriber, #2327) [Link]

If you are running an x86 user space...

1. syscalls probably won't be faster.
2. there certainly won't be more registers for user space apps.
3. multiprecision arithmetic is rare no matter what.

Even with those issues, I would still be happy to stop using a PAE kernel if I could retain my x86 user space. Unfortunately, I don't run Debian and it appears that is the only distribution that supports this out of the box.

Quotes of the week

Posted Jun 14, 2012 12:32 UTC (Thu) by nevets (subscriber, #11875) [Link] (8 responses)

The kernel only has access to 885 megs at a time. Userspace has 3G address range and 1G for the kernel. But the kernel uses over 100 megs for things like virtual memory (where modules are loaded) and accessing the hardware (iomem mapping), and even mapping pages for the rest of RAM.

Also the kernel needs to create a page descriptor for every page of RAM. This page table must always be present and takes up that 885 megs. When you have a lot of RAM, this table grows, but the total access does not. It's like raising taxes on people on social security or other fixed income.

All kernel related operations take place in that 885 megs. Even if you have 2Gigs or 4Gigs of RAM, the kernel does not use any more. If the kernel needs to do any operations on the memory outside this range, (besides copy_from_user) it must map that page into its own address space (where the extra 100 megs are used for). This slows down the kernel and the system in general.

For systems with 2, 4, or possibly even 8Gigs, the kernel is still remarkably efficient in doing this, but it still has its cost. When you go above 8gigs, now you are just asking for trouble. I may have been a bit extreme when saying anything over 1Gig should produce that message. But it definitely should say it for over 8G (and possible just over 4).

Read Documentation/vm/highmem.txt for more information.

Quotes of the week

Posted Jun 14, 2012 13:02 UTC (Thu) by nevets (subscriber, #11875) [Link]

> This page table must always be present and takes up that 885 megs

I meant to say "takes up part of that 885 megs", the way I wrote it, it looks like it takes it all up. But with a big enough amount of RAM, it could.

Quotes of the week

Posted Jun 14, 2012 13:14 UTC (Thu) by PaXTeam (guest, #24616) [Link] (6 responses)

on i386 the userland/kernel address space split is configurable, so if one can live with less virtual address space for userland, the kernel can be more efficient with 2-3GB RAM as well, but beyond that HIGHMEM is inevitable. an area where amd64 is worse is security due to the lack of segmentation, the baby went with the bathwater unfortunately...

Quotes of the week

Posted Jun 14, 2012 14:19 UTC (Thu) by nevets (subscriber, #11875) [Link] (5 responses)

> on i386 the userland/kernel address space split is configurable

If you're going to modify the kernel, might as well just install x86_64 instead.

> an area where amd64 is worse is security due to the lack of segmentation, the baby went with the bathwater unfortunately

Bah! Linux never bother with much of the segmentation crap that i386 uses to begin with. Sure, it separates userspace from kernel space, but it does nothing to protect one task from another. Page tables are used for that purpose.

Show me one security errata that was the result of removing segmentation from x86. And I mean for Linux.

Quotes of the week

Posted Jun 14, 2012 15:39 UTC (Thu) by PaXTeam (guest, #24616) [Link] (4 responses)

> If you're going to modify the kernel, might as well just install x86_64 instead.

it's an existing kernel config option, nothing needs to be modified.

> Linux never bother with much of the segmentation crap that i386 uses to begin with.

pre 2.0 (iirc) task switching? set_fs()? TLS? ;)

> Sure, it separates userspace from kernel space,

nope, (vanilla) linux uses flat segments, there's no separation at the segment level.

> but it does nothing to protect one task from another. Page tables are used for that purpose.

true but what's that matter here? ;)

> Show me one security errata that was the result of removing segmentation from x86. And I mean for Linux.

every single kernel-dereferences-unintended-userland-pointer bug (something that UDEREF in PaX protects against if you want to see how it's done properly). and asking for actual security errata when the declared policy from high up is to actively suppress them is... too funny if it wasn't so sad at the same time :P. in any case, http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+ker... should get you started.

Quotes of the week

Posted Jun 14, 2012 16:11 UTC (Thu) by nevets (subscriber, #11875) [Link] (3 responses)

> it's an existing kernel config option, nothing needs to be modified.

Modifying config options does modify the kernel. Do you need to recompile?

> pre 2.0 (iirc) task switching? set_fs()? TLS? ;)

I started working with 2.0, so I should never had said 'never' ;-)

Yeah, I knew about TLS, that's why I said 'much of segmentation', instead of saying 'any of segmentation'.

> nope, (vanilla) linux uses flat segments, there's no separation at the segment level.

Ah sorry, was thinking that it did. It's been a while since I've actually worked with segments. I know the kernel was not limited against accessing userspace, but I was thinking that userspace had the added protection of segments to protect against accessing the kernel.

> when the declared policy from high up is to actively suppress them is... too funny if it wasn't so sad at the same time

Are you saying that since Linux uses a flat segment space that the bugs happen for both i386 and x86_64?

Quotes of the week

Posted Jun 14, 2012 16:23 UTC (Thu) by PaXTeam (guest, #24616) [Link] (2 responses)

> Modifying config options does modify the kernel. Do you need to recompile?

i think for most people (esp. kernel devs) modify = patch, and not 'reconfigure'. but for all i care, i got the point across :).

> but I was thinking that userspace had the added protection of segments to protect against accessing the kernel.

even if the default segments were set up this way, there's modify_ldt and TLS to get around them.

> Are you saying that since Linux uses a flat segment space that the bugs happen for both i386 and x86_64?

yes (if 'happen' = 'are exploitable'). UDEREF on i386 uses segmentation to prevent exactly this class of bugs from becoming exploitable beyond DoS.

Quotes of the week

Posted Jun 14, 2012 16:38 UTC (Thu) by nevets (subscriber, #11875) [Link] (1 responses)

> yes (if 'happen' = 'are exploitable'). UDEREF on i386 uses segmentation to prevent exactly this class of bugs from becoming exploitable beyond DoS.

Which goes back to my original point. Why run vanilla Linux i386 on x86_64. It's better to just run x86_64 kernel with a i386 userspace, then an i386 kernel if you have extended RAM.

Quotes of the week

Posted Jun 14, 2012 18:11 UTC (Thu) by PaXTeam (guest, #24616) [Link]

sure, an amd64 kernel manages more RAM in a better way but you had a (rhetorical?) question as to why would someone still stick to i386, i just gave you one possible reason (better kernel self-defense), that's all :).