From: Leif D. <lde...@re...> - 2002-05-25 20:45:05
|
On Sat, 25 May 2002, Jos=E9 Fonseca wrote: > On 2002.05.25 20:36 Frank C. Earl wrote: > > On Saturday 25 May 2002 11:48 am, Jos=E9 Fonseca wrote: > >=20 > > > So if you can't secure it in the end, your extra effort will be in > > vain. > >=20 > > I just thought of something to try to change the nature of the test c= ase > > problem. What happens if you have a second descriptor of commands th= at > > merely resets the DMA engine settings to what they should be for the > > third > > descriptor? I'd say it'd depend on what the chip was actually doing- > > what do you guys think? >=20 > You mean, setting the descriptor to the right value in between? >=20 > hmm... I doubt that it in the middle works because as Leif noticed, the= =20 > changes that we make to BM_GUI_TABLE only affect the descriptor that is= =20 > two entries ahead, so it would be too late... >=20 > ..but your idea in principal is quite ingenious! What if we just fill t= he=20 > last 8 bytes of each 4K block with that command to reset the value of=20 > BM_GUI_TABLE? So even if the client tries to mess things up, we would p= ut=20 > it right in the end. Of course that it would be a pain [to code for] to= =20 > reserve 8 bytes on the end of each 4k block, but it's doable [It would=20 > also be a pain to code the kernel unmap/verification routine] >=20 > This means that not only the client can't mess up the descriptor table,= =20 > but they can't tamper with BM_GUI_TABLE, so we can also still use it as= a=20 > progression meter [in both implementations]. This had crossed my mind too. The only problem is that there could still= =20 be a short period of time where BM_GUI_TABLE isn't accurate, so it still=20 leaves the problem of being able to trust the contents of BM_GUI_TABLE fo= r=20 buffer aging and adding descriptors to the ring. --=20 Leif Delgass=20 http://www.retinalburn.net |