Re: [PATCH] New phys_addr() syscall

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Tue, 21 Jul 1998 17:01:04 +1000

Alexander Kjeldaas writes:
> On Mon, Jul 20, 1998 at 08:46:59AM +1000, Richard Gooch wrote:
> > Alexander Kjeldaas writes:
> >
> > > I don't think it's easy to analyze the risks so I'm a bit cautious.
> > > Some of the following _could_ be risks:
> > >
> > > * Hijacking DMA-able memory.
> > > * Hijacking memory with "good" alignments.
> >
> > You can only "hijack" if you manage to get pages unfairly. This patch
> > doesn't provide page-selection privileges or any other memory-related
> > privileges.
> > Look at it this way: any ordinary process can "hijack" memory by
> > calling malloc(3)!
>
> The difference is that when you know the physical address, you can't
> assume that the physical addresses used by a process' pages are random
> anymore. It can allocate memory, check the physical address, and if it
> doesn't fit an exploit pattern, give it back. So you can basically say
> that a process is free to pick whatever physical pages it wants to
> have. So if a process is only allowed to allocate 20MB of memory, you
> can assume that it will be able to allocate most of this below the
> 16MB border if it tries hard enough. You don't need to assume that
> without this system call. Maybe it is a problem, maybe not. If for
> example the memory subsystem could simply move away pages that were
> 'in the way' without going through swap, this would not be a problem.

First we need to step back and ask just what kind of attack are we
protecting against? Then ask if said attack can also proceed without
knowning virtual->physical translations?

In your example above, I could just allocate lots of pages and touch
them frequently, with a reasonable chance that I'll grab all pages
under 16 MB. If I know the translations I can be "nicer" about it by
returning (not touching) pages I don't care about. Hey! A considerate
denial of service attack!

> > > * Hashtables based on physical addresses can be exploited.
> >
> > Exploit what?
>
> If you can pick your pages, you can exploit hashtables that rely on
> random page-addresses. I can't point to any such hashtables, maybe
> there are none, but then I don't know the memory subsystem too
> well. Hopefully, the process will only be able to hurt itself.
>
> > > * Getting the amount of memory in the machine regardless of the
> > > setrlimits of the process.
> >
> > This patch doesn't give any privileges. I can't allocate more memory
> > with it, no matter what.
>
> If you can check the physical address of a page, you should be able to
> figure out how much memory the system has. Maybe it is ok that that
> information is available to all processes, maybe not.

% cat /proc/meminfo

Oh no! It tells me how much RAM the system has! Even worse, it tells
me what's used and where!
So shall we lock up /proc/meminfo too?

If someone shows me an exploit for virt->phys translations, I'll code
in access restrictions. Until then...

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html