On Fri, Jul 25, 2014 at 1:15 PM, Dave Jones <davej@xxxxxxxxxx> wrote: > On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote: > > > There is recent interest in having a way to turn generally-available > > kernel features off. Maybe we should add a good one so we can stop > > bikeshedding and avoid proliferating dumb interfaces. > > > > Things that might want to be turn-off-able include: > > - getrandom with GRND_RANDOM [from the getrandom threads] > > - Any lookup of a non-self pid [from the capsicum thread] > > - Any lookup of a pid outside the caller thread group [capsicum] > > - Various architectural things (personal wishlist), e.g.: > > - RDTSC and userspace HPET access > > - CPUID? > > - 32-bit GDT code segments [huge attack surface] > > - 64-bit GDT code segments [probably pointless] > > I'm not sure there's value in disabling cpuid dev interface, > when the instruction is unprivileged. I meant the CPUID instruction. Some CPUs have a setting that turns off the CPUID instruction for user code. In principle, all VMs can do this, too, if the hypervisor would be kind enough to help out. I only mentioned the x86 stuff here to make the point that there are quite a few possibilities along these lines. There's actually already a way to turn off RDTSC, but it's not currently very useful because it doesn't do the right thing for the vDSO. That could be fixed, but there's certainly no reason to make any of the other stuff here wait for that. > > > I would propose a new syscall for this: > > > > long restrict_userspace(int mode, int type, int value, int flags); > > do the restrictions happen system-wide like in say SELinux, > or only within the calling process, like seccomp ? > The calling process and children, like seccomp. --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
