2012. 3. 26. 23:21

AMBA AXI PROTOCOL v1.0 - ARCHITECTURE OVERVIEW II

 



The AXI protocol provides a single interface definition for describing interfaces:
• between a master and the interconnect
• between a slave and the interconnect
• between a master and a slave.


The interface definition enables a variety of different interconnect implementations.
The interconnect between devices is equivalent to another device with symmetrical
master and slave ports to which real master and slave devices can be connected.
Most systems use one of three interconnect approaches:
• shared address and data buses
• shared address buses and multiple data buses
• multilayer, with multiple address and data buses.


In most systems, the address channel bandwidth requirement is significantly less than
the data channel bandwidth requirement. Such systems can achieve a good balance
between system performance and interconnect complexity by using a shared address
bus with multiple data buses to enable parallel data transfers.

위의 인터페이스와 인터커넥트 설명을 보면 마스터와 슬레이브라는 용어가 나오는데, 쉽게 얘기해서 마
스터는 AXI 아비터에게 버스 사용의 권한을 획득하여 R/W 작업을 위해 컨트롤 시그널, 어드레스 그리고 데이터를 슬레이브에게 전달하여 슬레이브와 통신이 가능하도록 해주는 디바이스(ex : CPU, DMA 등)를 의미하고 슬레이브는 마스터에게 받은 컨트롤 시그널, 어드레스와 데이터로 슬레이브 영역에서 처리하도록 해주는 디바이스(ex : SRAM, BUFFER, FIFO 등)를 의미합니다. 인터커넥트는 하나 이상의 마스터와 슬레이브가 통신이 가능하도록 메모리 맵핑된 IP로 정의할 수 있습니다. 인터커넥트도 하나의 IP기 때문에 추상적인 개념이 아니라 논리 회로 블럭을 의미합니다.

레지스터 슬라이스(Register slices)
Each AXI channel transfers information in only one direction, and there is no
requirement for a fixed relationship between the various channels. This is important
because it enables the insertion of a register slice in any channel, at the cost of an
additional cycle of latency. This makes possible a trade-off between cycles of latency
and maximum frequency of operation.
It is also possible to use register slices at almost any point within a given interconnect.
It can be advantageous to use a direct, fast connection between a processor and
high-performance memory, but to use simple register slices to isolate a longer path to
less performance-critical peripherals.

레지스터 슬라이스라는 개념을 설명하기 앞서 아래의 그림을 먼저 살펴 보겠습니다.


위의 그림을 보면 왼쪽에는 여러 개의 마스터가 있고 오른쪽에는 여러 개의 슬레이브가 있으며 인터커넥트에 연결되어 있습니다. 녹색 네모가 바로 레지스터 슬라이스로 보시면 됩니다. 레지스터 슬라이스가 필요한 이유가 무엇일까요? 위와 같이 여러 개의 마스터와 슬레이브가 하나의 버스를 공유하는 구조에서는 인터커넥트가 마스터의 작업 처리에 대한 Bottleneck이 발생할 수 밖에 없습니다. 그러니까 마스터 하나가 어드레스 시그널을 슬레이브로 전달한다고 했을 때, 이를 디코딩하기 위한 작업이 슬레이브가 많을 수록 현저히 떨어지는데 결국, 인터커넥트에서 마스터의 어드레싱을 처리하는 응답 속도가 떨어진다는 의미가 되겠지요. 따라서 마스터와 인터커넥트 혹은 슬레이브와 인터커넥트 버스 중간에 레지스터 슬라이스 (비트를 저장할 수 있는 플립플롭으로 보시면 됩니다)를 두어, 인터커넥트까지 거치지 않고 레지스터 슬라이스에서 바로 특정 시그널에 대한 응답을 할 수 있습니다. 이 결과로 Frequency가 높아지겠지만 반대로 Interconnect Path가 많아지게 됨으로써 Latency 지연이 증가하게 되겠지요. 즉, 레지스터 슬라이스를 패스 중간에 얼만큼 설치하느냐에 따라 Frequency와 Latency 간의 TRADE OFF가 있습니다. 하지만, 여기서 Latency가 상쇄될 수 있는 요인이 있는데, 최초에 비어 있는 레지스터 슬라이스 개수만큼 채울 때, Latency가 길어지지만 모두 채운 이후의 흐름에서는 오히려 더 높은 Frequency(짧은 패스)로 캐쉬 작업이 가능하기 때문입니다. 쉽게 얘기해서 레지스터 슬레이스를 설치한 패스 자체를 하나의 파이프 라인 스킴으로 보시면 이해가 쉬울 겁니다. 그리고 마스터와 슬레이브 간의 버스 패스가 너무 길어 특정 사이클 이내로 응답이 불가능한 경우는 레지스터 슬라이스를 설치해야 한다고 하네요.

(위의 그림에서 혼돈을 줄 수 있는 부분이 있습니다만, 여러 개의 마스터와 인터커넥트, 그리고 여러 개의 슬레이브와 인터커넥트가 단선으로 연결되어 오직 하나의 패스에 레지스터 슬라이스가 설치된 것처럼 보이지만, 실제 구조에서는 각 IP마다 따로 인터커넥트가 연결되어 있고 각각의 IP에 레지스터 슬라이스를 설치할 수 있는 구조로 보시면 됩니다.)

오늘은 간단히 여기까지만 정리하고 다음 시간에 타이밍 다이어그램에서 READ와 WRITE BURST의
동작을 살펴보도록 하겠습니다. (아래에 AMBA AXI SPEC 첨부하였으니 참고하세요)


Written by Simhyeon, Choe


AMBAaxi[1].pdf


ug761_axi_reference_guide.pdf







2012. 3. 23. 00:02

AMBA AXI PROTOCOL v1.0 - ARCHITECTURE OVERVIEW I


AMBA AXI 프로토콜에 대해서 공부해 봅시다. (AMBA AXI Protocol spec v1.0 참조)

1.1 About the AXI protocol

AMBA AXI 프로토콜의 핵심 특징은 다음과 같습니다.

• separate address/control and data phases
• support for unaligned data transfers using byte strobes
• burst-based transactions with only start address issued
• separate read and write data channels to enable low-cost Direct Memory Access(DMA)
• ability to issue multiple outstanding addresses
• out-of-order transaction completion
• easy addition of register stages to provide timing closure.

위의 특징 중에서 AHB와 비교해 진보한 부분을 살펴보면 READ DATA와 WRITE DATA CHANNEL이
나누어져 있는데요. 일반적으로 AHB의 BUS는 같은 시간에 READ/WRITE가 불가능하지만 AXI의
CHANNEL(BUS)은 같은 시간에 READ와 WRITE를 할 수 있습니다. 따라서 THROUGHPUT이 증가하
겠지요. 또 하나의 특징은 MULTIPLE OUTSTANDING ADDRESS로 ISSUING이 가능합니다. AHB의
경우에는 하나의 BURST TRANSACTION이 완료한 후에 다음 BURST TRANSACTION을 위한
ADDRESS를 ISSUING할 수 있지만, AXI에서는 먼저 처리중인 BURST TRANSACTION이 완료될 때
까지 기다리지 않고 TRANSACTION의 ADDRESS를 ISSUING할 수 있습니다. MULTIPLE
OUTSTANDING ADDRESS의 ISSUING이 가능함으로써 OUT-OF-ORDER TRANSACTION의 구현을
할 수 있습니다.

Out-of-order transactions can improve system performance in two ways:

• The interconnect can enable transactions with fast-responding slaves to complete
  in advance of earlier transactions with slower slaves.

• Complex slaves can return read data out of order. For example, a data item for a
  later access might be available from an internal buffer before the data for an
  earlier access is available.

위에서 언급한 것처럼 MASTER는 ADDRESS ISSUING 순서에 상관없이 보다 빠른 SLAVE로부터
트랜잭션을 완료할 수 있고 나중에 읽은 데이터를 먼저 처리할 수도 있습니다.


1.2 Architecture

AXI 프로토콜은 BURST를 기반으로 하고 있고, 모든 트랜잭션은 어드레스 채널에서 전송하는 어드레스
와 컨트롤 정보 가지고 있습니다. 데이터 전송은 마스터와 슬레이브 간의 WRITE DATA CHANNEL을
통해서 슬레이브로, 그리고 READ DATA CHANNEL을 통해서 마스터로 각각 이루어 집니다. WRITE
TRANSACTION에서는 모든 데이터는 마스터에서 슬레이브로 전송이 이루어지고 WRITE
TRANSACTION이 완료되면 슬레이브는 마스터로 WRITE RESPONSE CHANNEL을 통해 완료 시그널
을 전송함으로써 TRANSACTION을 완료하게 됩니다.

각각의 독립적인 채널은 INFORMATION SIGNAL 세트로 이루어져 있고 TWO-WAY VALID와 READY 핸드쉐이크 메커니즘을 사용합니다. 시그널 몇 가지를 간단하게 설명드리면 VALID는 채널상에서 유효
한 DATA와 CONTROL INFORMATION이 사용 가능한지에 대한 여부(가능하다면 엣지가 HIGH 상태가 됨) READY는 데이터를 수락 가능한지에 대한 여부를 나타내는 시그널입니다. 그리고 READ DATA
CHANNEL과 WRITE DATA CHANNEL은 둘 다 LAST 시그널을 가지고 있습니다만, 이것은 트랜잭션
에서 마지막 데이터 아이템의 전송을 의미할 때 HIGH로 ISSUING합니다.


READ ADDRESS CHANNEL AND WRITE ADDRESS CHANNEL

READ와 WRITE TRANSACTION은 각각의 ADDRESS CHANNEL을 사용하는데, 트랜잭션을 위해 ADDRESS와 CONTROL INFORMATION을 ADDRESS CHANNEL을 통해서 전송합니다.

The AXI protocol supports the following mechanisms:
• variable-length bursts, from 1 to 16 data transfers per burst
• bursts with a transfer size of 8-1024 bits
• wrapping, incrementing, and non-incrementing bursts
• atomic operations, using exclusive or locked accesses
• system-level caching and buffering control



1) Read data channel
   The read data channel conveys both the read data and any read response information
   from the slave back to the master. The read data channel includes:
   • the data bus, which can be 8, 16, 32, 64, 128, 256, 512, or 1024 bits wide
   • a read response indicating the completion status of the read transaction.

2) Write data channel
   The write data channel conveys the write data from the master to the slave and includes:
   • the data bus, which can be 8, 16, 32, 64, 128, 256, 512, or 1024 bits wide
   • one byte lane strobe for every eight data bits, indicating which bytes of the data
     bus are valid.
   Write data channel information is always treated as buffered, so that the master can
   perform write transactions without slave acknowledgement of previous write transactions.

3) Write response channel
   The write response channel provides a way for the slave to respond to write transactions.
   All write transactions use completion signaling.
   The completion signal occurs once for each burst, not for each individual data transfer
   within the burst.

Written by Simhyeon, Choe
 

2010. 6. 30. 02:18

N모사 카페 채팅 해킹하기

또다시 오랜만에 포스팅을 하는군요. 하하. 한동안 이것저것 하느라 바빴습니다만.. 이번에는 좀

색다른 시도를 해봤습니다. 제목에서도 알 수 있드시 바로 N모사 카페 채팅을 해킹하기입니다. 후후..

사실 해킹같은 건 별로 경험도 없을 뿐더러 그다지 관심 분야도 아니었습니다만..

최근 들어서 이쪽 분야에 관심이 가기 시작하더군요. 저의 왕성한 호기심을 충분히 그리고 촉촉히

자극하기 시작하였지요. : )

해킹 대상을 물색하던 와중에 떠오르던 것이 제가 가끔씩 애용하는 만화책 카페 채팅방이었습니다.

채팅방을 해킹한다면 왠지 제법 많은 것들을 얻을 것 같다는 생각이 뇌리에 스치더군요.

예를 들어, 카페 로그인없이 채팅 내용을 도청하고 방장 기능을 획득한다거나 아이디 도용 등의

작업들 말입니다. 그동안 나름대로 쌓아왔던 내공과 짬밥을 적절히 활용했습니다.

대략적으로 제가 어떤 작업을 해야할지 감이 오더군요.

카페 채팅 해킹의 핵심은 패킷 스니핑으로 분석하여 암호화된 패킷을 복호화하고 CONNECT와

DISCONNECT에서 발생하는 핸드쉐이킹 인증 작업을 체크하는 것입니다.


1) 접속할 때 이루어지는 핸드쉐이킹 인증 구조 분석(Wire Shark)



2) 암호화된 패킷의 분석



3) 캡쳐한 패킷 내용



Frame 309 (128 bytes on wire, 128 bytes captured)
Ethernet II, Src: AsrockIn_1d:fa:85 (00:65:00:1d:00:85), Dst: Dasan_0b:2e:94 (00:00:cb:00:2e:00)
    Destination: Dasan_0b:2e:94 (00:10:2b:0b:23:94)
    Source: AsrockIn_1d:fa:85 (00:25:00:00:fa:00)
    Type: IP (0x0800)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 202.179.0.0 (202.179.0.0)
Transmission Control Protocol, Src Port: device2 (2030), Dst Port: 11900 (11900), Seq: 1, Ack: 1, Len: 74
    Source port: device2 (2030)
    Destination port: 11900 (11900)
    [Stream index: 21]
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 75    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 65535
    Checksum: 0x0e45 [validation disabled]
    [SEQ/ACK analysis]
Data (74 bytes)

0000  55 53 45 52 30 30 36 36 38 35 36 37 31 34 64 64   USER0096856714dd
0010  34 34 34 30 62 32 33 30 32 30 62 61 31 39 66 39   4440b23020ba19f9
0020  33 61 66 63 39 38 31 30 34 63 35 36 61 63 31 65   3afc98104c56ac1e
0030  34 35 37 38 33 36 38 35 63 61 36 61 31 34 63 36   45783685ca6a14c6
0040  38 31 64 31 65 38 30 38 34 31                     81d1e80841
    Data: 555345523030363638353637313464643434343062323330...
    [Length: 74]

No.     Time        Source                Destination           Protocol Info
    310 23.157561   202.179.183.0         0.0.0.0               TCP      11900 > device2 [ACK] Seq=1 Ack=75 Win=5840 Len=0

Frame 310 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Dasan_0b:2e:94 (00:00:cb:0b:00:00), Dst: AsrockIn_1d:fa:00 (00:00:22:00:fa:00)
    Destination: AsrockIn_1d:fa:85 (00:00:00:00:00:00)
    Source: Dgan_x:21:90 (00:d0:00:0b:2e:94)
    Type: IP (0x0800)
    Trailer: AAAA16D01CE9
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst:
Transmission Control Protocol, Src Port: 11900 (11900), Dst Port: device2 (2030), Seq: 1, Ack: 75, Len: 0
    Source port: 11900 (11900)
    Destination port: device2 (2030)
    [Stream index: 21]
    Sequence number: 1    (relative sequence number)
    Acknowledgement number: 75    (relative ack number)
    Header length: 20 bytes
    Flags: 0x10 (ACK)
    Window size: 5840
    Checksum: 0x1ce9 [validation disabled]
    [SEQ/ACK analysis]


4) 결과

* 카페 채팅에 접속하기 위한 유령 프로그램을 작성하여 인증을 받고 접속 성공
* 암호화된 송신 패킷의 복호화 및 패킷 구조 분석 완료
* 패킷 암호화 및 복호화 루틴 작성, 테스트 성공
* 모조 패킷 전송 성공


- 접속하지 않고 채팅 내용 도청과 아이디 도용, 상태 메시지 조작 가능
  강퇴 권한을 갖는 것은 시간 문제겠지만..
  그 이상의 시도는 위험하기 때문에 보류하겠습니다. : )

  어디까지나 호기심 탐구가 목적이기 때문에 이쯤에서 마무리하겠습니다.


Written by Simhyeon, Choe