Date: Mon, 3 Dec 2018 15:30:35 +0100
From: Maxime Villard <m...@m00nbsd.net>
Message-ID: <03e1d0b4-d6b9-5f45-4770-ee6b161b8...@m00nbsd.net>
| It shouldn't be hard to open new sysctls that don't leak stuff.
You really should stop using biased terminology. Of course we don't
want the kernel to "leak stuff" - but the syscalls in question are not
doing that, they are providing useful information. There is a difference.
The other fixes you have been making recently, where there are leaks,
where the kernel is returning data in padding fields of structs, etc, should
certainly all be fixed. Those ones really are leaks.
The sysctls (and procfs/kernfs if they're relevant) are something entirely
different, they're doing what they were designed to do, and which is used,
probably in more ways than you'd think.
m...@eterna.com.au said:
| we still would have to audit the tools to ensure they do not expose these
| addresses directly (ie, printf), but only use them internally,
I disagree with that too - I want to be able to see (at least some of) those
values. That is, I want to see where in the kernel a particular file struct
or inode/proc/... (etc) is stored, so I can get at it easily with a debugger,
and look and see what is happening with it inside the kernel.
Obviously I could chase it down with the debugger using the same methods
that the sysctl uses (using all the kernel internal data structs) to find what
I am looking for, but as the kernel has already done all that work, and can
make it available, I want it to.
I also want to be able to disable KASLR (in all its aspects) completely.
I don't care what the default is, I know how to build my own kernels, and
I change the defaults for all kinds of things - that's fine. But I want all
of the kernel loaded at the VA's that the linker put things (all text and
data). Obviously dynamic data goes wherever there is space available
when it is allocated ... that's why we have the sysctls that will tell us
where a particular object is located.
I also don't care if you don't want any of this information, and I don't
care if you add (optional) mechanisms so that none of it works on your
systems. Just don't break mine in a way I cannot easily turn off.
kre
