On Dec 8, 12:15 pm, [email protected] wrote:
> I wrote a short design doc about handling dataresourcesand localized
> strings onlinux.
>
> http://sites.google.com/a/chromium.org/dev/developers/design-document...
>
> Feedback welcome.
>
> tony
Quoth the design doc:
> Other ideas
> Leave everything in code, but in .so files (dlls)
> Each data resource would become a .c file which we compile into a single .so.
> This is very similar to the current
> approach on Windows and would allow us to embed data resources into the main
> chrome.so. This might also be
> a bit faster to load because it doesn't have to parse the data file index.
> The only drawback to this approach is
> that it loads data as code. On Windows, you can load a dll with
> LoadLibraryEx(LOAD_AS_DATAFILE) which
> prevents code execution in the case of a corrupt file. I don't know of a way
> to do something similar on Linux.
The linux library model isn't particularly magical - some code in user
space (in ld-linux.so.2) simply open()s the file, grovels around in
headers, mmap()s bits of it, does some relocations, mprotect()s to
disable write access to the stuff it just relocated, and there it is.
As such, if the goal is to be able to load untrusted datafiles, it
would probably be best not to use a .so-file at all, but instead to
mmap in a much simpler format - thus probably loading faster than the
dynamic linker would. This approach is easily ported back to windows
as well, using MapViewOfFile and friends.
That said, there's no direct equivalent to LOAD_AS_DATAFILE in Linux,
since Linux doesn't have resources - and so it is very rare to use a
library for anything other than its exported functions, which are
likely to not work properly if the library's dependencies aren't
loaded, or its entry point not invoked.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
