Chapter 15. Clocking

[ Team LiB ]

Chapter 15. Clocking The Previous Chapter The high speed signaling performed by HT devices is based on point-to-point differential signaling and source synchronous clocking. Details associated with link power requirements and the driver and receiver characteristics are discussed in this chapter. Also, the characteristics of the system-related signals, including RESET#, PWROK, LDTSTOP#, and LDTREQ# are discussed. This Chapter This chapter focuses on the source synchronous clocking environment within HT. This involves the use of the source synchronous transmit clock to load data into a receive FIFO and the transfer of data into the receiver time domain with a receive clock that unloads data from the FIFO. Additionally, the specification defines three clocking modes that require different levels of support for passing packets between these two clock domains. The Next Chapter The next chapter describes the configuration of devices which use the HyperTransport technology type 1 configuration header for bridges. Such devices include HyperTransport-to-HyperTransport bridges and bridges to other PCI compatible protocols (e.g. HyperTransport-to-PCI or PCI-X). In this chapter, the basic architecture of a HyperTransport-to-HyperTransport bridge is reviewed and the configuration header fields are described. Differences in usage of bit fields by HyperTransport bridge interfaces vs. PCI bridge interfaces are emphasized. The format of PCI compatible bridge headers is formally defined in the PCI-to-PCI Bridge Architecture Specification, Revision 1.1.

[ Team LiB ]

Section 12.1. Introduction

12.1. Introduction The embedded Linux examples demonstrate certain basic APIs for various operations. Additional APIs exist that offer other functionality. You should research the additional APIs on your own to determine whether there are other, better ways to perform the operations necessary for your particular embedded system. One aspect of Linux you need to be familiar with is its thread model. The Linux API conforms to the key POSIX standard in the space, POSIX 1003.1c, commonly called the pthreads standard. POSIX leaves many of the implementation details up to the operating system implementer. A good source of information on pthreads is the book Pthreads Programming, by Bradford Nichols, Dick Buttlar, and Jacqueline Farrell (O'Reilly). The version of embedded Linux used on the Arcom board is a standard kernel tree (version 2.6) with additional ARM and XScale support from the ARM Linux Project at http://www.arm.linux.org.uk. A plethora of books about Linux and embedded Linux are available. Some good resources include Understanding the Linux Kernel, by Daniel P. Bovet and Marco Cesati (O'Reilly), Linux Device Drivers, by Alessandro Rubini and Jonathan Corbet (O'Reilly), and Building Embedded Linux Systems, by Karim Yaghmour (O'Reilly). The instructions for configuring the embedded Linux build environment and building the example Linux applications are detailed in Appendix E. Additional information about using embedded Linux on the Arcom board can be found in the Arcom Embedded Linux Technical Manual and the VIPER-Lite Technical Manual. In order to keep the examples in this chapter shorter and easier to read, we don't check the return values from function calls. In general, it is a good idea to validate all return codes. This provides feedback about potential problems and allows you, as the developer, to make decisions in the software based on failed calls. Basically, it makes your code more robust and, hopefully, less buggy.

Example: Reading File Permissions

Example: Reading File Permissions Program 15-4 is the function ReadFilePermissions, which is used by Programs 15-1 and 15-2. This program methodically uses the preceding functions to extract the information. Its correct operation depends on the fact that the ACL was created by Program 15-3. The function is in the same source module as Program 15-3, so the definitions are not repeated. Program 15-4. ReadFilePermissions: Reading Security Attributes DWORD ReadFilePermissions (LPCTSTR lpFileName, LPTSTR UsrNm, LPTSTR GrpNm) /* Return the UNIX-style permissions for a file. */ { PSECURITY_DESCRIPTOR pSD = NULL; DWORD LenNeeded, PBits, iAce; BOOL DaclF, AclDefF, OwnerDefF, GroupDefF; BYTE DAcl [ACL_SIZE]; PACL pAcl = (PACL) &DAcl; ACL_SIZE_INFORMATION ASizeInfo; PACCESS_ALLOWED_ACE pAce; BYTE AType; HANDLE ProcHeap = GetProcessHeap (); PSID pOwnerSid, pGroupSid; TCHAR RefDomain [2] [DOM_SIZE]; DWORD RefDomCnt [] = {DOM_SIZE, DOM_SIZE}; DWORD AcctSize [] = {ACCT_NAME_SIZE, ACCT_NAME_SIZE}; SID_NAME_USE sNamUse [] = {SidTypeUser, SidTypeGroup}; /* Get the required size for the security descriptor. */ GetFileSecurity (lpFileName, OWNER_SECURITY_INFORMATION | GROUP_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION, pSD, 0, &LenNeeded); pSD = HeapAlloc (ProcHeap, HEAP_GENERATE_EXCEPTIONS, LenNeeded); GetFileSecurity (lpFileName, OWNER_SECURITY_INFORMATION | GROUP_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION, pSD, LenNeeded, &LenNeeded); GetSecurityDescriptorDacl (pSD, &DaclF, &pAcl, &AclDefF); GetAclInformation (pAcl, &ASizeInfo, sizeof (ACL_SIZE_INFORMATION), AclSizeInformation); PBits = 0; /* Compute the permissions from the ACL. */ for (iAce = 0; iAce < ASizeInfo.AceCount; iAce++) { GetAce (pAcl, iAce, &pAce); AType = pAce->Header.AceType; if (AType == ACCESS_ALLOWED_ACE_TYPE) PBits |= (0x1 << (8-iAce)); } /* Find the name of the owner and owning group. */ GetSecurityDescriptorOwner (pSD, &pOwnerSid, &OwnerDefF); GetSecurityDescriptorGroup (pSD, &pGroupSid, &GroupDefF); LookupAccountSid (NULL, pOwnerSid, UsrNm, &AcctSize [0], RefDomain [0], &RefDomCnt [0], &sNamUse [0]); LookupAccountSid (NULL, pGroupSid, GrpNm, &AcctSize [1], RefDomain [1], &RefDomCnt [1], &sNamUse [1]); return PBits; }

Chapter 12. Distributed Databases and Distributed Data

[ Team LiB ]

Chapter 12. Distributed Databases and Distributed Data Data in large and mid-sized companies frequently resides on multiple servers. The data might be distributed across various-sized servers running a mix of operating systems for a number of reasons, including scalability, performance, access, and management. As a result, the data needed to answer business questions may not reside on a single local server. The user may need to access data on several servers simultaneously, or the data required for an answer may need to be moved to a local server. Inserts, updates, or deletions of data on these distributed servers may also be necessary. There are two basic ways to deal with data in distributed databases: as part of a single distributed entity in which the distributed architecture is transparent, or by using a variety of replication techniques to create copies of the data in more than one location. This chapter will examine both of these options and the technologies associated with each solution. Several of the technologies described here can be used in combination with Oracle Application Server components to integrate data from several sources (for example, to facilitate document exchange). This combination of Oracle technology solutions is sometimes referred to as the Oracle Enterprise Integration framework. Grid computing introduces a new third solution to widely distributed data�a single database deployment model leveraging Oracle's Real Application Clusters and Application Server services. As might be expected, capabilities introduced earlier for distributed data play a part in this solution, particularly Oracle Streams, as described later in this chapter.

[ Team LiB ]

Praise for Exploiting Software

Prev don't be afraid of buying books Next

Praise for Exploiting Software "Exploiting Software highlights the most critical part of the software quality problem. As it turns out, software quality problems are a major contributing factor to computer security problems. Increasingly, companies large and small depend on software to run their businesses every day. The current approach to software quality and security taken by software companies, system integrators, and internal development organizations is like driving a car on a rainy day with worn-out tires and no air bags. In both cases, the odds are that something bad is going to happen, and there is no protection for the occupant/owner. This book will help the reader understand how to make software quality part of the design—a key change from where we are today!" —Tony Scott Chief Technology Officer, IS&S General Motors Corporation "It's about time someone wrote a book to teach the good guys what the bad guys already know. As the computer security industry matures, books like Exploiting Software have a critical role to play." —Bruce Schneier Chief Technology Officer Counterpane Author of Beyond Fear and Secrets and Lies "Exploiting Software cuts to the heart of the computer security problem, showing why broken software presents a clear and present danger. Getting past the 'worm of the day' phenomenon requires that someone other than the bad guys understands how software is attacked. This book is a wake-up call for computer security." —Elinor Mills Abreu Reuters' correspondent "Police investigators study how criminals think and act. Military strategists learn about the enemy's tactics, as well as their weapons and personnel capabilities. Similarly, information security professionals need to study their criminals and enemies, so we can tell the difference between popguns and weapons of mass destruction. This book is a significant advance in helping the 'white hats' understand how the 'black hats' operate. Through extensive examples and 'attack patterns,' this book helps the reader understand how attackers analyze software and use the results of the analysis to attack systems. Hoglund and McGraw explain not only how hackers attack servers, but also how malicious server operators can attack clients (and how each can protect themselves from the other). An excellent book for practicing security engineers, and an ideal book for an undergraduate class in software security." —Jeremy Epstein Director, Product Security & Performance webMethods, Inc. "A provocative and revealing book from two leading security experts and world class software exploiters, Exploiting Software enters the mind of the cleverest and wickedest crackers and shows you how they think. It illustrates general principles for breaking software, and provides you a whirlwind tour of techniques for finding and exploiting software vulnerabilities, along with detailed examples from real software exploits. Exploiting Software is essential reading for anyone responsible for placing software in a hostile environment—that is, everyone who writes or installs programs that run on the Internet." —Dave Evans, Ph.D. Associate Professor of Computer Science University of Virginia "The root cause for most of today's Internet hacker exploits and malicious software outbreaks are buggy software and faulty security software deployment. In Exploiting Software, Greg Hoglund and Gary McGraw help us in an interesting and provocative way to better defend ourselves against malicious hacker attacks on those software loopholes. The information in this book is an essential reference that needs to be understood, digested, and aggressively addressed by IT and information security professionals everywhere." —Ken Cutler, CISSP, CISA Vice President, Curriculum Development & Professional Services, MIS Training Institute "This book describes the threats to software in concrete, understandable, and frightening detail. It also discusses how to find these problems before the bad folks do. A valuable addition to every programmer's and security person's library!" —Matt Bishop, Ph.D. Professor of Computer Science University of California at Davis Author of Computer Security: Art and Science "Whether we slept through software engineering classes or paid attention, those of us who build things remain responsible for achieving meaningful and measurable vulnerability reductions. If you can't afford to stop all software manufacturing to teach your engineers how to build secure software from the ground up, you should at least increase awareness in your organization by demanding that they read Exploiting Software. This book clearly demonstrates what happens to broken software in the wild." —Ron Moritz, CISSP Senior Vice President, Chief Security Strategist Computer Associates "Exploiting Software is the most up-to-date technical treatment of software security I have seen. If you worry about software and application vulnerability, Exploiting Software is a must-read. This book gets at all the timely and important issues surrounding software security in a technical, but still highly readable and engaging, way. Hoglund and McGraw have done an excellent job of picking out the major ideas in software exploit and nicely organizing them to make sense of the software security jungle." —George Cybenko, Ph.D. Dorothy and Walter Gramm Professor of Engineering, Dartmouth Founding Editor-in-Chief, IEEE Security and Privacy "This is a seductive book. It starts with a simple story, telling about hacks and cracks. It draws you in with anecdotes, but builds from there. In a few chapters you find yourself deep in the intimate details of software security. It is the rare technical book that is a readable and enjoyable primer but has the substance to remain on your shelf as a reference. Wonderful stuff." —Craig Miller, Ph.D. Chief Technology Officer for North America Dimension Data "It's hard to protect yourself if you don't know what you're up against. This book has the details you need to know about how attackers find software holes and exploit them—details that will help you secure your own systems." —Ed Felten, Ph.D. Professor of Computer Science Princeton University

	Amazon

PBX Lease Returns

< Day Day Up >

PBX Lease Returns At the time of the implementation, 22 of the 55 Cisco Expansion Port Network (EPN) PBXs were leased, which meant that the IP Telephony implementation schedule was largely dictated by the PBX lease return dates. To keep the massive effort of returning the large quantity of leased equipment organized and on schedule, the team leader who was responsible for the retrofit cleanup effort entered all the Cisco PBX leases onto a spreadsheet and developed a Microsoft project plan to keep the returns on track. The initiative involved returning each leased PBX, along with its ancillary parts, throughout the San Jose campus. In 2003, the two main leased PBXs were removed and fully disconnected. Chapter 7, "Moving Forward: Continuing to Be Cisco's First and Best Customer," outlines that process in more detail. "Getting the equipment out of the buildings was the easy part," says Reid Bourdet, SPM IT project manager and team lead who was responsible for returning all the Cisco leased legacy PBX equipment. Like a lot of large enterprises, Cisco had taken each lease agreement and allocated that lease to various buildings. "Because of the sheer size of the deployment, we had to pull all of the equipment back together to rebuild the original lease, ensuring that it was all there, and matched the original equipment list before we returned it," Bourdet recalls. The other challenge was to ensure that when the PBX deinstallations were conducted, steps were taken to prevent creating alarms from the equipment that remained. Cisco developed a procedure that entailed removing the software, removing all the trunks�the lines coming into the PBX�and then removing the cabinet from the CPU. "You have to tell the CPU that the cabinets are no longer there. If you don't, the CPU is always looking for them and will alarm the system," Bourdet cautions. Each PBX hardware deinstallation took an average of one working day, whereas the software removal required an additional three to four hours. Staffing involved four technicians who were familiar with the PBX network and knowledgeable on trunking technology. An additional telecom administrator removed the phone sets from the software configuration. "It's really important that the individuals doing the actual deinstalls are qualified and familiar with this type of network," Bourdet said. "We were fortunate enough to have the necessary resources on staff. If we didn't, we would have outsourced that part of the initiative to PBX-certified individuals." Although the equipment disconnection and retrieval went smoothly for the team, they did experience a problem reconciling their equipment list with the vendor's. "We followed the lessor's instructions to the letter, but we still ended up with disagreements about the quantities of equipment that we returned," Bourdet says. The leasing company did not inventory the equipment when it arrived at the facility, instead turning it over to a secondary market vendor. "The secondary vendor then either miscounted it, or things got lost between here and there, because our records and their records did not match. If I had it to do over, I would have gone an additional step that included a box level inventory of the equipment, rather than a consolidated list," Bourdet adds. Results of PBX Lease Return Initiative STATUS: 99.9 percent of all leased equipment up for renewal was returned. More than U.S. $3.5 million dollars (market value) of equipment was returned, including 22 PBX EPNs and 10,000 phones. U.S. $128,888 per month was saved in leased equipment cost. All final leftover equipment was inventoried and identified for lab testing use or reselling opportunities. RESULTS: The San Jose campus is completely retrofitted and is now 100 percent IP Telephony-ready. Best Practices: PBX Lease Returns Enter all PBX lease renewal dates and associated equipment onto a spreadsheet for tracking purposes, and build a project plan that schedules the deinstallations and returns. Develop a process that prevents alarms when removing cabinets from the PBX. Ensure that only PBX-certified technicians are involved in the deinstallation. Carefully match the equipment list on the original lease agreement to the inventory being returned, create a box-level inventory list, and get a signed receiving list from the vendor.

< Day Day Up >

35.1 NEED FOR CTI

< Day Day Up >

---

35.1 NEED FOR CTI

CTI technology is finding applications in every business sector. Why? The following are the reasons:

• 
  

  Throughout the world, the use of telephones is very high. In most developed countries, the telephone density (number of telephones per 100 population) is anywhere between 50 and 90. In developing countries, it is lower—between 2 and 20, but still higher than the number of computers.

  
  


• 
  

  To access the information using a telephone is much easier than using PC, mostly because voice is the most convenient mode of communication, and operating a telephone is much easier than operating a PC.

  
  


• 
  

  With the advent of automation, much of information is available on computers—whether from banks, libraries, transport agencies, service organizations, and others—some of this information needs to be provided to users/customers.

  
  


• 
  

  Throughout the world, manpower costs are rising. If the monotonous work of distributing routine information can be automated, organizations can save money and use their human resources for more productive work.

  
  


• 
  

  CTI provides the platform for unifying the various messaging systems. It benefits the user because it provides a single device for accessing different messaging systems such as e-mail, voice mail, and databases.

  
  

For these reasons, CTI is emerging as one of the highest growth areas in IT. However, CTI is not a new technology; it is a combination of many existing technologies to provide innovative applications to users.

The purpose of computer telephony integration (CTI) is to access information stored in computers through telephones. CTI is gaining practical importance due to the high number of telephones and availability of large amounts of information in computers.

Note

CTI finds applications in every business sector—banking, education, transportation, service organizations, entertainment, and others.

< Day Day Up >

---

Chapter 6: Digital Encoding

In a digital communication system, the first step is to convert the information into a bit stream of ones and zeros. Then the bit stream has to be represented as an electrical signal. In this chapter, we will study the various representations of the bit stream as an electrical signal.

6.1 REQUIREMENTS FOR DIGITAL ENCODING

Once the information is converted into a bit stream of ones and zeros, the next step is to convert the bit stream into its electrical representation. The electrical signal representation has to be chosen carefully for the following reasons:

• 
  

  The electrical representation decides the bandwidth requirement.

  
  


• 
  

  The electrical representation helps in clocking— the beginning and ending of each bit.

  
  


• 
  

  Error detection can be built into the signal representation.

  
  


• 
  

  Noise immunity can be increased by a good electrical representation.

  
  


• 
  

  The complexity of the decoder can be decreased.

  
  

The bit stream is encoded into an equivalent electrical signal using digital encoding schemes. The encoding scheme should be chosen keeping in view the bandwidth requirement, clocking, error detection capability, noise immunity, and complexity of the decoder.

A variety of encoding schemes have been proposed that address all these issues. In all communication systems, the standards specify which encoding technique has to be used. In this chapter, we discuss the most widely used encoding schemes. We will refer to these encoding schemes throughout the book, and hence a good understanding of these is most important.