Posts Tagged ‘TCB

TCP/Process Communication

In order to send a message, a process sets up its text in a buffer region in its own address space,inserts the requisite control information (described in the following list) in a transmit control block (TCB) and passes control to the TCP. The exact form of a TCB is not specified here, but it might take the form of a passed pointer, a pseudo interrupt, or various other forms. To receive a message in its address space, a process sets up a receive buffer, inserts the requisite control information in a receive control block (RCB) and again passes control to the TCP.

Fig. 1. Conceptual TCB format.

In some simple systems, the buffer space may in fact be provided by the TCP. For simplicity we assume that a ring buffer is used by each process,but other structures (e.g., buffer chaining) are not ruled out. A possible format for the TCB is shown in Fig.1. The TCB contains information necessary to allow the TCP to extract and send the process data.Some of the information might be implicitly known,but we are not concerned with that level of detail.The various fields in the TCB are described as follows.

  1. Source Address: This is the full net/HOST/TCP/port address of the transmitter.
  2. Destination Address: This is the full net/HOST/TCP/port of the receiver.
  3. Next Packet Sequence Number: This is the sequence number to be used for the next packet the TCP will transmit from this port.
  4. Current Buffer Size: This is the present size of the process transmit buffer.
  5. Next Write Position: This is the address of the next position in the buffer at which the process can place new data for transmission.
  6. Next Read Position: This is the address at which the TCP should begin reading to build the next segment for output.
  7. End Read Position: This is the address at which the TCP should halt transmission. Initially 6 and 7 bound the message which the process wishes to transmit.
  8. Number of Re-transmissions/Maximum Re-transmissions: These fields enable the TCP to keep track of the number of times it has re-transmitted the data and could be omitted if the TCP is not to give up.
  9. Timeout/Flags: The timeout field specifies the delay after which unacknowledged data should be re-transmitted. The flag field is used for semaphores and other TCP/process synchronization status reporting, etc.
  10. Current Acknowledgment/Window: The current acknowledgment field identifies the first byte of data still unacknowledged by the destination TCP.

The read and write positions move circularly around the transmit buffer, with the write position always to the left (module the buffer size) of the read position. The next packet sequence number should be constrained to be less than or equal to the sum of the current acknowledgment and the window fields. In any event, the next sequence number should not exceed the sum of the current acknowledgment and half of the maximum possible sequence number (to avoid confusing the receiver’s duplicate detection algorithm). A possible buffer layout is shown in Fig.2.


Fig. 2. Transmit buffer layout.

The RCB is substantially the same, except that the end read field is replaced by a partial segment check-sum register which permits the receiving TCP to compute and remember partial check sums in the event that a segment arrives in several packets. When the final packet of the segment arrives, the TCP can verify the check sum and if successful, acknowledge the segment.

Tags : , , , , , , , , , , , , , , ,

Protecting Embedded-Systems Security

The key to preventing such disasters is to equip mobile devices with software that is secure by design. As the experience of the PC world shows, this is not easy — clearly, the standard of mobile device security must be much higher than what we areused to from the PC world. The problem is that the software driving mobile devices is becoming as complex as that of PCs, owing to the dramatic increase in functionality of such devices. Top-of-the line cell phones already run software that is composed of millions of lines of code (LOC), and top of-the-line cars contain in excess of a gigabyte of software.

Such large systems are impossible to make fault free. Experience shows that even well-engineered software averages at least one fault every few thousand lines of code (and well-engineered software is rare). This is made worse by the traditional approach to embedded-systems software, which tends to be built on top of a real-time executive without memory protection. In such a system every bug in any part of the system can cause a security violation.

In security terms, the part of a system that can circumvent security policies (and must therefore befully trusted) is called the trusted computing base (TCB). In a system without memory protection, the TCB is the complete system (of potentially millions of lines of code). Clearly, such a large TCB cannot be made trustworthy.

Tags : , , , , , , ,