KSK 101

AMD features 

Advanced Clock Calibration 

ACC is a feature offered by AMD's SB710 and SB710 Southbridges and processors with a
K10 architecture. It allows separate settings for all individual cores of the processor and also
the CPU's overclocking capabilities by altering internal settings. Besides that it is said to be
possible to unlock deactivated cache and cores of certain processors although this is not
officially supported or recommended by AMD. 

AMD Overdrive 
This tool grants access to real-time adjustments of many system attributes and thus it
allows for example easy, on-the-fly overclocking. Furthermore AMD Overdrive also offers
benchmarking and stability testing features. 

AMD-V 
AMD Virtualization is the virtualization extension for AMD's x86 processors. 

Black Edition 
The processors that carry the Black Edition tag differ from the other AMD CPUs because of
their open multiplier. Increasing the multiplier is an easy way to increase the frequency a
processor is running at. Therefore Black Edition CPUs are especially popular among
overclockers. 

Cool'n'Quiet 
Cool'n'Quiet is a feature of AMD CPUs that automatically reduces the frequency and the
voltage of a CPU in order to lower the power consumption and the temperature. 

EVP 
The Enhanced Virus Protection, also known as NX Bit, is a security system that prevents so
called buffer overflow attacks. If a system supports EVP the processor prevents that
malicious software can insert code into the memory area of other programs and execute it
there. 

Hyper Transport 
Hyper Transport is a bidirectional serial/parallel point-to-point link with a high bandwidth
and a low-latency. HT has several areas of application. In certain processor architectures
AMD uses Hyper Transport as a replacement of the Front Side Bus., but it is also part of
AMD's Direct Connect Architecture. 

Presidio 
AMD's Presidio is a feature of AMD processors that uses special commands to provide a
fundament for Trusted Computing. 

Side Port Memory 

The idea behind side port memory is to provide the integrated graphics unit of certain AMD
chipsets with an extra amount of memory in order to reduce the usage of the system
memory itself and thus to increase the overall performance. 
TDP 
The Thermal Design Power is the maximal heat a CPU can emit and thus the maximal heat
the cooling solution in use has to deal with. 

AMD processors 
The Central Processing Unit could more or less be called the brain of a computer. It is the
component responsible for executing programs. Below you can see a list of AMD processors
that have been release for the Sockets AM2, AM2+ and AM3. The chart also delivers
detailed information like the frequencies, the amount of cache or the Thermal Design Power.

Hard Disk

A computer relies on its hard drive to store nearly everything that it needs to operate,
including all of its programs and data. Hard drive capacity has steadily increased while the
cost and physical size of the drives have decreased at the same time. Constant research
into this field of technology may guarantee that what is standard today will probably be
replaced by something better tomorrow. At the same time, the general characteristics of the
hard drive will remain the same.

Floppy Disk

Floppy drives are a type of disk drive that can read and write to special disks called floppy
diskettes, which are like CDs and DVDs in that they hold information. However, floppy
diskettes hold a lot less information than CDs and DVDs. Floppy drives have been largely
replaced by optical drives (CD/DVD) and are very rarely sold with new computers.

CD & DVD

A CD and a DVD disc might look similar, but because a DVD holds more data on it, there are
physical differences between the two disc formats. So It would be logical to assume that
there are also differences between the CD and DVD drives that are used with these discs.
But in point of fact, there are actually a number of characteristics that DVD and CD drives
both share as optical drives.

Tape

This paper discusses the problem of setting operating bias current so that the ultimate in
performance can be obtained from -Long Recording- type tapes, which possess more critical
bias-output characteristics than do the standard varieties. The results of a wide survey of
commercial-recorder bias are given, and it is concluded that machines should be equipped
with provision for bias adjustment.

Memory Card

A memory card is a storage of digital data used most often for the storage of digital images
in digital cameras (APN) for backup parts on video game consoles, but also in MP3 music
players or professional electronic equipment such as total stations.

Smartcard support
Future smart card support will be based on:
 A Bus:

 CCID specification for USB Smart card reader device implemented as a ccid bus (-

device usb-ccid)

 Two devices (you can use either one)

 passthru protocol to connect to remote computer carrying physical (or virtual)

smartcard (-device ccid-card-passthru)

 emulated card using NSS backend with certificates or real hardware on qemu running

host (-device ccid-card-emulated)

This page is mainly about documention the protocol used for remote reader and card support.

The protocol header is libcacard/vscard_common.h.

VSCard protocol
A header/payload protocol between the ccid-card-passthru device and a remote client. The protocol is

APDU oriented.

This page contains the header file in a form easy to extract, so this page can stay up to date with the

source.

To create the include file you need to be logged in and capable of pressing edit on this page. After

pressing edit select all, and then run:

xsel | gawk 'BEGIN { x=0 }; /^<pre>$/ { x+=1 }; /^<\/pre>$/ { x-=1; print ""; }; x==1
&& ! /<pre>/ { print }' > libcacard/vscard_common.h

(would be nice to have a direct url accessible)

Preamble

/* Virtual Smart Card protocol definition

*
* This protocol is between a host using virtual smart card readers,
* and a client providing the smart cards, perhaps by emulating them or by
* access to real cards.
*
* Definitions for this protocol:
* Host - user of the card
* Client - owner of the card
*
* The current implementation passes the raw APDU's from 7816 and additionally
* contains messages to setup and teardown readers, handle insertion and
 * removal of cards, negotiate the protocol via capabilities and provide
* for error responses.
*
* Copyright (c) 2011 Red Hat.
*
* This code is licensed under the LGPL.
*/

#ifndef VSCARD_COMMON_H
#define VSCARD_COMMON_H

#include <stdint.h>

#define VERSION_MAJOR_BITS 11
#define VERSION_MIDDLE_BITS 11
#define VERSION_MINOR_BITS 10

#define MAKE_VERSION(major, middle, minor) \

( (major << (VERSION_MINOR_BITS + VERSION_MIDDLE_BITS)) \
| (middle << VERSION_MINOR_BITS) \
| (minor) )

/** IMPORTANT NOTE on VERSION

*
* The version below MUST be changed whenever a change in this file is made.
*
* The last digit, the minor, is for bug fix changes only.
*
* The middle digit is for backward / forward compatible changes, updates
* to the existing messages, addition of fields.
*
* The major digit is for a breaking change of protocol, presumably
* something that cannot be accomodated with the existing protocol.
*/

#define VSCARD_VERSION MAKE_VERSION(0,0,2)

Message Types

typedef enum {
VSC_Init = 1,
VSC_Error,
VSC_ReaderAdd,
VSC_ReaderRemove,
VSC_ATR,
VSC_CardRemove,
 VSC_APDU,
VSC_Flush,
VSC_FlushComplete
} VSCMsgType;

Error Codes

typedef enum {
VSC_SUCCESS=0,
VSC_GENERAL_ERROR=1,
VSC_CANNOT_ADD_MORE_READERS,
VSC_CARD_ALREAY_INSERTED,
} VSCErrorCode;

Reserved Reader ID numbers

#define VSCARD_UNDEFINED_READER_ID 0xffffffff

#define VSCARD_MINIMAL_READER_ID 0

Other Constants

#define VSCARD_MAGIC (*(uint32_t*)"VSCD")

Header struct

/* Header
* Each message starts with the header.
* type - message type
* reader_id - used by messages that are reader specific
* length - length of payload (not including header, i.e. zero for
* messages containing empty payloads)
*/
typedef struct VSCMsgHeader {
uint32_t type;
uint32_t reader_id;
uint32_t length;
uint8_t data[0];
} VSCMsgHeader;

Messages
Init
/* VSCMsgInit Client <-> Host
* Client sends it on connection, with its own capabilities.
* Host replies with VSCMsgInit filling in its capabilities.
*
* It is not meant to be used for negotiation, i.e. sending more then
* once from any side, but could be used for that in the future.
* */
typedef struct VSCMsgInit {
uint32_t magic;
uint32_t version;
uint32_t capabilities[1]; /* receiver must check length,
array may grow in the future */
} VSCMsgInit;

Error

/* VSCMsgError Client <-> Host

* This message is a response to any of:
* Reader Add
* Reader Remove
* Card Remove
* If the operation was successful then VSC_SUCCESS
* is returned, other wise a specific error code.
* */
typedef struct VSCMsgError {
uint32_t code;
} VSCMsgError;

Reader Add

/* VSCMsgReaderAdd Client -> Host

* Host replies with allocated reader id in VSCMsgError with code==SUCCESS.
*
* name - name of the reader on client side, UTF-8 encoded. Only used
* for client presentation (may be translated to the device presented to the
* guest), protocol wise only reader_id is important.
* */
typedef struct VSCMsgReaderAdd {
uint8_t name[0];
} VSCMsgReaderAdd;

Reader Remove

/* VSCMsgReaderRemove Client -> Host

 * The client's reader has been removed.
* */
typedef struct VSCMsgReaderRemove {
} VSCMsgReaderRemove;

ATR

/* VSCMsgATR Client -> Host

* Answer to reset. Sent for card insertion or card reset. The reset/insertion
* happens on the client side, they do not require any action from the host.
* */
typedef struct VSCMsgATR {
uint8_t atr[0];
} VSCMsgATR;

Card Remove

/* VSCMsgCardRemove Client -> Host

* The client card has been removed.
* */
typedef struct VSCMsgCardRemove {
} VSCMsgCardRemove;

APDU

/* VSCMsgAPDU Client <-> Host

* Main reason of existance. Transfer a single APDU in either direction.
* */
typedef struct VSCMsgAPDU {
uint8_t data[0];
} VSCMsgAPDU;

Flush

/* VSCMsgFlush Host -> Client

* Request client to send a FlushComplete message when it is done
* servicing all outstanding APDUs
* */
typedef struct VSCMsgFlush {
} VSCMsgFlush;

FlushComplete
/* VSCMsgFlush Client -> Host
* Client response to Flush after all APDUs have been processed and
* responses sent.
* */
typedef struct VSCMsgFlushComplete {
} VSCMsgFlushComplete;

Wrap

#endif // VSCARD_COMMON_H