lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 25 Jul 2014 13:21:31 -0700
From:	Andy Lutomirski <>
To:	Dave Jones <>,
	Andy Lutomirski <>,
	"Eric W. Biederman" <>,
	Julien Tinnes <>,
	David Drysdale <>,
	Al Viro <>,
	Paolo Bonzini <>,
	LSM List <>,
	Greg Kroah-Hartman <>,
	Paul Moore <>,
	James Morris <>,
	Linux API <>,
	Meredydd Luff <>,
	Christoph Hellwig <>,
	"" <>,
	Kees Cook <>,
	"Theodore Ts'o" <>,
	Henrique de Moraes Holschuh <>,
Subject: Re: General flags to turn things off (getrandom, pid lookup, etc)

On Fri, Jul 25, 2014 at 1:15 PM, Dave Jones <> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists