LWN: Comments on "3.16 merge window, part 2"

3.16 merge window, part 2

eru — Sun, 29 Jun 2014 12:11:48 +0000

Thanks again, I will study that sample.

3.16 merge window, part 2

khim — Sat, 28 Jun 2014 12:43:35 +0000

LDT is unusable in 64bit mode, yes. This is hardware limitation. It's fully usable in 32bit process even on x86-64 system with 64bit kernel. For 32bit process there are examples (e.g. you could look on NaCl here).

3.16 merge window, part 2

eru — Sat, 28 Jun 2014 10:12:05 +0000

Thanks, khim. I guess I was too dense to include "ldt" in my queries. The manpage is not too informative, though. It does not say if I can extend the LDT with the call, and a quick test on my home x86_64 machine just returned 0 as the size, when reading the LDT (maybe this works only in 32-bit processes?). I would like to be able to allocate at least about ten LDT entries, in order to partially simulate a legacy system, where code, data and stack are all in different segments, and memory allocation calls return fresh segments with their own LDT entries.

Oh well, I probably have to read relevant bit of the kernel source for further investigations.

3.16 merge window, part 2

khim — Fri, 27 Jun 2014 16:27:32 +0000

What have you tried to find in Google? Request How to modify LDT in Linux returns the appropriate manpage as the first hit!

3.16 merge window, part 2

eru — Fri, 27 Jun 2014 10:14:12 +0000

16-bit stack segments will be allowed on 64-bit x86 kernels again. That feature was disabled due to a kernel information leak of the top 16 bits of the stack pointer that has now been fixed. Users will regain the ability to run 16-bit Windows programs in Wine on 64-bit kernels.

Didn't even know that was ever possible, but could be useful for my purposes. I wonder where I can find docs on how to allocate actual x86 16-bit segments, or for that matter 32-bit segments from user code? Manpages and googling turned up nothing.

3.16 merge window, part 2

rvfh — Fri, 13 Jun 2014 07:30:38 +0000

inode_owner_or_capable() was also modified to support the case where 'current [...] has CAP_FOWNER in a namespace with the inode owner uid mapped'.

3.16 merge window, part 2

luto — Thu, 12 Jun 2014 05:49:27 +0000

The capable_wrt_inode_uidgid change was the entire fix for CVE-2014-4014. No one as claimed the prize for figuring out the vulnerability yet :)