Re: [PATCH] New phys_addr() syscall

Alexander Kjeldaas (astor@guardian.no)
Mon, 20 Jul 1998 14:09:05 +0200


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.

> > * 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.

astor

-- 
 Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
 http://www.guardian.no/

- 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