> Albert D. Cahalan <acahalan@cs.uml.edu> wrote:
> > There were plans to make mlock() available to normal users for
> > cryptographic purposes. There would be a quota to protect the
> > machine. If a user (or group of users) can get 1/32 of the pages
> > below 16 MB, then the system can not allocate 128 kB for DMA.
>
> You'll eventually want to allow memory locked with this variation of
> mlock to be migrated out of the DMA region (to deal with fragmentation
> issues).
>
> > In general, it is bad to leak information.
>
> But the question is: is the physical address information, or is
> protecting it security through obscurity?
Security-through-obscurity isn't the issue here, rather the leakage of
information from the kernel to a user-space task which isn't currently
being leaked, and the possibility of a covert channel.
The former isn't something I care much about one way or another, though
I'll certainly agree that the less information is leaked, the easier it'll
be on future implementors. (If the info isn't available, you can't break
anything by changing it.)
The latter is a completely different issue from everything else that is
being discussed, and has to do with high security installations, the
concept being that no task should be able to leak information to another
task through a channel that isn't monitored. I won't bother conjuring up
an example of using phys_addr in such a manner, as Linux has more then
enough non-covert channels to bother worrying about the covert ones. If
the system has a finite amount of processing power, dynamic scheduling,
and a real-time clock, it's not worth worrying about covert channels.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- 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