Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 70
Текст из файла (страница 70)
This is becausethe session handle is shared, along with the file handle, which meansthat any other files opened by the owning process in that session may beaccessible to the receiving process, which could then increment the filehandle numbers and gain access to other files. Not conforming to thisrule is a security hole.For more information on shared file handles, please refer to Chapter 9,The File Server.8.5 SummaryIn this chapter, I have introduced you to the key concepts in the Symbian OS implementation of platform security. Although I have not fullyexplored the subject, I hope that I have demonstrated how the kernel,loader and file server have been designed to play their part in makingSymbian OS a secure platform. I have shown that this support is provided independently of cryptographic and authentication mechanisms toreduce the impact on the performance of the system and dependencyupon those mechanisms:• Capabilities are used to associate permissions to a program independent of the origin of the programSUMMARY331• Capabilities are used to prevent a program from loading a library thatcould compromise it.Finally, I have discussed the file server and its role in data caging.I have shown that data caging provides safe storage for binaries andsensitive data, thus keeping them out of the reach of badly written ormalicious code.In the next chapter, I will explain the operation of the file server.9The File Serverby Peter ScobieRAM disk is not an installation procedure.UnknownThe file server component, also referred to as F32, manages every filedevice on a Symbian OS phone; it provides services to access the files,directories and drives on those file devices.
This component also containsthe loader, which loads executable files (DLLs and EXEs). The loader iscovered in Chapter 10, The Loader, and in this chapter I will concentrateon the file server.9.1 Overview9.1.1 Hardware and terminology9.1.1.1 Internal drive hardwareWe always designate the main ROM drive as ‘‘Z:’’ on a Symbian OSmobile phone. This drive holds system executables and data files and itscontents (known as the ROM image) are created by the mobile phonemanufacturer when building the device.
In fact, the ROM image is normally programmed into Flash memory – Flash is nonvolatile memory thatcan be programmed and erased electronically. The use of programmablememory for this read-only drive allows the manufacturer to replace orupgrade the ROM image after initial manufacture. In the past, SymbianOS products sometimes used masked ROM to hold the ROM image (orpart of it) but this is rarely done now. It takes time to fabricate a maskedROM device with the image and once this has taken place, it is notpossible to upgrade the software.A Symbian OS phone will also have at least one internal drive whichprovides read/write access, and which the OS uses for the permanentstorage of user data. Again, mobile phone manufactures tend to use334THE FILE SERVERFlash memory for this internal drive.
Indeed, in certain circumstances, thesame memory device can be used for both code and user data storage.Flash memory is made using either NAND or NOR gates – each havingsignificantly different characteristics. Symbian OS supports the storage ofcode and user data on both NAND and NOR Flash.Some early Symbian OS products used a RAM disk as the mainuser data storage device. RAM disks use the same memory as systemRAM.
Rather than being of fixed size, the system allocates memory tothem from the system pool as files are created or extended. Likewise, itfrees the memory as data is deleted from the drive. But RAM is volatilestorage – data is lost when power is removed. To provide permanentstorage, the device has to constantly power the RAM, even when thedevice is turned off, and it must supply a backup battery to maintainthe data, should the main supply fail.
Flash memory, on the other hand,retains its contents when power is removed and is also low power andlow cost. Because of this, Flash has replaced RAM for permanent userdata storage.Mobile phones do occasionally still make use of a RAM disk, however.If the file server finds that the main user-data drive is corrupt whenSymbian OS boots, then it can replace this with a RAM disk, providing atemporary work disk to the OS and allowing the main one to be restored.It can then mount the corrupt disk as a secondary drive, which allows adisk utility to recover data, where possible, and then reformat the drive.9.1.1.2 Removable media devicesMany Symbian OS phones support removable media devices such asMultiMediaCard (MMC), Secure Digital card (SD card), Memory Stickor Compact Flash (CF). The file server allocates each removable mediasocket one or more drives, allowing read/write access while a memorycard is present.
Being removable, these devices have to be formatted ina manner that is compatible with other operating systems. The devicesI have mentioned are all solid state rather than rotating media storagedevices, but miniature rotating media devices are likely to be used morewidely in future, due to their low cost and high capacity. Rotating mediadevices require more complex power management because of the highercurrent they consume and their relatively slow disk spinup times.I will discuss Symbian OS support for MultiMediaCards in Section 13.5.9.1.1.3 File server terminologyMany types of media device, such as MultiMediaCards and SD cards,require every access to be in multiples of a particular sector size, usually512 bytes.
Thus, the sector is the smallest unit that can be accessed.Other types of media device, such as the ROM, don’t have this constraintand allow access in any multiple of a byte.OVERVIEW335Throughout this chapter, I will often refer to a media device as adisk. The memory on a disk may be divided into isolated sections,called partitions. Information on the size and location of each partitionis generally stored at a known point on the disk – the partition table.For example, most MultiMediaCards keep a partition table in the firstsector of the disk. Even when a device has only a single partition, it willstill generally have a partition table. Each separate partition that is madeavailable on a Symbian OS mobile phone is enabled as a different drive.Drives that are allocated to removable media, may, over time, containdifferent volumes, as the user inserts and removes different removablemedia devices.
So a volume corresponds to a partition on a disk that hasbeen introduced into the system at some time.9.1.2 F32 system architecture overviewThe entire file server system consists of the (shaded) components displayedin Figure 9.1.The file server, like any other server in Symbian OS, uses theclient/server framework. It receives and processes file-related requestsfrom multiple clients. The file server runs in its own process and usesmultiple threads to handle the requests from clients efficiently.
Clientslink to the F32 client-side library (EFSRV.DLL), whose API I will describein Section 9.2. The file server executable, EFILE.EXE, contains twoservers – the file server itself (which I will describe in detail in Section 9.3)and the loader server, which loads executables and libraries. I will coverthis in Chapter 10, The Loader.Because of the differing characteristics of the various types of disk thatSymbian OS supports, we need a number of different media formats. Forexample, removable disks are FAT formatted to be compatible with otheroperating systems, and the ROM drive uses a format scheme which isefficient for read operation, but which wouldn’t be suitable if writes to thedrive were required.
In general, the file server does not concern itself withthe detail of each file system; instead we implement the different mediaformats as separate file systems, components that are ‘‘plugged into’’ thefile server. (The exception to this is the ROM file system, which is built intothe file server, for reasons that I will discuss in Section 9.1.2.3.) File systemcomponents are polymorphic DLLs that have the file extension ‘‘.FSY’’.These DLLs are dynamically loaded and registered with the file server,normally at system boot time. Figure 9.1 shows a file server configurationwith two file systems loaded, ELOCAL.FSY and ELFFS.FSY.
I willdescribe these and other file systems in Section 9.4.Before a particular drive can be accessed, it must have a file systemassociated with it, whereupon it can be said that the drive is mounted.Again, the file server generally carries out this process at system boot time,once the file systems have been loaded. Mounting also involves determining the basic parameters associated with the drive (drive capacity,336THE FILE SERVERFile serverclient 1File serverclient 2File serverclient 3File serverclient-side library(EFSRV.DLL)LoaderFile serverplug-in(VSCAN.PXT)File serverROM FS(EFILE.EXE)File systemFile system(ELOCAL.FSY)(ELFFS.FSY)File serverextension(NANDFTL.FXT)User-library(EUSER.DLL)TBusLocalDriveTBusLocalDriveuserkernelLocal media sub-systemFigure 9.1F32 system architecturefree space and so on) and initializing the drive specific data held by thefile server.
A loaded file system may be mounted on more than one drive.The file systems gain access to the mobile phone’s internal andremovable disks via a set of device drivers known as the local mediasub-system. These drivers are split into a logical device driver layer – thelocal media LDD (ELOCD.LDD) and a physical device driver layer.
Thephysical device drivers are called media drivers. The user-side interface tothe local media sub-system is provided by the class TBusLocalDrivewhose methods are exported from the user library (EUSER.DLL). Themain functions it provides are those to read, write and format regions ofOVERVIEW337each drive’s memory area. I describe the local media sub-system in detailin Section 13.3.Again, the ROM drive is an exception, as we do not access it throughthe local media sub-system. Instead, the bootstrap maps this memory areato be user-readable, and the file-server accesses it directly.For other drives though, the TBusLocalDrive class provides the userside interface to the physical media. Often, when a file system is mountedon a particular drive, it will interface directly with the TBusLocalDriveinstance for that drive.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
