From: Jens O. <je...@je...> - 2001-07-20 04:08:32
|
Linus Torvalds wrote: > Also, please be careful when adding things to the shared area, and ask > yourself a few things. Is it _really_ performance critical? Does it have > to be shared? > > Also, shared memory implementations tend to have _really_ subtle security > issues, and let's say that you use a shared memory area for passing in > data that ends up being used by something asynchronous like an interrupt > routine or directly by a DMA hardware engine or something. > > That's the perfect example of something where you as a software engineer > might think "Oh, let's just let the user put the data in the right format > in the first place, and we can just validate it and let the engine rip". > > Bzzt! Wrong answer. You cannot validate shared memory. Another thread may > be changing it maliciously at the same time, so you HAVE to copy it away > to a private area anyway while you're validating it. At which point the > whole point of using shared memory is completely lost, and your shared > memory optimization actually turns out to be a pessimization on many > architectures (shared memory has to have stricter cache consistency > guarantees on some architectures, so it can actually be slower to access > from a pure CPU hardware standpoint). > > So be very very careful about shared memory even if you ignore the > versioning problems. To a first-order approximation you should have the > rule that shared memory is used for > - locks > - mapping in "safe" memory (ie things like a frame buffer) directly into > the application. > > Putting things like drawing engine command lists in shared memory (I don't > know if DRI does) would count as a REALLY bad mistake from a security > standpoint. Can you say "Microsoft Windows" five times really quickly? > > And security is the _one_ place where performance simply doesn't matter. > If it's not secure, it doesn't matter _how_ fast it is, because it is not > working right. Linus, I agree with your analysis of the dangers of shared memory, or any memory where you turn a graphics hardware engine loose on user validated graphics data. Getting maximum performance while not sacrificing security has been a HIGH priority of the DRI development team. Much more development time has gone into this area than I've seen on any other graphics team over my career. However, the fact remains that most of our performance overhead for the current generation of PC graphics hardware is firmly divided into two major buckets: state management and data transfers. Working with hardware that can safely and efficiently handle unvalidated graphics data is the ideal. However, this ideal is usually ellusive. For a closed source vendor--no problem. They leave the security exploits because they know the chances of them being discovered are minimal (security thrue obscurity). However, the DRI team has never relied on this tactic. When security exploits are discovered with the graphics engine itself--we depend on minimizing the validation to cover only the exploit and leave as much of the data unvalidated as possible. That's when we can get into creative work arounds that only lose 10-20% of our performance instead of 50-70%. Shared memory has been a critical resource for these workarounds, and you will find that we have used it in some of our drivers for data we eventually pass to a graphics engine. However, we do feel we've covered the identified security exploit in those cases--I guess the real question is what unknown exploits have we created. Can we effectively minimize these exploits so that shared memory can still be used and allow us to create competitive drivers for graphics hardware where specs are still being given out for open source development? Regards, Jens -- /\ Jens Owen / \/\ _ je...@je... / \ \ \ Steamboat Springs, Colorado |