lkml.org 
[lkml]   [1998]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: getting rid of iopl(3) in XFree86


On Mon, 30 Mar 1998, Horst von Brand wrote:

> MOLNAR Ingo <mingo@chiara.csoma.elte.hu> said:
>
> The plan to get rid of iopl(3):
>
> 1) extend our current (limited) ioperm() range (ports 0-1024) to ports
> 0-65535. We couldnt do this so far, due to the outragous size of the IO
> bitmap (two pages per thread). Gabriel Paulbert has found a nice trick to
> get it done in a 'delayed' fashion. (his hack has inspired the clone()
> io-bitmap hack as well). The latest softswitch patches implement Gabriel's
> trick, i hope we can get them integrated into 2.3. [I'm also ready to
> pester XFree86 people witch patches if such a feature went into the kernel
> ;)]

You are too modest, Ingo :-). I just gave a few sketchy ideas on how it
might be done. And you implemented it with all the details I had probably
not though of, softening the rough edges...

OTOH, I would know the opinion of Linus about it. I remember he told once
that he did not like tricks playing with page tables. However modifying 2
PTE instead of copying 8 kbytes is obviously a huge win (in the case of
the softswitch patch).

>
> [...]
>
> > Using ioperm() instead of iopl(3) reduces the impact of X's hardware
> > priviledges _greatly_. Most cards would be 100% safe, and maybe some cards
> > need some theoretical and crazy and hardware-specific exploit. (one needs
> > to start a busmaster DMA request to overwrite kernel memory... almost
> > impossible to get this right as at the priviledge level where the exploit
> > might run we do not have knowledge about virtual->physical mappings, thus
> > there is no reliable way to DMA some exploit code into the kernel ... yes
> > the system can crash but thats just a mild D.O.S. attack, not a root
> > exploit).
>
> I wouldn't be so sure... the kernel is loaded into physical RAM by lilo (or
> whatever), so the physical layout should be more or less constant. And
> that's all you'd need. Or am I totally off base here?


I would agree with Horst. Especially since you can get the address
of a few critical structures quite easily (sidt and sgdt instructions
can be used at _any_ privilege level). The manage to put an entry in the
IDT or a call gate in the GDT pointing back to code in your
virtual address space. It will run at CPL 0 and size is no more a problem.
Needed DMA is 8 bytes long and the only variable you need to
know is the kernel virtual base address.

Won't work if idt and gdt are in kernel virtual memory. IDT is now
protected because of the FOOF bug AFAIR.

Gabriel.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.094 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site