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

Evolution of the x86 context switch in Linux (2018)

maizure.org

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Evolution of the x86 context switch in Linux (2018)

#21

Post by monocasa »

loeg wrote: post #12
Someone wrote: post #4

Earlier quoted context omitted.

It enables you to invoke the macro as if it were an expression statement consisting of a function call, regardless of where it appears. For details, see http://c-faq.com/cpp/multistmt.html :

In particular, a single statement. I'm sure the link covers it, but: if (foo) MULTI_LINE_MACRO; Breaks without some wrapper like if (1) { A; B; } or do { A; B; } while (0): if (foo) A; B; // oops, unconditional (e.g., "goto fail")

It also gives you a nice scope to keep local variables in, but there are other ways to accomplish that too.

Re: Evolution of the x86 context switch in Linux (2018)

#22

Post by bogomipz »

monocasa wrote: post #18
bogomipz wrote: post #17

Can someone say why is using the TSS still mandatory with software-based task switching? Is this a requirement imposed by x86? In looking at the OS dev wiki I see the following: >"The TSS is primarily suited for hardware multitasking, where each individual process has its own TSS. In Software multitasking, one or two TSS's are also generally used, as they allow for entering Ring 0 code after an interrupt." Would you…

The interrupt stack pointer comes from the TSS. Without that you're still running on the untrusted user stack with no way of bootstrapping a kernel context without corrupting the user state.

Oh right, without a mapping its a "chicken and egg" situation. Cheers.

Re: Evolution of the x86 context switch in Linux (2018)

#23

Post by bogomipz »

DSingularity wrote: post #16
bogomipz wrote: post #15

Earlier quoted context omitted.

Can you elaborate? How does relying on pure TSS for context switching prevent meltdown? What were the 4g4g kernels? Might you have any literature and/or on those?

Separate address space for kernel and user. Hardware will use TSS to switch address space as needed for syscalls.

Do you the reason why Linus rejected this idea?

Re: Evolution of the x86 context switch in Linux (2018)

#24

Post by amluto »

DSingularity wrote: post #16
bogomipz wrote: post #15

Earlier quoted context omitted.

Can you elaborate? How does relying on pure TSS for context switching prevent meltdown? What were the 4g4g kernels? Might you have any literature and/or on those?

Separate address space for kernel and user. Hardware will use TSS to switch address space as needed for syscalls.

Huh? Hardware TSS has nothing to do with separating address spaces. It’s just a trick for switching the address space, and it’s really quite slow on modern CPUs. In theory, a kernel could use hardware task switching to switch address spaces on user/kernel transitions by forcing a hardware task switch when this happens, but the performance impacts would be considerably worse than KPTI.

What does seem to mitigate Meltdown on some CPUs is enabling segment limits for user code. This does nothing for 64-bit code, though.

edit: not to mention that there are no hardware context switches on 64-bit kernels. AMD removed support entirely in 64-bit mode. The TSS still exists, but it’s just an awkward dumping ground for a couple of data structures.

Re: Evolution of the x86 context switch in Linux (2018)

#26

Post by souprock »

bogomipz wrote: post #23
DSingularity wrote: post #16

Earlier quoted context omitted.

Separate address space for kernel and user. Hardware will use TSS to switch address space as needed for syscalls.

Do you the reason why Linus rejected this idea?

The main reason seemed to be the relatively bad performance of the hardware task switch (loading segment registers and the page table base) that would be required for any system call.

Of course, that turns out to be the fix for meltdown, unless you have the process-context identifiers (PCID) available on Haswell chips and newer. The meltdown fix for older CPUs, such as the Pentium III and Intel Core, is roughly the same as the 4g4g kernel changes.

BTW, the 4g4g kernels were created for a different reason. The kernel needed more virtual address space for itself, and thus couldn't share with user code. This was for a time when people were trying to run 32-bit kernels on systems with 32 gigabytes of RAM.

Re: Evolution of the x86 context switch in Linux (2018)

#27

Post by ezconnect »

Groxx wrote: post #10
heinrichhartman wrote: post #5

I really like how good the article looks when printed. I enjoy reading long, in-depth articles much more when I can read them in print. Unfortunately many blog posts need a lot of tweaking until I can get an acceptable print result. This one looks good enough without any trickery. Thanks to the author, for caring about the paper people. : )

out of curiosity, since it changes how the page prints and I haven't experimented much: have you tried printing while in the browser's "reading" mode? Or does that tend to be worse?

Not OP,but if it looks good on "reading" mode it prints nicely. Plus you can adjust font size and print width to conform to your taste.

Re: Evolution of the x86 context switch in Linux (2018)

#28

Post by bogomipz »

souprock wrote: post #26
bogomipz wrote: post #23

Earlier quoted context omitted.

Do you the reason why Linus rejected this idea?

The main reason seemed to be the relatively bad performance of the hardware task switch (loading segment registers and the page table base) that would be required for any system call. Of course, that turns out to be the fix for meltdown, unless you have the process-context identifiers (PCID) available on Haswell chips and newer. The meltdown fix for older CPUs, such as the Pentium III and Intel Core, is roughly the s…

>"Of course, that turns out to be the fix for meltdown, unless you have the process-context identifiers (PCID) available on Haswell chips and newer."

Using TSS based switching is incompatible with PCIDs? Or is it incompatible with separate address spaces for user space and kernel space?

PCIDs are process ID tags on cache lines correct?

Re: Evolution of the x86 context switch in Linux (2018)

#29

Post by souprock »

bogomipz wrote: post #28
souprock wrote: post #26

Earlier quoted context omitted.

The main reason seemed to be the relatively bad performance of the hardware task switch (loading segment registers and the page table base) that would be required for any system call. Of course, that turns out to be the fix for meltdown, unless you have the process-context identifiers (PCID) available on Haswell chips and newer. The meltdown fix for older CPUs, such as the Pentium III and Intel Core, is roughly the s…

>"Of course, that turns out to be the fix for meltdown, unless you have the process-context identifiers (PCID) available on Haswell chips and newer." Using TSS based switching is incompatible with PCIDs? Or is it incompatible with separate address spaces for user space and kernel space? PCIDs are process ID tags on cache lines correct?

TSS switching is incompatible with running in 64-bit mode. It is very slow. Doing most of the same actions (reload segment registers and the page table base) in software is also very slow. Prior to the meltdown issue, Linux system calls had avoided most reloads of the segment registers and page table base.

PCIDs are incompatible with older hardware. They are modestly slow. I think the PCID state includes the TLB.

That pretty much means the kernel must support both methods. The PCIDs is used when possible. When the hardware doesn't support PCIDs, Linux must instead reload segment registers and the page table base, either step-by-step in software or via a TSS switch.

BTW, I had to implement x86 hardware task switching for an x86 emulator. The complexity is insane. See my "Who is Hiring?" post if that sounds fun for you.

Post reply on HN