On Fri, Jul 25, 2014 at 4:43 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 07/25/2014 11:30 AM, Andy Lutomirski wrote: >> - 32-bit GDT code segments [huge attack surface] >> - 64-bit GDT code segments [probably pointless] > > I presume you mean s/GDT/LDT/. > > We already don't allow 64-bit LDT code segments. Also, it is unclear to > me how 32-bit LDT segments have a huge attack surface, given that there > will realistically always be a 32-bit *GDT* segment present. I really did mean GDT :) Setting the 32-bit code segment to "not present" (and using seccomp to block modify_ldt) prevents any attempt to exploit bugs in the sysenter and cstar code. It also might prevent exploiting CPU bugs, although I've never heard of a relevant CPU bug in this area. If I actually tried to implement this (which wouldn't be part of the initial implementation), I'd split out the unusual things in __switch_to and friends to a slow path that's only used if weird settings are present (e.g. this, TSC restrictions, etc). But twiddling the present bit on a GDT entry is very fast, I assume -- it's just memory, and I don't think that any flush is needed. Also, if I implement this, I will curse Xen. I might even go so far as to disable the feature entirely if there's a paravirt GDT. Hmm. A separate flag to turn int $0x80 into GPF could have some value, too. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
