On 6 Jul 2002, Eric W. Biederman wrote: > > On some BIOSes the SLAAC-II register set was mapped onto the same physical > > page as the IDE controller memory-mapped registers. A user program which > > mmap'ed the SLAAC-II registers would have direct access to the SLAAC-II > > register set AND the IDE register set. Misbehaving SLAAC-II programs could > > thus scribble random junk into the IDE register set with predictably bad > > results. Since on some controllers some bit-patterns mean "format the > > drive" this could be very bad. > > Agreed, a good thing to avoid. I would go farther and say this is a 50% > driver bug in that it allowed the memory to be mmapped when it didn't know > it was the only device on that page. This should be fairly easy to detect.
yes, but ... the whole point of this kind of card is to direct-map control registers in user space. There are lots of cards like this -- myrinet, quadrics, graphics, etc. If the BIOS sets things up in a non-page-aligned way, the driver still has to allow the mapping, or the card can not be used. I see three bugs: 1) hardware bug -- for cards which are intended to be user-mapped, the hardware should ALWAYS indicate a BAR size of >= 4096 bytes. But ... 2) BIOS bug. (1) doesn't help on architectures with big page sizes -- Alpha with 8192 byte pages, or other machines with 16384 or larger pages. How big should the minimum BAR be? it is clear, however, that 256 bytes is wrong. 3) driver bug. I fixed it this way. If drivers find that user-mapped BARs are not on unique pages they should relocate them. But this can be totally impossible in some circumstances. Summary: the BIOS should set up BAR registers in a VM-friendly way. Not all BIOSes do this. LinuxBIOS does, hurrah! ron
