yes, but at the same time you would limit processes to a comparably small address space. I fear we already got too used to the vast space of 48bit virtual addresses.
-
-
Replying to @lavados
Sure. Is x32 as currently implemented in the Linux kernel safe from Meltdown or are minor changes needed (propose them on LKML if so)?
1 reply 0 retweets 0 likes -
x32 isn't architecturally different from x64-64 AFAIK? just a different syscall convention?
1 reply 0 retweets 1 like -
and differences in what you can do with segments. and if you're not using a long mode segment you can't use long mode operations -> you can't have pointers that point anywhere above 2^32.
1 reply 0 retweets 0 likes -
but the point of x32 is that you do have 64-bit mode, so that you can use R8-R15 and other features of 64-bit mode. x32 uses 32-bit pointers in its calling convention, but it's not architecturally compatibility mode
1 reply 0 retweets 2 likes -
Sure. I really do mean x32 here. With Meltdown, it just became more attractive: I guess just restrict modify_ldt() from x32 personality processes and we've defeated Meltdown for them, without KPTI. And those can co-exist with slower x86_64 processes with KPTI for full 64-bitness.
1 reply 0 retweets 1 like -
how would that work? x32 is architecturally still x86_64, and AFAIK the CPU will silently ignore any segment limits you try to set on e.g. CS or DS in that mode
1 reply 1 retweet 2 likes -
you would have to go for compatibility mode
2 replies 0 retweets 2 likes -
and use a second GDT, or something like that, because on normal Linux, any 32-bit process can just IRET to 64-bit mode - there is a 64-bit user code segment in the GDT, and ring 3 can switch to any ring 3 code segment
1 reply 0 retweets 0 likes -
Good point. Reminds me of my use of ring 2 for running userspace code with exec stack on Linux 2.0, so that ring 3 code wouldn't easily switch to there. But I'm not exactly happy about introducing this hack for 64-bit mode userspace code just so that 32-bit can't switch to there.
1 reply 0 retweets 0 likes
btw: Xen PV has something similar - if a 32-bit PV guest could switch to 64-bit mode, there'd be security issues, so they switch the GDT on context switch between VMs
-
-
Would an OS kernel do better by keeping 64-bit descriptors in LDT instead? IIRC, at the time of my Linux 2.0 hack, FreeBSD kept user code/data descriptors in LDT, and I was envious. Perhaps lower overhead than switching the GDT and less of a hack than running user code in ring 2.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.