Messages in this thread | | | Date | Tue, 21 Jul 1998 17:01:04 +1000 | From | Richard Gooch <> | Subject | Re: [PATCH] New phys_addr() syscall |
| |
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
| |