ABSTRACT Enabling Trusted Software Integrity
Enabling Trusted Software Integrity
Darko Kirovski Microsoft Research One Microsoft Way Redmond,WA98052 darkok@https://www.wendangku.net/doc/3d15040497.html,
Milenko Drini′c
Computer Science Dept.
University of California
Los Angeles,CA90095
milenko@https://www.wendangku.net/doc/3d15040497.html,
Miodrag Potkonjak
Computer Science Dept.
University of California
Los Angeles,CA90095
miodrag@https://www.wendangku.net/doc/3d15040497.html,
ABSTRACT
Preventing execution of unauthorized software on a given computer plays a pivotal role in system security.The key problem is that although a program at the beginning of its execution can be veri?ed as authentic,while running,its execution?ow can be redirected to externally injected ma-licious code using,for example,a bu?er over?ow exploit. Existing techniques address this problem by trying to de-tect the intrusion at run-time or by formally verifying that the software is not prone to a particular attack.
We take a radically di?erent approach to this problem. We aim at intrusion prevention as the core technology for enabling secure computing systems.Intrusion prevention systems force an adversary to solve a computationally hard task in order to create a binary that can be executed on a given machine.In this paper,we present an exemplary sys-tem—SPEF—a combination of architectural and compila-tion techniques that ensure software integrity at run-time. SPEF embeds encrypted,processor-speci?c constraints into each block of instructions at software installation time and then veri?es their existence at run-time.Thus,the processor can execute only properly installed programs,which makes installation the only system gate that needs to be protected. We have designed a SPEF prototype based on the ARM in-struction set and validated its impact on security and per-formance using the MediaBench suite of applications.
1.INTRODUCTION
Preventing execution of unauthorized software on a com-puting system is an essential part of system security.Most computing systems rely on the operating system and basic cryptographic primitives to provide security features that ensure data,program,and execution?ow authenticity and integrity.Unfortunately,the complexity of modern operat-ing systems(e.g.,Microsoft’s Windows XP Embedded con-tains up to10,000integrated modules)and the fact that an adversary needs only a single unprotected entry point to gain control over a system,have made malicious code into a Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for pro?t or commercial advantage and that copies bear this notice and the full citation on the?rst page.To copy otherwise,to republish,to post on servers or to redistribute to lists,requires prior speci?c permission and/or a fee.
ASPLOS X10/02San Jose,CA,USA
c 2002ACM1-58113-574-2/02/0010...$https://www.wendangku.net/doc/3d15040497.html,mon security problem on all systems that allow incom-ing tra?c from distruste
d sources such as th
e Internet.
A key problem in such systems is that although a program at the beginning of execution may be veri?ed as authentic, while running,its execution?ow can be redirected to ex-ternally injected malicious code using,for example,a bu?er over?ow exploit[22].Once the adversary executes injected code in the highest trust-priority mode,usually all system resources are at her disposal.In that case,the possibility for malicious actions is fairly broad including:destruction (e.g.,disk formatting,deleting?les),replication(e.g.,Inter-net worms),network tra?c analysis(e.g.,packet sni?ng), and covert communication(e.g.,Trojan horses).Ease of im-plementation and e?ectiveness have established attacks that focus on redirecting program execution as the most common threat to system security[18,6].The research community has addressed this problem from two perspectives:?Intrusion detection–a set of mechanisms that aim at scanning system resources and detecting the activity of intrusive agents[5].
?Formal veri?cation–a set of formally de?ned methods that either change the de?nition of the programming language so that executables are impervious to bu?er over?ow attacks[12],or perform static analysis on bi-naries to verify that they do not have bu?er over?ow exploits[27].
1.1Intrusion Prevention
In this paper,we take a radically di?erent approach.We aim at intrusion prevention as the core technology for enabling secure computing systems.The goal of an intru-sion prevention system is to force an adversary to solve a computationally di?cult(preferably intractable)task in or-der to create a binary that can execute on a given machine. According to this de?nition,the only way that an adversary can inject software into a protected system is by forcing a trusted user to explicitly install it,which is,in a sense,the best we can hope for,as a trusted user can always choose to install a malicious program.
As a demonstration of an intrusion prevention system,in this manuscript,we introduce—SPEF1—a framework of architectural and compilation mechanisms that ensure soft-ware integrity at run-time.SPEF installs a software bi-nary by encoding a set of constraints,unique to the pro-cessor,into each block of instructions.Speci?cally,the bi-nary is modi?ed using local peephole transformations and 1SPEF–S ecure P rogram E xecution F ramework.
rescheduling techniques that do not alter program function-ality and that have nominal impact on code run-time.SPEF exploits the fact that a given program binary has numerous representations that all satisfy the desired functionality and which all are within certain small performance bounds.The entropy of these representations is used as a communication channel to store the processor-speci?c constraints.
While constraint encoding is a post-compilation proce-dure,constraint veri?cation is performed in the processor for each block of referenced instructions.The di?culty of creating a valid block of instructions stems from the fact that the constraints are encoded using a keyed and crypto-graphically secure one-way hash function,where the secret key is hidden in the processor hardware and cannot be ac-cessed by any program except the software installer.Thus, software installation must be performed in a special mode, much like the boot procedure on a modern PC.
1.2System Features Enabled by SPEF
SPEF is a cryptographic tool used by the operating sys-tem to ensure that users are not able to switch from their user-mode into another one that is either of higher security or that impersonates another user.SPEF represents a fun-dament for secure execution of programs as it can police the crucial three trust modes on a given platform:trusted OS kernel mode which cannot be accessed by any user,all variants of user modes(private,public,shared),and a dis-trusted public mode.Hence,SPEF can actually provide a platform for execution of an arbitrary distrusted program,a scenario typical for distributed computing platforms such as peer-to-peer networks.SPEF enables the operating system to realize the following basic modes of operation.
Public mode(a)–in this mode,SPEF is disabled.There-fore,this mode does not provide protection for software integrity.On the other hand,since SPEF is not used in this mode,the user can run performance-critical applica-tions that do not require software protection.Similarly,the user can run programs downloaded from the Internet that have not being authenticated,while having the insurance that these programs cannot launch a bu?er over?ow or sim-ilar code alternation attack against processes running at a higher priority.Finally,this mode opens a spectrum of op-portunities for deploying a computer in a peer-to-peer net-working scenario:including?le-sharing,collaboration,etc. Just as in a traditional system,the computer resources avail-able in this mode are governed by the administrator–either UNIX-like chmod type of access control or a digitally signed registry are both possible as a control mechanism.
Trusted mode(b)–in this mode,SPEF is enabled which means that all programs executed in this mode must be in-stalled.Since programs in this mode are veri?ed for in-tegrity and authenticity,SPEF can protect system and user resources from malicious users.Trusting the operating sys-tem is important from the perspective that the administra-tor user(e.g.,the most privileged user)must not be able to access the resources that are protected for another user if sharing is not speci?ed.In that respect,there can be two trusted submodes:
(b.1)User mode–where information and software integrity
are protected among users with typical submodes such as private and shared resources.(b.2)OS kernel mode–this mode is the root of trust for
the maintenance of security policies among users.Ev-ery time a resource is accessed,the operating system takes over the call in this mode,to ensure that proper access is given to accredited entities.This mode can be enforced using several mechanisms–the simplest one probably being?xed memory mapping.The de-scription of the environment that would handle such policing is beyond the scope of this paper,however,it strongly resembles traditional operating systems such as UNIX or Microsoft Windows.
Installation mode(c)–the purpose of installation in SPEF is to encode processor speci?c constraints into pro-grams such that they can be executed in trusted mode.Since the constraints are dependent upon the root of system secu-rity,processor’s secret key,the requirement imposed upon a process executed in installation mode is not to leak this secret under software and most hardware attacks.Details of how this mode operates are presented in Subsection3.2.
The operating system can run in modes(a-b),however,its access management procedures must run in the(b.2)mode. Since SPEF induces certain performance overhead,in or-der to trade speed for security,users can run programs in mode(a)for maximum performance.Clearly,SPEF enables ?exibility in terms of functionality,performance,and strong software integrity of the computing platform.
2.ATTACK MODEL
In this paper,we consider a fairly broad class of attacks in which the goal of the adversary is to subvert the execu-tion of a given program into a program of adversary’s choice at the highest trust-priority mode.In such a scenario,the adversary operates either remotely(typical for client-server scenarios)or from a lower trust-priority mode(typical for peer-to-peer networks or application service providers).In the?rst case,the adversary scans the remote computer’s ports for networking services with known security?aws and then penetrates the system by exploring their vulnerabili-ties.In the second case,the adversary is already running a program on the remote system,but not at the highest trust-priority mode.In this case,the adversary can use the vulnerability of any system procedure already running in the top priority mode and try to subvert its execution?ow towards a desired malicious procedure.System vulnerabili-ties usually stem from network and cryptographic protocol incorrectness(such as the802.11hack[2]),careless protocol or system call implementations(e.g.,the setuid()system calls on UNIX systems[4]),or improperly conceived I/O.
In this section,we focus on the most common type of at-tacks that belong to this class:bu?er over?ows2.In order to be vulnerable to this attack,a program must have at least one bu?er with an unchecked over?ow.The simplest bu?er over?ow attack,stack smashing[22,18],overwrites a bu?er on the stack to replace the function call return ad-dress.Figure1illustrates how execution is subverted in the case of stack smashing.The adversary writes into the target bu?er enough information to overwrite the return address of the currently executed procedure and then places the ma-licious code.The return address is overwritten with the 2Also referred to as bu?er overruns.
address of the injected malicious procedure.The malicious code is typically a call to a function such as execve()on UNIX systems which kills the current process and launches an arbitrary binary in the same trust priority mode as was the killed process.Needless to say,the attack has numerous variants tailored to particular operating systems or program-ming language features.
A Memory Fragment
Higher
Lower
Figure1:Bu?er over?ow attack.By over?lling the unchecked bu?er,the attacker overwrites the origi-nal return address of the currently executed proce-dure and injects afterwards the malicious procedure. Upon return from the currently executed procedure, control?ow is diverted to the malicious code.
Bu?ers with unchecked over?ow commonly occur in soft-ware for two main reasons:most common programming lan-guages do not inherently generate bu?er manipulation code that checks for over?ows and the inevitable programmer’s mistakes.For example,programs written in C,which pro-vides direct low-level memory access and pointer arithmetic, are particularly susceptible to bu?er over?ow attacks as common standard string functions(e.g.,gets()or strcpy()) do not check for bu?er over?ow.
The solutions to bu?er over?ow attacks can be divided into two categories:run-time detection and static source code analysis.A typical example of the?rst type of solutions is StackGuard,a set of compiler enhancement mechanisms, that generates binaries which insert a”dummy”value on the stack next to the return address[5].Programs check if the value has been tampered with before jumping back to the calling function.The technology provides decent pro-tection against most common bu?er over?ow attacks with a relatively large performance overhead[5];however,the technology is not provably secure against a generic bu?er over?ow attack[5].Similar,run-time solutions observe po-tentially dangerous operations to restrict further execution in case of an intrusion[3,9].
Static source code analysis techniques range from fast and simple error detection,such as type errors and uninitialized variables[11,28]to complex,powerful,and relatively slow formal veri?cation-based tools that detect variety of bugs, including null pointers and errors in de?nitions,allocation and aliasing[8,7,24].Wagner et https://www.wendangku.net/doc/3d15040497.html,ed static analysis techniques as the?rst step toward automated bu?er over?ow detection–their static analyzer generates large number of false alarms that must be veri?ed manually[27].
In general,both run-time intrusion detection and static analysis including formal veri?cation may prove to be quite e?ective in certain cases.However,both approaches require manual support and hence fall short in the case of a human error,the most proli?c vulnerability manufacturer.The pos-sibilities for intrusion are numerous–e.g.,every?oating pointer in a program can be used potentially as an intrusion gate.The methodology that we present in this work aims at preventing an arbitrary intrusion attack;we aim at forcing the adversary solve a di?cult problem rather than having the intrusion detection or formal veri?cation software per-form a computationally challenging task in the pursuit for impenetrable system security.
3.SPEF-SYSTEM DESCRIPTION
The main goal of SPEF is to ensure that a potential in-truder has to solve a computationally intractable task in order to execute any desired code on a SPEF-protected ma-chine.SPEF achieves this objective by relying on both hardware and software-based mechanisms.A block of in-structions3is an atomic execution unit on a SPEF machine. During software installation,each block of instructions is transformed depending upon a cryptographic key.This key is securely stored in the processor.The transformations are invariant with respect to functionality.During the trans-formation,SPEF?rst computes a transformation-invariant hash of the instruction block.In other words,the hash is such that regardless of the considered instruction transfor-mations(e.g.,instruction rescheduling),it always has the same value.The computed hash is then encrypted with the secret key,which results in a random string of bits.The val-ues of these bits are used to select a unique transformation of the instruction block(e.g.,a particular instruction order in the case of instruction rescheduling).
During program execution,the SPEF veri?er,part of pro-cessor’s hardware,repeats the steps taken by the software installation procedure.First,it computes the hash of the instruction block.Note that because the hash value is in-variant to the applied transformations,the hash value com-puted during veri?cation is equal to the one computed dur-ing installation.Then,it generates the random string of bits.Finally,it veri?es that the instruction block satis?es the constraints imposed by this bitstream(e.g.,instruction order is the same as the order imposed by the computed bitstream).If the constraints are not satis?ed,the SPEF veri?er concludes that the instruction block has not been installed properly or that it has been altered and generates an interrupt that aborts the execution of the current process. Intuitively,SPEF is a cryptographic tool that signs a block of instructions during installation and stores this sig-nature in the instruction block itself.The signature(random bitstream)does not need to use public-key cryptography be-cause the signing key(processor’s ID)is never revealed ex-ternally.In an ine?cient implementation of SPEF,the sig-nature can be stored in the instruction block as is,for exam-ple,as a footer.However,cryptographically secure hashes such as SHA1or MD5require at least20bytes of storage space,which increases code size by an excessive amount.We exploit the fact that a given program binary has numerous representations that all satisfy the desired functionality and which all are within certain small performance bounds.The 3Depend ing on the implementation,the length of this block can correspond,for example,to the size of the instruction cache line or pre-fetch bu?er.
entropy of these representations is used as a communication channel to store the signature,which signi?cantly reduces both the storage and,indirectly,performance overhead im-posed by the embedded signature.
The most important potential limitation of SPEF is its performance overhead–a price that needs to be paid for trustworthy computing.First of all,as experiments show, this overhead is reasonably low.In addition,SPEF is not conceived as a mandatory execution platform within a com-puting system–it can be deployed only for select processes that require high level of software and data integrity(e.g., OS kernel,e-mail agents).Processes that do not require such level of security can be executed in a mode that does not deploy SPEF run-time code veri?cation and hence,gets the maximum performance from the system.
3.1Preliminaries
SPEF is a platform that consists of architectural mech-anisms and compilation tools with intrusion prevention as an objective.In this section,we present the key entities in SPEF and describe their interaction during software in-stallation and run-time software veri?cation.SPEF’s key components and their activity are illustrated in Figure2.
Processor-unique identifier-CPU ID.The root of security is a read-only register with a secret key that is unique for each processor.Burning unique identi?ers is a standard manufacturing practice as demonstrated by the Pentium III processors[10].Intel’s goal with the Processor Serial Number(PSN)was to provide a link between comput-ers and their”owners”,then identify computers to external agents(such as e-commerce web-sites),who can in return develop services for their”owners”tailored to this feature. Such an application posed a myriad of privacy and imper-sonation concerns that forced Intel to disable this feature on their products[29].
The main goal of SPEF is to secure privacy rather to expose identifying information to external agents.Hence, the privacy problem does not occur in SPEF systems for two reasons:(a)the information that links SPEF’s CPU ID with its”owner”is not maintained just as with any other chip on the market with a serial number and(b)as a root of system security,the CPU ID is never revealed to any installed application,let alone an external agent4.Thus,it is in the best possible interest to the designers of a SPEF-like system to keep the CPU identi?er as secret as possible.
Software delivery.There are two essential procedures associated with software delivery:initial software instal-lation and software updates, e.g.,patching.In a SPEF-based system,from the perspective of a software distributor, these two actions are exactly the same as in conventional computing systems.A given application is distributed to clients or peers as a compiled binary-we denote it as the master-copy.The recipients of the software can validate the authenticity of the master-copy via standard authenti-cation methods that deploy public-key cryptography(e.g., via SSL).The master-copy cannot be executed on any of 4One remote possibility for an adversary who has physical access to a SPEF processor,is to extract/alter CPU’s ID by reverse engineering,and then perform malicious activities accord ingly. The cost of such an attack is signi?cant as an adversary must
d isassemble,revers
e engineer,and reassemble a SPEF-like chip without destruction.the target machines.Each target machine needs to cus-tomize the master-copy in order for it to run.The installed copy o
f the program,denoted as the working-copy,is func-tionally equivalent to the master-copy but augmented with processor-speci?c constraints.In high-security mode,only a working-copy can be run on the SPEF platform.The same installation procedure needs to be performed for both the initial installation and subsequent updates.
3.2Software Installation
Software installation consists of several steps illustrated in Figure2.In the?rst step,the CPU enters a special installa-tion mode used exclusively for software installation.Since the CPU ID is a system’s master secret,it must never leave the pins of the CPU.The installer must access the CPU ID to create application’s working-copy.This special mode of operation ensures that the CPU ID is kept secret from soft-ware and most hardware attacks.This is done by following a simple recipe:(a)installation is executed atomically,i.e. without any interruptions,(b)the installer must not write the CPU ID or any other variable that discloses bits of the CPU ID o?chip,and(c)before completion,the installation procedure must overwrite any intermediate results or vari-ables stored in on-chip memory.Here is an example of steps that a CPU should follow to enter this mode:
Calling the installer.First,the arguments to the software installer are fetched to a predetermined and?xed address in the main memory.The arguments encompass the location and size of the input master-copy,the location where the working-copy should be stored,and potentially,a password5that enables only an authorized party to install software.Following the principles of traditional password systems,the hash of this password is stored on-chip in non-volatile memory(e.g.,?ash memory).Before proceeding to the next step,the CPU veri?es whether the hash of the entered password is the same as the stored hash and then continues to the next step.
Since the installer operates in a single process mode,it uses physical rather than virtual addresses.Thus,the OS needs to forward the physical addresses of source and desti-nation bu?ers to the installer.This can be done in several ways that may include hardware support.The OS is respon-sible for freeing the operating memory used as an output destination.If the OS is not installed,the installer assumes certain default values for its arguments.
Disabling context switching.The calling procedure must disable all soft and hard interrupts on the CPU before issuing the call.Hardware can verify that CPU ID is ac-cessed only if all interrupts are disabled.Alternatively,the CPU can have hardware support to bu?er interrupts while in the installation mode.This renders context switching on the CPU during software installation impossible.This step is important for preventing possible leakage of secrets or other types of manipulations.
Diverting control to the installer.Finally,the program counter is redirected to the memory address where the software installer is located.The software installer is a program that can be stored on-chip in read-only memory or 5User authentication can be also achieved using smart cards.
Random
Figure2:Flowchart describing the components and procedures of the SPEF system.
externally.In the latter case,the content of the external ROM must be validated using a cryptographic hash within the CPU prior to loading the?rst instruction of the installer. In this case,the expected value of the hash must be stored permanently6in the CPU.
Note that this mode of operation is actually not particu-larly unique,as most boot procedures for modern processors are performed in similar fashion from external ROMs con-taining BIOS-like software[19,16].
3.2.1Constraint Encoding
The main goal of the software installer is to encode unique constraints for a given processor,into the target binary in a secure manner.An application’s working-copy is created by processing individual blocks of instructions.An instruction block(I-block)is an atomic execution unit;even if the CPU executes only a single instruction from an I-block,the entire I-block must be validated to begin execution of this instruc-tion.I-block size is governed by the size of the instruction pre-fetch bu?er in the CPU-typically block size is64to256 instructions.Smaller blocks do not o?er su?cient transfor-mation entropy,while larger blocks impose hardware and performance overhead.
Installation of each I-block is performed in three steps:do-main ordering,computation of the transformation-invariant hash of the I-block,and?nally,constraint embedding.SPEF can operate with di?erent types of constraint encoding tech-niques such as:assigning variables to a pseudo-random per-mutation of available registers,instruction scheduling,branch-type selection,and basic block reordering.Note that all these transformations preserve program’s functionality.For the sake of brevity,here we use instruction rescheduling as an exemplary constraint to demonstrate the procedures in-volved in software installation(details on constraint encod-ing are presented in Section4.1).The installation process of an I-block is illustrated in Figure3.
Domain ordering.For a given type of transformation, the goal of domain ordering is to assign a unique identi?er to each component of the domain in which constraints are embedded.The ordering policy must be invariant under the transformations used in constraint encoding,so the assigned unique identi?ers are identical before and after constraint 6Replacement of this hash value may be allowed only in installa-tion mod e.Then,the CPU must store on-chip the public key of the trusted authority issuing valid hash values.This key is used
to verify signatures of new hash values.embedding.For example,domain ordering for instruction scheduling could be to assign a unique number to each in-struction within a basic block according to a standardized policy(e.g.,sorting instructions with preserved dependen-cies based on their op-code).
SUB...
MOV...
MOV...
DIV...
MULT...
XOR...
SUB...
JUMP...
ADD...
MOV...
SUB...
MOV...
MOV...
DIV...
MULT...
XOR...
SUB...
JUMP...
ADD...
MOV...
Figure3:Constraint encoding on the example of instruction rescheduling as a transformation.
Transformation-invariant hash(TI-hash).In this step,SPEF computes the TI-hash of the content of the I-block.The TI-hash is a sequence of bits used to generate the constraints.Clearly,since the embedded constraints must be invariant under the change that they introduce in the I-block,the TI-hash must be invariant with respect to the transformations that embed the constraints.Because of the transformation invariance,the TI-hashes computed for the master-and working-copy of an I-block are equal.As a di-rect consequence,any working-copy from an arbitrary client can be used as a master-copy on all other clients.An exam-ple of structures that stay intact after common exemplary transformations,are:control-data?ow graphs,instruction types,and values of constants.
Constraint embedding.Constraints are embedded into the I-block as directed by a256-bit pseudo-random bit-stream.This stream is created by encrypting the TI-hash using a standard cipher(3DES or AES)keyed with the se-cret CPU ID.For example,for instruction scheduling,em-bedding a set of constraints means that a particular schedule
of instructions within an I-block is enforced with preserved functional dependencies.A single constraint is encoded as the order in which two independent instructions I0and I1 appear(e.g.,0from the bit-stream directs I0to appear be-fore I1).The modi?ed I-blocks are assembled into a?nal working-copy of the executable.
3.3Program Execution
The working-copy of a program can be executed on the processor in any of the operation modes enabled by SPEF. While executing the working-copy of the program,the pro-cessor performs several steps:it loads a block of instructions, veri?es the embedded constraints in this I-block,and?nally approves its execution.The veri?cation procedure consists of the same three steps as constraint encoding.The only di?erence is that instead of embedding constraints,the veri-?er analyzes whether the constructed constraints match the ones in the I-block.If the veri?er detects a complete match, the code in the I-block is executed.Otherwise,the veri?er sends an abort signal to the processor which can be resolved in several ways:for example,non-blockable exception or sys-tem reset.In the former case,the OS on the processor can then terminate the process.
The constraint veri?cation procedure is performed by on-chip hardware.The constraint veri?er can be implemented in numerous ways.For example,the I-block bu?er can be multiplexed from the set of instruction cache lines.Instruc-tions must be veri?ed every time a new I-cache line is loaded. Since writes to the I-cache are not possible,veri?cation is not necessary for repeat accesses to any of the lines.This ap-proach may have adverse e?ect on processor’s critical path due to additional logic attached to the I-cache.Another implementation is to have the I-block bu?er precede the I-cache as a pre-fetch unit.In addition,the results of several units in the processor such as the out-of-order execution unit(basically,its scheduler)can be reused in the SPEF veri?er[26].Then,the hardware that supports speculative execution can be used to compensate for the delay caused by the SPEF engine by executing the freshly loaded I-block, but not committing the actual transactions until the SPEF veri?er does not validate the code[25].
For the sake of brevity and simplicity,in this paper we adopt the?rst implementation with a pipelined constraint veri?er as the only performance improving technique.For the set of constraints that we have considered in our imple-mentation of SPEF,we estimated that the veri?er should not exceed20K gates,thus inducing little overhead to the hardware design.However,our particular implementation of SPEF induces non-trivial delay as constraints are veri?ed for every I-block fetched into the I-cache upon a miss.In our implementation,the pipelined constraint veri?er which interleaves constraint veri?cation with data fetching from main memory results in a50-clock-cycle delay(detailed in Section4.1).Typically,execution of many common appli-cations for embedded systems have high I-cache hit rates; hence,the overhead of SPEF on actual run-time is frequently within20%of the performance of the traditional system. We quantify the e?ect of SPEF on the performance of standard multimedia tasks[13]implemented for the ARM instruction set and the ARM TDMI720processor[1].
4.SPEF-AN IMPLEMENTATION
In this section,we present the technical details of an im-plementation of the SPEF framework for the ARM instruc-tion set.We have chosen the ARM hardware-software devel-opment toolkit for two main reasons:simplistic RISC-type instruction set and availability of tools that support simula-tion of additional logic attached to the main processing unit. It is important to stress that implementation of a SPEF-like platform for another processor and instruction set,such as Intel’s x86,may pose new challenges due to sophisticated super-scalar pipelined ALUs,variable length instructions, branch prediction,multi-processor support,etc.
In this section,we detail how domain ordering,TI-hashing, and constraint generation,encoding,and veri?cation are performed for three types of transformations and the ARM instruction set.The considered constraint types are:in-struction rescheduling,basic block reordering,and permutation of register assignment.They satisfy the following set of requirements:
?High degree of freedom.Each type of constraint
should provide a rich domain for code transformation,
implying a large number of distinct representations for
a given I-block.
?Functional transparency.The induced transforma-
tions must not alter program’s functionality.
?Transformation invariance.The encoding of con-
straints must depend exclusively on the functionality
of an I-block and processor’s CPU ID.Constraint en-
coding must be exactly the same before and after the
constraints are embedded into an I-block.Thus,the
induced code transformations due to constraint encod-
ing must not alter the result of domain ordering and
TI-hashing.
?E?ective implementation.The hardware imple-
mentation of the constraint veri?er must be fast and
require few silicon gates.
?Low performance overhead.The imposed changes
due to constraint encoding should have minimal per-
formance overhead.For example,instruction reschedul-ing poses little performance overhead on processors
with out-of-order execution7,however,it may have a
dramatic e?ect on heavily pipelined architectures.In
such a case,instruction rescheduling can be used with
certain additional constraints or not used at all as com-
monly,there is plenty of transformation freedom for a
given,relatively large,I-block.
The properties of the implemented protection system were tested using a benchmark test assembled from the Media-Bench test suite[13].It included the MPEG and JPEG codecs,PEGWIT,and a set of cryptographic primitives. 4.1Transformation Types
In this subsection,we present the technical details behind the embedding and veri?cation procedures for each type of code transformation(i.e.constraint type).We analyze two basic tasks performed during software installation and exe-cution:(i)domain ordering including TI-hashing and(ii) 7Out-of-order execution is a crucial component of almost every modern architecture that relies on inherited instruction sets(e.g., Intel’s x86),as pipeline structures of new generation processors are usually not built with the target to achieve high performance for programs optimized for the pipelines of the old architectures.
constraint generation,encoding,and validation.For each
constraint type,we provide an example and a quanti?ca-
tion of the main security parameter:degree of freedom
(DOF).DOF aims at modeling the entropy of an I-block
with respect to the considered transformations.
Definition 1.The degree of freedom of a given I-block with respect to a given set of constraint types quanti?es
the number of ways the I-block can be transformed such that
the functionality(semantics)of the I-block is preserved. The inverse of DOF equals the probability that a ran-
dom I-block of instructions(potentially malicious)acciden-
tally satis?es all required constraints considered for con-
straint embedding.Thus,DOF relatively accurately models
the security of the scheme.For a set of constraint types S={C1,...,C n}that are mutually orthogonal,i.e.trans-formation in one constraint domain does not a?ect the DOF
for another constraint domain,the total DOF of an I-block I,δ(I,S),equals the product of DOF for each individual constraint type:
δ(I,S)=
n
i=1
δ(I,C i),(1)
or from the perspective of the corresponding entropy:
H(I,S)=
n
i=1
H(I,C i)=?
n
i=1
log2
1
δ(I,C i
,(2)
whereδ(I,C i)denotes the number of possible distinct transformations of the I-block I using the transformation type C i.All transformation types evaluated in the follow-ing subsections are mutually orthogonal.
4.1.1C1-Instruction Reordering
Static instruction scheduling is an optimization technique that can greatly improve program performance,especially for heavily pipelined architectures that do not have out-of-order execution units.However,the targeted ARM proces-sor,as a single-issue architecture,is minimally a?ected by a particular instruction order within a basic block.Thus,we adopt instruction scheduling as a transformation for con-straint embedding.In this subsection,we evaluate the two key steps in SPEF for this type of transformation:domain ordering and constraint embedding.
Domain ordering.For this constraint type,domain or-dering assigns a unique identi?er to each data-?ow(non-branch)instruction.Since instructions are ordered only within basic blocks,domain ordering is performed indepen-dently for each basic block8.First,the data-?ow instruc-tions within a basic block are sorted with preserved depen-dencies using the following criteria easy to implement in hardware: e.g.,(i)instruction op-code that includes infor-mation about the number and indexing of operands and(ii) instruction fan-out.A fan-out of an instruction that sets reg-ister r,is de?ned as the XOR sum of op-codes of all instruc-tions that use the value in register r as a?rst operand.If there are no such instructions,the fan-out equals null.For 8Please see next subsection on how basic blocks boundaries are determined at run-time.example,consider instructions(1)and(2)in Figure4a that cannot be distinctly sorted using the?rst two policies.How-ever,the fan-out of instruction(1)is null and the fan-out of instruction(2)is opcode(MUL).This distinction is used to sort(1)ahead of(2).In our experiments,we have not encountered a single I-block that could not be fully sorted using the above set of policies.If certain instructions can-not be sorted distinctly(assigned unique identi?ers),then they are not considered in this transformation.The order-ing of the domain for the instruction rescheduling transform is formally presented using the pseudo-code in Figure5.
1for each instruction block B
2S1=sort B in decreasing order of op-codes
3Set(?i∈B)ID(i)=arg{i,S1}
4for each subset of instructions b∈B
with?i∈b|arg{i,S1}=const.
5S2=sort b in decreasing order of fan-out
6Set(?i∈b)ID(i)=ID(i)+arg{i,S2}
Figure5:Pseudo-code for ordering the domain of the instruction rescheduling transform.Function arg{i,S x}returns the index of instruction i in a sorted list S x.The index of the?rst element in the list equals zero.Instructions that cannot be dis-tinctly sorted,have equal,smallest possible,indices. ID(i)is the resulting instruction identi?er.
Constraint embedding.Based on the random bitstream, out of all possible permutations of instructions that preserve the functionality of an I-block,the constraint embedding al-gorithm selects one and reschedules the instructions accord-ing to this new instruction order.The scheduling algorithm constructively builds the ordering by selecting a speci?c in-struction from a pool of instructions that can be executed at a particular control step.
The constraint embedding is illustrated in Figure4.A simple code segment with six instructions illustrates the de-gree of freedom for instruction scheduling as a transforma-tion domain(see Figure4a).Each of the instructions can be scheduled in more than one control step either uncondi-tionally(denoted in Figure4a as⊕)or conditionally( )as shown on the right side in Figure4a.Control step i can be conditionally occupied by instruction(a)if there exists at least one more instruction whose scheduling in control step j enables scheduling of instruction(a)in control step i such that no data-?ow dependency between instructions is violated.For example,instruction(4)can be scheduled in step3only if both instructions(1)and(2)are scheduled in control steps1and2.Instruction(3)can be uncondi-tionally scheduled in any of the given steps since it does not have any data-?ow dependency with other instructions within the selected block.Even in such a small instance,the number of possible schedules in this example is24.
For simplicity reasons,the domain ordering used in this example is simpli?ed to the instruction numbering of their initial schedule.The instruction ordering algorithm shown in Figure4d constructs the ordering that represents the working-copy of the code as follows.There are three in-structions that can be scheduled in the?rst control step: (1),(2),and(3).The?rst four bits of the random bit-stream are0110.Since there are three instructions that can be scheduled at the?rst control step,we use the?rst two bits
b) Dependency graph
(1)(2)(3)
a) Initial order of instructions
and their possible positions
initial position
possible position
conditional possible position
stream used
Selected
d) Instruction ordering procedure
e) Final order of instructions
c) Sample bit-stream
Figure4:An example of constraint embedding for the instruction rescheduling transform.
from the bitstream10to select the corresponding instruc-
tion.In this case,according to the encoding in Figure4d,
instruction(3)is scheduled in the?rst control step.Note
that the number of instructions that can be scheduled at a
particular control step depends upon the preceding schedul-
ing decisions.The process continues using the subsequent
bits of the bitstream as illustrated in the example in Figure
4d.The resulting ordering is shown in Figure4e.
Constraint veri?cation.Whereas the software installer
enforces the generated constraints,the constraint veri?er
only validates their existence.The constraint veri?er per-
forms domain ordering,generates constraints based on the
extracted TI-hash,and validates that the particular order-
ing of instructions corresponds to the generated constraints.
Domain ordering can be performed using a hardware sorter
in log2(n)clock cycles,where n is the number of instructions
in the I-block.From the moment the random bitstream is
available,the actual veri?cation of constraints can be per-
formed in a single clock cycle.
Evaluating H(I,C1)is a hard task as the number of valid
scheduling solutions is commonly exponentially proportional
to the number of instructions within a basic block.In our ex-
periments,we have compiled our results using a lower bound
onδ(I,C1)which is computed as follows:if the length of
a basic block is shorter than10instructions9,we compute
δ(I,C1)exhaustively for each block in I:
δ(I,C1)=
?block∈I
δ(block,C1).(3)
Basic blocks with more than10instructions are parti-
tioned into sub-blocks of up to10instructions.We treat
each block as a basic block,and then computeδ(I,C1)ac-
cording to Eqn.3.Although this approach may grossly lower
the values for H(I,C1),it still provides a good estimate on
which I-blocks do not provide high H(I,C1).The results of
our approximation of H(I,C1)for MediaBench applications
are presented in Figure6.
4.1.2C2-Basic Block Reordering
9A block of ten mutually independent instruction can be sched-
uled in10!≈3.6·106di?erent ways.
In this subsection,we introduce basic block reordering as
another transform for constraint embedding.A basic block
generally refers to a section of code that has only one en-
try and one exit.Basic block identi?cation is one of the
elementary tasks used in optimizing compilers to improve
code e?ciency.In many instances,basic blocks can be relo-
cated with little overhead.In this subsection,we describe a
method to encode constraints using a speci?c permutation
of basic blocks in an I-block.
During code veri?cation,basic block boundaries are not
known inside of an I-block unless the basic block is ended
with a control transfer instruction such as a conditional
branch.Thus,we make an additional requirement for pro-
gram’s master-copy:if a basic block does not end with a
control transfer instruction,an unconditional branch to the
following instruction is inserted at the end of the block.
This way,the constraint veri?er is able to determine the
basic block boundaries necessary to extract the encoded
constraints.For our benchmark applications,on the av-
erage23%of basic blocks do not end with one of the control
transfer instructions,and the size of a basic block on the
average is4.7instructions.As a result,the insertion of un-
conditional branches increases the total program size7.5%.
Finally,basic blocks that span across two or more I-blocks
require special attention.Such basic blocks are partitioned
along I-block borders and treated as separate basic blocks.
Figure7shows a simple example that illustrates how basic-
block reordering is used as a transformation domain.A por-
tion of code with?ve basic blocks is shown.Both the initial
(in Figure7a)as well as the transformed(in Figure7b)ba-
sic block scheduling are presented.The arrows represent a
possible change of the execution order due to branching.All
execution paths must exist after the reordering procedure.
Thus,it is necessary to redirect some of the branches as well
as change their branching condition(e.g.,branch on address
0x00dce8).In some cases,it is necessary to insert uncon-
ditional branches such as the one at the address0x00dd20.
Reordering basic blocks results in a high degree of freedom
for constraint manipulation as there existδ(I,C2)=N!pos-
sible orderings for an I-block with N basic blocks.
Domain ordering.Basic blocks in an I-block are enu-
merated in the increasing order of the?rst data-?ow instruc-
50100050100050100050100050100
Mpeg Encode
Mpeg Decode
Jpeg Encode
Jpeg Decode
Pegwit
Degrees of Freedom - Instruction Scheduling
64-I n s t r u c t i o n B l o c k C o u n t
Figure 6:Experimental results measuring H (I,C 1)for instruction scheduling as a transformation type.The abscissa in each histogram represents the number of I-blocks with the DOF level speci?ed on the ordinate.
10
20
30
10
20
30
10
20
300
10
20
30
10
20
30
Mpeg Encode
Mpeg Decode
Jpeg Encode
Jpeg Decode
Pegwit
Degrees of Freedom - Basic Block Reordering
64-I n s t r u c t i o n B l o c k C o u n t
Figure 8:Experimental results measuring H (I,C 2)for basic block reordering as a transformation type.The abscissa in each histogram represents the number of I-blocks with the DOF level speci?ed on the ordinate.
a) Original order of basic blocks
b) Reordered basic blocks
Figure 7:An example of basic block reordering.Dif-ferent basic block schedules may involve addition of unconditional branch instructions.Such case occurs in basic block (3).
tion in each basic block.The procedure for enumerating instructions is presented in the previous subsection.Constraint embedding.The bitstream determines the ordering of basic blocks using the random permutation func-tion presented in the previous subsection.The number of bits m required to select a particular permutation of N >2basic blocks using this algorithm is:
m =
N i =2
log 2i < log 2N ! .
(4)
Constraint veri?cation.The constraint veri?er per-
forms domain ordering,generates constraints based on the
extracted TI-hash,and validates that the particular order-ing of basic blocks corresponds to the generated constraints.Domain ordering for basic block reordering waits for the enumeration result of the same procedure for instruction rescheduling.Then,it assigns a unique identi?er for each basic block –this step adds log 2(N )clock cycles to the de-lay imposed by the domain ordering hardware for instruc-tion rescheduling.Once the random bitstream is available,constraint validation can take potentially only a single cycle.Figure 8shows the experimental results measuring the pa-rameter δ(I,C 2)for our benchmark suite of applications.In our experiments,we observed an average of 11basic blocks per a 64-long I-block.However,in certain cases such as in the digital signal processing functions in MPEG,basic blocks can be larger than the I-block.
4.1.3
C 3-Permuted Register Assignment
The third transform considered for constraint embedding is register reassignment.Register allocation includes assign-ing variables to registers during the compilation process.This problem can be modeled as graph coloring where the nodes of the graph represent variables,edges between nodes represent overlapping lifetimes between variables,and colors correspond to registers.In SPEF,during the constraint em-bedding process,assignment of variables which are created within a given I-block is dictated by the random bitstream.It is important to stress that this type of transformation must be performed after instruction rescheduling constraints are embedded,because the domain ordering for permuted register assignment depends upon the result of that trans-formation 10.We denote the set of registers modi?ed within
10Hence,the
transforms need not be truly orthogonal in SPEF.
The only requirement is that constraints embedded by all con-sidered transforms must be detected properly if transforms are
a) Code segment with original
register assignment
c) Permuted register assignment of the
code segment
b) Working register
set (WRS)
Figure9:Example of a block of16ARM instructions taken from the MPEG2encoder.Six di?erent registers are set in this block.At any control step,at most four registers are candidates for reassignment.During constraint veri?cation,one out of216di?erent register assignments is selected.
an I-block as the working register set(WRS),which is a subset of the full register?le.The working register set represents the domain for this transformation.
Domain ordering.A unique identi?er X(i)assigned to a variable i is equal to the di?erence a-b where a is the address of the instruction that creates i and b is the starting address of the I-block.Registers are numbered following the ascending index in the register?le.
Constraint embedding.Constraint embedding is per-formed by assigning the variables generated within the I-block,to a random permutationπ(WRS)of the working set of registers.The new assignment is determined by the ran-dom bitstream,by the dependencies among variables,and by the set of available registers WRS(i)at control step i.The register reassignment within one I-block must be propagated throughout all I-blocks in which the modi?ed variables are alive.Note that the propagation is done only during con-straint embedding,not their veri?cation.Hence,it does not a?ect the computation of the TI-hash in the subsequent runs of the SPEF veri?cation hardware.
We illustrate permuted register assignment using an ex-ample presented in Figure9.A segment of ARM-code ex-tracted from an MPEG2encoder[13],contains16instruc-tions.The original register assignment of this code segment is shown in Figure9a.There are six distinct register as-signments and the a?ected registers are:WRS={r2,r3,r6, r7,r12,r14}.In the example,the constraint encoder uses the random bitstream to compute the following exemplary permutationπ(WRS)={r6,r7,r3,r2,r12,r14}.Figure9b shows the set of registers WRS(i)available for(re)assignment at each control step i.For example,in the?rst control step, we have:WRS(1)={r3,r6,r7,r12}.Registers r2and r14 are not elements of WRS(1)because they are used as sources in instructions prior to their assignment in the block.
The constraint encoder parses the I-block top-down and at each control step at which a new register is assigned to a variable,it selects a register from WRS(i)with the smallest index inπ(WRS).For example,register r6is assigned to the applied in particular order.variable created by the?rst instruction in the I-block.The used register replaces all appearances of the replaced https://www.wendangku.net/doc/3d15040497.html,ly,r6replaces all occurrences of r3in the block. Register r6is then removed from WRS.Registers that are used as source registers prior to their assignment,are added to WRS as they become available.For example,register r2 is added to WRS in control step5.The resulting register assignment is illustrated in Figure9c.
Constraint veri?cation.Domain enumeration is a triv-ial task for this type of transformation as variables are sorted in the order they are generated and registers inherit their register?le indices.The extraction of WRS as well as the permutation selected using the random bitstream,can be computed in a single cycle.In at most|WRS|steps,we can sequentially verify whether a particular variable has been assigned to a proper register as guided by the random bit-stream.Assuming the random bitstream is available,the veri?cation procedure can be performed in1+|WRS|cycles. As this number is limited by the cardinality of the working register?le,for the ARM architecture the veri?cation of the permuted register assignment is limited to seventeen control steps.The degree of freedom for this transformation type,δ(I,C3),is equal to:
δ(I,C3)=
N
i=1
|WRS(i)|≤N!(5)
where N is the number of modi?ed registers within the I-block and|WRS(i)|is the cardinality of the available subset of registers from the working set at control step i.Accordingly, for the code segment presented in Figure9,the total number of all possible register reassignments is4·3·3·3·2·1= 216.Figure10shows the experimental results measuring the parameter H(I,C3)for our benchmark suite of applications.
4.1.4Computing the Random Bitstream
For a given set of transformation types,the random bit-stream that guides constraint encoding is generated in two steps.First,the information in the I-block that is invari-ant to considered transformations is concatenated into a
10
2030
01020
3001020
3001020
300102030
Degrees of Freedom - Register Allocation
Mpeg Enco de
Mpeg Decode
Jpeg Encode
Jpeg Decode
Pegwit
64-I n s t r u c t i o n B l o c k C o u n t
Figure 10:Experimental results measuring H (I,C 3)for register reassignment as a transformation type.The abscissa in each histogram represents the number of I-blocks with the DOF level speci?ed on the ordinate.message (denoted as TI-hash).Instruction ?elds that con-tribute to this message are op-codes of data-?ow instructions and constants.The message,as de?ned,has variable length,whereas the keyed encryption mechanism used to create the random bitstream has a ?xed length input.This problem can be resolved by feeding the encryption mechanism in a CBC-MAC mode (see [15],§9.58)for as many iterations as required to process the entire message.Since each itera-tion takes several clock cycles (e.g.,in the case of DES,a typical implementation of one iteration costs 8cycles),this approach is not the most e?ective in terms of system per-formance.Another approach is to pipeline the encryption engine and process the message in blocks of K bits where K is cipher’s input data width and then get the desired length of the random bitstream by XORing the encrypted blocks.In our experiments,we have observed I-blocks that demand up to 160bits from the random bitstream to perform a full constraint encoding.Therefore,we restrict the length of the random bitstream to 256bits.
SPEF can deploy any of the popular encryption stan-dards which are particularly e?cient for hardware imple-mentations.Typical candidates would include a 112-bit key triple-DES or a 128-bit key AES,which create encrypted content after 8cycles per DES iteration or 16cycles in typi-cal low-cost implementations respectively.Pipelined imple-mentations would add overhead to the basic iteration period proportional to O (n ),where n is I-block length.
4.2SPEF –System Security
For the sake of brevity,in this paper we do not present details of the set of additional constraint types that we have evaluated in the SPEF framework.In addition to the con-straints (1-3)evaluated in Subsection 4.1,we have also stud-ied the following additional transformation types:
4.C 4–Conditional branch selection –refers to em-bedding constraints in an executable by selecting one of the two choices for each conditional statement that is associated to a conditional branch.For example,condition ”greater-than”can be replaced by the con-dition ”less-than-or-equal-to”.
5.C 5–Filling unused instruction fields with bits from the bitstream –in our implementation for the ARM instruction set,we use the software interrupt in-struction (SWI)with appropriate condition codes that ensure that the instruction never causes an interrupt.Each SWI instruction contains 24unused bits that can be set according to the random bitstream.
6.C 6–Toggling the signs of immediate operands to select between addition and subtraction of in-lined constants.The experimental results for the accumulated I-block en-tropy H (I,{C 1...C 4C 6})are summarized in Figure 11.The ordinate in each histogram represents the accumulated DOF for constraint manipulation with all constraint types com-bined.The abscissa for each case shows the number of I-blocks with the respective DOF.The minimal and average achieved entropy across all I-blocks of all benchmark pro-grams is 21and 140bits.Although the average case pro-vides strong security,the cases with small entropy need to be addressed.A trivial transformation that achieves this goal is C 5.Another approach that results in signi?cantly lower overhead,is to perform intra-I-block code perturbation in order to improve the worst case above certain lower bound (e.g.,50bits).Algorithms that perform such optimizations are outside the scope of this paper.
The most viable attack on the system feeds the proces-sor with an I-block which has a small entropy in terms of the considered transformations.In that case,the cardinal-ity of the embedded constraints is small and only few bits from the random bitstream are used.This renders the au-thentication decision unreliable,which makes a brute force attack a possibility.To prevent this type of an attack,both the constraint encoder and veri?er need to detect the case when an I-block with low entropy is encountered.This case is signalled if the sum of successfully enumerated elements in each of the domains is not su?cient (typically,less than 100).Then,the software installer can either:(i )refuse to create the corresponding working-copy or (ii )it can perturb the executable so that the constraint for minimal entropy is satis?ed for all I-blocks or (iii )it can improve the entropy of such I-blocks by adding dead-code which generally results in minor increase in code size and slight decrease in perfor-mance.Correspondingly,when an I-block with low-entropy is executed,the constraint veri?er should refuse to exe-cute this code regardless whether the constraints match.
4.3SPEF –Effect on System Performance
To evaluate the impact of constraint veri?cation on per-formance,we conducted a series of simulations on the AR-Mulator platform [1].The system environment consisted of direct mapped and fully associative data and instruction caches of size 1,2and 4KB.In addition,we assumed the fol-lowing system model:(i )all instructions are executed in one
0100
200300
0100
200300
010*******
010********
100
200300
Cummulative Degrees of Freedom For All Constraint Types
Mpeg Encode
Mpeg Decode
Jpeg Encode
Jpeg Decode
Pegwit
64-I n s t r u c t i o n B l o c k C o u n t
35
685621
22
Figure 11:Accumulated entropy H (I,S )with respect to all considered transformation types –a direct measure of the likelihood that an adversary can create a malicious I-block.For each chart,the achieved minimum arg min ?I
H (I,S )is shown as a vertical dotted line.
clock cycle if there is a cache hit,(ii )on a data cache miss the processor stalls k clock cycles (in our examples k =64cycles for a 64-long I-block),(iii )on an instruction cache miss,the processor stalls k +l cycles where l is the compo-nent representing the delay of the constraint veri?er.This models the fact that when there is an instruction cache miss,a new I-block is fetched from memory and then validated using SPEF’s constraint veri?er.Overhead l has four com-ponents:delay due to domain ordering,TI-hash extraction,random bitstream generation,and veri?cation.Discussion on their hardware implementation can be found in Subsec-tion 4.1,however,detailed descriptions of these components are beyond the scope of this paper.In our implementation,domain ordering and TI-hash extraction consume 33clock cycles in the worst case.Random bitstream generation takes 16clock cycles [21]and veri?cation consumes 1clock cycle.We used the Mediabench suite of benchmark programs as payload to the system [13].Cache performance results for our benchmark applications under di?erent system con?gu-rations are shown in Figure 12.
Augmenting the normal execution cycle with constraint veri?cation increases system’s clock cycles per instruction (CPI)when there is a cache miss.By adding a TI-hash cache,we have been able to reduce the penalty of domain ordering and TI-hash extraction.In our implementation,the number of entries in the TI-hash cache is set to twice the number of entries in the I-cache.That is acceptable since TI-hash entries are much smaller (256-bit payload).As a consequence,in our experiments only 20%of I-cache misses resulted in the recalculation of the domain order and TI-hash.Therefore,the performance overhead was reduced from the range 12.7%-24.7%without,to range 7.5%-17.1%with the TI-hash cache.
The experimental results for di?er-ent cache sizes and organization are shown in Figure 13.
5.RELATED WORK
In this section,we review the related work for code secu-rity.Four major approaches for code security have emerged:code signing,sandboxes,?rewalling,and proof-carrying code.Code signing is conceptually the simplest mobile code secu-rity technique.Code signing follows a typical authenticated handshake protocol such as WTLS [20].Recently,sandbox-ing,as a security paradigm,has attracted a great deal of attention,mainly due to its applicability in Java.Although Java provides a new concept of a protected domain and sev-eral related security primitives,the backbone of its security
23456789101K, FA
1K, DM
2K, FA
2K, DM
4K, FM 4K, DM
Cache size
M i s s r a t e (%)
Figure 12:Cache miss rate for di?erent sizes of
caches with direct mapped and fully associative or-ganization.
architecture is a sandbox [23].Sekar and Uppuluri devel-oped a security layer that includes a sandbox designed to protect the application against malicious users and the host from malicious applications [23].The main idea behind the ?rewalling technique for mobile code security is to conduct comprehensive examination of the provided mobile code at the very point where it enters the consumer domain.Sev-eral variants of the generic approach have emerged,but their e?ectiveness is not often satisfactory [14].Necula [17]has developed the concept of proof-carrying code,a mechanism by which a host system can determine with certainty that it is safe to execute a program provided by an un-trusted source.This is accomplished by requesting that the source provides a safety proof that attests to the code’s adherence to a consumer de?ned safety policy.
6.CONCLUSION
We have developed a system of hardware-software mecha-nisms that prevents execution of unauthorized code in pro-tected (trusted)mode by imposing a computationally in-tractable task to a potential attacker.The key protection mechanism is space and time e?cient checking of blocks of executable code with respect to a set of constraints that facilitate rapid detection of malicious code alternations.Ef-?cient code veri?cation is conducted at run-time by em-bedding the constraints into code through local syntactic changes.The installed software is individualized for each processor and the key to individualization is stored as a
2468
1K, FA
1K, DM
2K, FA
2K, DM 4K, FM 4K, DM
Cache size
E
f f e c t i v e C P I Figure 13:E?ective clock cycles per instruction (CPI)with and without the TI hash (TIH)cache.secret on the protected system.The protection system is transparent with respect to the OS and the applications.The changes to the executable due to individualization are performed as a post-compilation step and fully preserve the functionality of the program.The approach is prototyped and evaluated usin
g the ARM instruction set,a correspond-ing embedded system,and the Mediabenc
h set of embedded benchmark programs.
7.ACKNOWLEDGEMENTS
We would like to gratefully acknowledge the e?orts by Seapahn Megerian in helping us obtain the experimental results.We thank Jim Larus and the anonymous reviewers for discussions that improved the content of the manuscript.
8.REFERENCES
[1]ARM Corp.The ARM hardware-software development
kit.Available online at https://www.wendangku.net/doc/3d15040497.html, .
[2]N.Borisov,I.Goldberg,and D.Wagner.Intercepting
mobile communications:the insecurity of 802.11.MOBICOM ,2001.
[3]S.Chari and P.-C.Cheng.Bluebox:A policy driven,
host-based intrusion detection https://www.wendangku.net/doc/3d15040497.html,work and Distributed System Security ,February 2002.[4]H.Chen,D.Wagner,and D.Dean.Setuid
demysti?https://www.wendangku.net/doc/3d15040497.html,ENIX Security Symposium ,2002.[5]C.Cowan,C.Pu,D.Maier,H.Hinton,J.Walpole,
P.Bakke,S.Beattie,A.Grier,and P.W.Q.Zhang.Stackguard:automatic adaptive detection and prevention of bu?er-over?ow https://www.wendangku.net/doc/3d15040497.html,ENIX Security Symposium ,pages 63–77,Jan.1998.[6]C.Cowan,F.Wagle,P.Calton,S.Beattie,and
J.Walpole.Bu?er over?ows:attacks and defenses for the vulnerability of the decade.DARPA Information Survivability Conference and Exposition.IEEE Computer Soc ,2:95–107,2000.
[7]D.Evans.Static detection of dynamic memory errors.
Programming Language Design and Implementation ,pages 44–53,1996.
[8]D.Evans,J.Guttag,J.Horning,and Y.Tan.LCLint:
A tool for using speci?cations to check code.ACM SIGSOFT Symposium on the Foundations of Software Engineering ,pages 87–96,1994.
[9]I.Goldberg,D.Wagner,R.Thomas,and E.Brewer.A
secure environment for untrusted helper https://www.wendangku.net/doc/3d15040497.html,ENIX Security Symposium ,pages 1–13,July 1996.[10]Intel Corp.Processor Serial Number Technical Notes .
Available on-line at https://www.wendangku.net/doc/3d15040497.html, .[11]S.Johnson.Lint,a C program checker.Unix
Programmer’s Manual,AT&T Bell Laboratories,1978.[12]https://www.wendangku.net/doc/3d15040497.html,rochelle and D.Evans.Statically detecting likely
bu?er over?ow https://www.wendangku.net/doc/3d15040497.html,ENIX Security Symposium ,pages 177–89,Aug.2001.
[13]C.Lee,M.Potkonjak,and W.H.Mangione-Smith.
Mediabench:A tool for evaluating and synthesizing multimedia and communications systems.
International Symposium on Microarchitecture ,330–351,1997.
[14]D.Martin,Jr,S.Rajagopalan,and A.Rubin.
Blocking java applets at the ?https://www.wendangku.net/doc/3d15040497.html,work and Distributed System Security ,pages 16–26,1997.[15]A.Menezes,P.V.Oorschot,and S.Vanstone.
Handbook of Applied Cryptography .CRC Press,Boca Raton,FL,October 1996.
[16]R.Minnich.The Linux BIOS Home Page .Available
on-line at https://www.wendangku.net/doc/3d15040497.html,/linuxbios .[17]G.Necula.Proof-carrying code.Symposium on
Principles of Programming Languages ,pages 106–119,1997.
[18]A.One.Smashing the stack for fun and pro?t.Phrack ,
49,1996.
[19]Phoenix Technologies Ltd.System BIOS for IBM
PCs,Compatibles,and EISA Computers .Addison-Wesley,Reading,MA,1991.
[20]A.Rubin and D.Geer,Jr.Mobile code security.IEEE
Internet Computing ,2(6):30–34,1998.
[21]Sci-Worx GmbH.AES Rijndael core.Available on-line
at https://www.wendangku.net/doc/3d15040497.html, .
[22]D.Seeley.The internet worm,password cracking:a
game of https://www.wendangku.net/doc/3d15040497.html,munications of the ACM ,32(6):700–3,June 1989.
[23]R.Sekar and P.Uppuluri.Synthesizing fast intrusion
prevention/detection systems from high-level
speci?https://www.wendangku.net/doc/3d15040497.html,ENIX Security Symposium ,pages 63–78,1999.
[24]U.Shankar,K.Talwar,J.Foster,and D.Wagner.
Detecting format string vulnerabilities with type quali?ers.pages 201–20,2001.
[25]M.Smith.Support for speculative execution in
high-performance processors.PhD thesis,Stanford University ,1992.
[26]R.Tomasulo.An e?cient algorithm for exploiting
multiple arithmetic units.IBM Journal ,pages 25–33,1967.
[27]D.Wagner,J.Foster,E.Brewer,and A.Aiken.A ?rst
step towards automated detection of bu?er overrun https://www.wendangku.net/doc/3d15040497.html,work and Distributed System Security ,2000.
[28]C.Wilson and L.Osterweil.Omega -a data ?ow
analysis tool for the C programming language.IEEE Trans.on Software Engineering ,11(9):832–8,1985.[29]Zero Knowledge Systems Inc.The Intel Pentium III
Exploit Page .Available on-line at
https://www.wendangku.net/doc/3d15040497.html,/p3/home.asp .
公文写作规范格式
商务公文写作目录 一、商务公文的基本知识 二、应把握的事项与原则 三、常用商务公文写作要点 四、常见错误与问题
一、商务公文的基本知识 1、商务公文的概念与意义 商务公文是商业事务中的公务文书，是企业在生产经营管理活动中产生的，按照严格的、既定的生效程序和规范的格式而制定的具有传递信息和记录作用的载体。规范严谨的商务文书，不仅是贯彻企业执行力的重要保障，而且已经成为现代企业管理的基础中不可或缺的内容。商务公文的水平也是反映企业形象的一个窗口，商务公文的写作能力常成为评价员工职业素质的重要尺度之一。 2、商务公文分类：（1）根据形成和作用的商务活动领域，可分为通用公文和专用公文两类（2）根据内容涉及秘密的程度，可分为对外公开、限国内公开、内部使用、秘密、机密、绝密六类（3）根据行文方向，可分为上行文、下行文、平行文三类（4）根据内容的性质，可分为规范性、指导性、公布性、陈述呈请性、商洽性、证明性公文（5）根据处理时限的要求，可分为平件、急件、特急件三类（6）根据来源，在一个部门内部可分为收文、发文两类。 3、常用商务公文： （1）公务信息：包括通知、通报、通告、会议纪要、会议记录等 （2）上下沟通：包括请示、报告、公函、批复、意见等 （3）建规立矩：包括企业各类管理规章制度、决定、命令、任命等； （4）包容大事小情：包括简报、调查报告、计划、总结、述职报告等； （5）对外宣传：礼仪类应用文、领导演讲稿、邀请函等； （6）财经类：经济合同、委托授权书等； （7）其他：电子邮件、便条、单据类（借条、欠条、领条、收条）等。 考虑到在座的主要岗位，本次讲座涉及请示、报告、函、计划、总结、规章制度的写作，重点谈述职报告的写作。 4、商务公文的特点： （1）制作者是商务组织。（2）具有特定效力，用于处理商务。 （3）具有规范的结构和格式，而不像私人文件靠“约定俗成”的格式。商务公文区别于其它文章的主要特点是具有法定效力与规范格式的文件。 5、商务公文的四个构成要素： （1）意图：主观上要达到的目标 (2）结构：有效划分层次和段落，巧设过渡和照应 (3）材料：组织材料要注意多、细、精、严 (4) 正确使用专业术语、熟语、流行语等词语，适当运用模糊语言、模态词语与古词语。 6、基本文体与结构 商务文体区别于其他文体的特殊属性主要有直接应用性、全面真实性、结构格式的规范性。其特征表现为：被强制性规定采用白话文形式，兼用议论、说明、叙述三种基本表达方法。商务公文的基本组成部分有：标题、正文、作者、日期、印章或签署、主题词。其它组成部分有文头、发文字号、签发人、保密等级、紧急程度、主送机关、附件及其标记、抄送机关、注释、印发说明等。印章或签署均为证实公文作者合法性、真实性及公文效力的标志。 7、稿本 （1）草稿。常有“讨论稿”“征求意见稿”“送审稿”“草稿”“初稿”“二稿”“三稿”等标记。（2）定稿。是制作公文正本的标准依据。有法定的生效标志（签发等）。（3）正本。格式正规并有印章或签署等表明真实性、权威性、有效性。（4）试行本。在试验期间具有正式公文的法定效力。（5）暂行本。在规定
关于会议纪要的规范格式和写作要求
关于会议纪要的规范格式和写作要求 一、会议纪要的概念 会议纪要是一种记载和传达会议基本情况或主要精神、议定事项等内容的规定性公文。是在会议记录的基础上，对会议的主要内容及议定的事项，经过摘要整理的、需要贯彻执行或公布于报刊的具有纪实性和指导性的文件。 会议纪要根据适用范围、内容和作用，分为三种类型： 1、办公会议纪要(也指日常行政工作类会议纪要)，主要用于单位开会讨论研究问题，商定决议事项，安排布置工作，为开展工作提供指导和依据。如，xx学校工作会议纪要、部长办公会议纪要、市委常委会议纪要。 2、专项会议纪要(也指协商交流性会议纪要)，主要用于各类交流会、研讨会、座谈会等会议纪要，目的是听取情况、传递信息、研讨问题、启发工作等。如，xx县脱贫致富工作座谈会议纪要。 3、代表会议纪要(也指程序类会议纪要)。它侧重于记录会议议程和通过的决议，以及今后工作的建议。如《××省第一次盲人聋哑人代表会议纪要》、《xx市第x次代表大会会议纪要》。 另外，还有工作汇报、交流会，部门之间的联席会等方面的纪要，但基本上都系日常工作类的会议纪要。 二、会议纪要的格式 会议纪要通常由标题、正文、结尾三部分构成。
1、标题有三种方式：一是会议名称加纪要，如《全国农村工作会议纪要》;二是召开会议的机关加内容加纪要，也可简化为机关加纪要，如《省经贸委关于企业扭亏会议纪要》、《xx组织部部长办公会议纪要》;三是正副标题相结合，如《维护财政制度加强经济管理——在xx部门xx座谈会上的发言纪要》。 会议纪要应在标题的下方标注成文日期，位置居中，并用括号括起。作为文件下发的会议纪要应在版头部分标注文号，行文单位和成文日期在文末落款(加盖印章)。 2、会议纪要正文一般由两部分组成。 (1)开头，主要指会议概况，包括会议时间、地点、名称、主持人，与会人员，基本议程。 (2)主体，主要指会议的精神和议定事项。常务会、办公会、日常工作例会的纪要，一般包括会议内容、议定事项，有的还可概述议定事项的意义。工作会议、专业会议和座谈会的纪要，往往还要写出经验、做法、今后工作的意见、措施和要求。 (3)结尾，主要是对会议的总结、发言评价和主持人的要求或发出的号召、提出的要求等。一般会议纪要不需要写结束语，主体部分写完就结束。 三、会议纪要的写法 根据会议性质、规模、议题等不同，正文部分大致可以有以下几种写法： 1、集中概述法(综合式)。这种写法是把会议的基本情况，讨
titlesec宏包使用手册
titlesec&titletoc中文文档 张海军编译 makeday1984@https://www.wendangku.net/doc/3d15040497.html, 2009年10月 目录 1简介,1 2titlesec基本功能,2 2.1.格式,2.—2.2.间隔, 3.—2.3.工具,3. 3titlesec用法进阶,3 3.1.标题格式,3.—3.2.标题间距, 4.—3.3.与间隔相关的工具, 5.—3.4.标题 填充,5.—3.5.页面类型,6.—3.6.断行,6. 4titletoc部分,6 4.1.titletoc快速上手,6. 1简介 The titlesec and titletoc宏包是用来改变L A T E X中默认标题和目录样式的，可以提供当前L A T E X中没有的功能。Piet van Oostrum写的fancyhdr宏包、Rowland McDonnell的sectsty宏包以及Peter Wilson的tocloft宏包用法更容易些；如果希望用法简单的朋友，可以考虑使用它们。 要想正确使用titlesec宏包，首先要明白L A T E X中标题的构成，一个完整的标题是由标签+间隔+标题内容构成的。比如： 1.这是一个标题，此标题中 1.就是这个标题的标签，这是一个标签是此标题的内容，它们之间的间距就是间隔了。 1
2titlesec基本功能 改变标题样式最容易的方法就是用几向个命令和一系列选项。如果你感觉用这种方法已经能满足你的需求，就不要读除本节之外的其它章节了1。 2.1格式 格式里用三组选项来控制字体的簇、大小以及对齐方法。没有必要设置每一个选项，因为有些选项已经有默认值了。 rm s f t t md b f up i t s l s c 用来控制字体的族和形状2，默认是bf,详情见表1。 项目意义备注（相当于） rm roman字体\textrm{...} sf sans serif字体\textsf{...} tt typewriter字体\texttt{...} md mdseries(中等粗体)\textmd{...} bf bfseries(粗体)\textbf{...} up直立字体\textup{...} it italic字体\textit{...} sl slanted字体\textsl{...} sc小号大写字母\textsc{...} 表1:字体族、形状选项 bf和md属于控制字体形状，其余均是切换字体族的。 b i g medium s m a l l t i n y（大、中、小、很小） 用来标题字体的大小，默认是big。 1这句话是宏包作者说的，不过我感觉大多情况下，是不能满足需要的，特别是中文排版，英文 可能会好些！ 2L A T E X中的字体有5种属性：编码、族、形状、系列和尺寸。 2
毕业论文写作要求与格式规范
毕业论文写作要求与格式规范 关于《毕业论文写作要求与格式规范》，是我们特意为大家整理的，希望对大家有所帮助。 (一)文体 毕业论文文体类型一般分为：试验论文、专题论文、调查报告、文献综述、个案评述、计算设计等。学生根据自己的实际情况，可以选择适合的文体写作。 (二)文风 符合科研论文写作的基本要求：科学性、创造性、逻辑性、
实用性、可读性、规范性等。写作态度要严肃认真，论证主题应有一定理论或应用价值;立论应科学正确，论据应充实可靠，结构层次应清晰合理，推理论证应逻辑严密。行文应简练，文笔应通顺，文字应朴实，撰写应规范，要求使用科研论文特有的科学语言。 (三)论文结构与排列顺序 毕业论文，一般由封面、独创性声明及版权授权书、摘要、目录、正文、后记、参考文献、附录等部分组成并按前后顺序排列。 1.封面：毕业论文(设计)封面具体要求如下： (1)论文题目应能概括论文的主要内容，切题、简洁，不超过30字，可分两行排列;
(2)层次：大学本科、大学专科 (3)专业名称：机电一体化技术、计算机应用技术、计算机网络技术、数控技术、模具设计与制造、电子信息、电脑艺术设计、会计电算化、商务英语、市场营销、电子商务、生物技术应用、设施农业技术、园林工程技术、中草药栽培技术和畜牧兽医等专业，应按照标准表述填写; (4)日期：毕业论文(设计)完成时间。 2.独创性声明和关于论文使用授权的说明：需要学生本人签字。 3.摘要：论文摘要的字数一般为300字左右。摘要是对论文的内容不加注释和评论的简短陈述，是文章内容的高度概括。主要内容包括：该项研究工作的内容、目的及其重要性;所使用的实验方法;总结研究成果，突出作者的新见解;研究结论及其意义。摘要中不列举例证，不描述研究过程，不做自我评价。
公文格式规范与常见公文写作
公文格式规范与常见公文写作 一、公文概述与公文格式规范 党政机关公文种类的区分、用途的确定及格式规范等，由中共中央办公厅、国务院办公厅于2012年4月16日印发，2012年7月1日施行的《党政机关公文处理工作条例》规定。之前相关条例、办法停止执行。 （一）公文的含义 公文，即公务文书的简称，属应用文。 广义的公文，指党政机关、社会团体、企事业单位，为处理公务按照一定程序而形成的体式完整的文字材料。 狭义的公文，是指在机关、单位之间，以规范体式运行的文字材料，俗称“红头文件”。 ?（二）公文的行文方向和原则 ?、上行文下级机关向上级机关行文。有“请示”、“报告”、和“意见”。 ?、平行文同级机关或不相隶属机关之间行文。主要有“函”、“议案”和“意见”。 ?、下行文上级机关向下级机关行文。主要有“决议”、“决定”、“命令”、“公报”、“公告”、“通告”、“意见”、“通知”、“通报”、“批复”和“会议纪要”等。 ?其中，“意见”、“会议纪要”可上行文、平行文、下行文。?“通报”可下行文和平行文。 ?原则： ?、根据本机关隶属关系和职权范围确定行文关系 ?、一般不得越级行文 ?、同级机关可以联合行文 ?、受双重领导的机关应分清主送机关和抄送机关 ?、党政机关的部门一般不得向下级党政机关行文 ?(三) 公文的种类及用途 ?、决议。适用于会议讨论通过的重大决策事项。 ?、决定。适用于对重要事项作出决策和部署、奖惩有关单位和人员、变更或撤销下级机关不适当的决定事项。
?、命令（令）。适用于公布行政法规和规章、宣布施行重大强制性措施、批准授予和晋升衔级、嘉奖有关单位和人员。 ?、公报。适用于公布重要决定或者重大事项。 ?、公告。适用于向国内外宣布重要事项或者法定事项。 ?、通告。适用于在一定范围内公布应当遵守或者周知的事项。?、意见。适用于对重要问题提出见解和处理办法。 ?、通知。适用于发布、传达要求下级机关执行和有关单位周知或者执行的事项，批转、转发公文。 ?、通报。适用于表彰先进、批评错误、传达重要精神和告知重要情况。 ?、报告。适用于向上级机关汇报工作、反映情况，回复上级机关的询问。 ?、请示。适用于向上级机关请求指示、批准。 ?、批复。适用于答复下级机关请示事项。 ?、议案。适用于各级人民政府按照法律程序向同级人民代表大会或者人民代表大会常务委员会提请审议事项。 ?、函。适用于不相隶属机关之间商洽工作、询问和答复问题、请求批准和答复审批事项。 ?、纪要。适用于记载会议主要情况和议定事项。?（四）、公文的格式规范 ?、眉首的规范 ?（）、份号 ?也称编号，置于公文首页左上角第行，顶格标注。“秘密”以上等级的党政机关公文，应当标注份号。 ?（）、密级和保密期限 ?分“绝密”、“机密”、“秘密”三个等级。标注在份号下方。?（）、紧急程度 ?分为“特急”和“加急”。由公文签发人根据实际需要确定使用与否。标注在密级下方。 ?（）、发文机关标志（或称版头） ?由发文机关全称或规范化简称加“文件”二字组成。套红醒目，位于公文首页正中居上位置（按《党政机关公文格式》标准排
ctex 宏包说明 ctex
ctex宏包说明 https://www.wendangku.net/doc/3d15040497.html,? 版本号：v1.02c修改日期：2011/03/11 摘要 ctex宏包提供了一个统一的中文L A T E X文档框架，底层支持CCT、CJK和xeCJK 三种中文L A T E X系统。ctex宏包提供了编写中文L A T E X文档常用的一些宏定义和命令。 ctex宏包需要CCT系统或者CJK宏包或者xeCJK宏包的支持。主要文件包括ctexart.cls、ctexrep.cls、ctexbook.cls和ctex.sty、ctexcap.sty。 ctex宏包由https://www.wendangku.net/doc/3d15040497.html,制作并负责维护。 目录 1简介2 2使用帮助3 2.1使用CJK或xeCJK (3) 2.2使用CCT (3) 2.3选项 (4) 2.3.1只能用于文档类的选项 (4) 2.3.2只能用于文档类和ctexcap.sty的选项 (4) 2.3.3中文编码选项 (4) 2.3.4中文字库选项 (5) 2.3.5CCT引擎选项 (5) 2.3.6排版风格选项 (5) 2.3.7宏包兼容选项 (6) 2.3.8缺省选项 (6) 2.4基本命令 (6) 2.4.1字体设置 (6) 2.4.2字号、字距、字宽和缩进 (7) ?https://www.wendangku.net/doc/3d15040497.html, 1
1简介2 2.4.3中文数字转换 (7) 2.5高级设置 (8) 2.5.1章节标题设置 (9) 2.5.2部分修改标题格式 (12) 2.5.3附录标题设置 (12) 2.5.4其他标题设置 (13) 2.5.5其他设置 (13) 2.6配置文件 (14) 3版本更新15 4开发人员17 1简介 这个宏包的部分原始代码来自于由王磊编写cjkbook.cls文档类，还有一小部分原始代码来自于吴凌云编写的GB.cap文件。原来的这些工作都是零零碎碎编写的，没有认真、系统的设计，也没有用户文档，非常不利于维护和改进。2003年，吴凌云用doc和docstrip工具重新编写了整个文档，并增加了许多新的功能。2007年，oseen和王越在ctex宏包基础上增加了对UTF-8编码的支持，开发出了ctexutf8宏包。2009年5月，我们在Google Code建立了ctex-kit项目1，对ctex宏包及相关宏包和脚本进行了整合，并加入了对XeT E X的支持。该项目由https://www.wendangku.net/doc/3d15040497.html,社区的开发者共同维护，新版本号为v0.9。在开发新版本时，考虑到合作开发和调试的方便，我们不再使用doc和docstrip工具，改为直接编写宏包文件。 最初Knuth设计开发T E X的时候没有考虑到支持多国语言，特别是多字节的中日韩语言。这使得T E X以至后来的L A T E X对中文的支持一直不是很好。即使在CJK解决了中文字符处理的问题以后，中文用户使用L A T E X仍然要面对许多困难。最常见的就是中文化的标题。由于中文习惯和西方语言的不同，使得很难直接使用原有的标题结构来表示中文标题。因此需要对标准L A T E X宏包做较大的修改。此外，还有诸如中文字号的对应关系等等。ctex宏包正是尝试着解决这些问题。中间很多地方用到了在https://www.wendangku.net/doc/3d15040497.html,论坛上的讨论结果，在此对参与讨论的朋友们表示感谢。 ctex宏包由五个主要文件构成：ctexart.cls、ctexrep.cls、ctexbook.cls和ctex.sty、ctexcap.sty。ctex.sty主要是提供整合的中文环境，可以配合大多数文档类使用。而ctexcap.sty则是在ctex.sty的基础上对L A T E X的三个标准文档类的格式进行修改以符合中文习惯，该宏包只能配合这三个标准文档类使用。ctexart.cls、ctexrep.cls、ctexbook.cls则是ctex.sty、ctexcap.sty分别和三个标准文档类结合产生的新文档类，除了包含ctex.sty、ctexcap.sty的所有功能，还加入了一些修改文档类缺省设置的内容（如使用五号字体为缺省字体）。 1https://www.wendangku.net/doc/3d15040497.html,/p/ctex-kit/
文档书写格式规范要求
学生会文档书写格式规范要求 目前各部门在日常文书编撰中大多按照个人习惯进行排版，文档中字体、文字大小、行间距、段落编号、页边距、落款等参数设置不规范，严重影响到文书的标准性和美观性，以下是文书标准格式要求及日常文档书写注意事项，请各部门在今后工作中严格实行： 一、文件要求 1.文字类采用Word格式排版 2.统计表、一览表等表格统一用Excel格式排版 3.打印材料用纸一般采用国际标准A4型（210mm×297mm），左侧装订。版面方向以纵向为主，横向为辅，可根据实际需要确定 4.各部门的职责、制度、申请、请示等应一事一报，禁止一份行文内同时表述两件工作。 5.各类材料标题应规范书写，明确文件主要内容。 二、文件格式 （一）标题 1.文件标题：标题应由发文机关、发文事由、公文种类三部分组成，黑体小二号字,不加粗，居中，段后空1行。 （二）正文格式 1. 正文字体：四号宋体，在文档中插入表格，单元格内字体用宋体，字号可根据内容自行设定。 2.页边距：上下边距为2.54厘米；左右边距为 3.18厘米。
3.页眉、页脚：页眉为1.5厘米；页脚为1.75厘米； 4.行间距：1.5倍行距。 5.每段前的空格请不要使用空格，应该设置首先缩进2字符 6.年月日表示：全部采用阿拉伯数字表示。 7.文字从左至右横写。 （三）层次序号 (1)一级标题：一、二、三、 (2)二级标题：（一）（二）（三） (3)三级标题：1. 2. 3. (4)四级标题：（1）（2）（3） 注：三个级别的标题所用分隔符号不同，一级标题用顿号“、”例如：一、二、等。二级标题用括号不加顿号，例如：（三）（四）等。三级标题用字符圆点“.”例如：5. 6.等。 （四）、关于落款： 1.对外行文必须落款“湖南环境生物专业技术学院学生会”“校学生会”各部门不得随意使用。 2.各部门文件落款需注明组织名称及部门“湖南环境生物专业技术学院学生会XX部”“校学生会XX部” 3.所有行文落款不得出现“环境生物学院”“湘环学院”“学生会”等表述不全的简称。 4.落款填写至文档末尾右对齐，与前一段间隔2行 5.时间落款：文档中落款时间应以“2016年5月12日”阿拉伯数字
政府公文写作格式规范
政府公文写作格式 一、眉首部分 （一）发文机关标识 平行文和下行文的文件头，发文机关标识上边缘至上页边为62mm，发文机关下边缘至红色反线为28mm。 上行文中，发文机关标识上边缘至版心上边缘为80mm，即与上页边距离为117mm，发文机关下边缘至红色反线为30mm。 发文机关标识使用字体为方正小标宋_GBK，字号不大于22mm×15mm。 （二）份数序号 用阿拉伯数字顶格标识在版心左上角第一行，不能少于2位数。标识为“编号000001” （三）秘密等级和保密期限 用3号黑体字顶格标识在版心右上角第一行，两字中间空一字。如需要加保密期限的，密级与期限间用“★”隔开，密级中则不空字。 （四）紧急程度 用3号黑体字顶格标识在版心右上角第一行，两字中间空一字。如同时标识密级，则标识在右上角第二行。 （五）发文字号 标识在发文机关标识下两行，用3号方正仿宋_GBK字体剧
中排布。年份、序号用阿拉伯数字标识，年份用全称，用六角括号“〔〕”括入。序号不用虚位，不用“第”。发文字号距离红色反线4mm。 （六）签发人 上行文需要标识签发人，平行排列于发文字号右侧，发文字号居左空一字，签发人居右空一字。“签发人”用3号方正仿宋_GBK，后标全角冒号，冒号后用3号方正楷体_GBK标识签发人姓名。多个签发人的，主办单位签发人置于第一行，其他从第二行起排在主办单位签发人下，下移红色反线，最后一个签发人与发文字号在同一行。 二、主体部分 （一）标题 由“发文机关+事由+文种”组成，标识在红色反线下空两行，用2号方正小标宋_GBK，可一行或多行居中排布。 （二）主送机关 在标题下空一行，用3号方正仿宋_GBK字体顶格标识。回行是顶格，最后一个主送机关后面用全角冒号。 （三）正文 主送机关后一行开始，每段段首空两字，回行顶格。公文中的数字、年份用阿拉伯数字，不能回行，阿拉伯数字：用3号Times New Roman。正文用3号方正仿宋_GBK，小标题按照如下排版要求进行排版：
tabularx宏包中改变弹性列的宽度
tabularx宏包中改变弹性列的宽度\hsize 分类：latex 2012-03-07 21:54 12人阅读评论(0) 收藏编辑删除 \documentclass{article} \usepackage{amsmath} \usepackage{amssymb} \usepackage{latexsym} \usepackage{CJK} \usepackage{tabularx} \usepackage{array} \newcommand{\PreserveBackslash}[1]{\let \temp =\\#1 \let \\ = \temp} \newcolumntype{C}[1]{>{\PreserveBackslash\centering}p{#1}} \newcolumntype{R}[1]{>{\PreserveBackslash\raggedleft}p{#1}} \newcolumntype{L}[1]{>{\PreserveBackslash\raggedright}p{#1}} \begin{document} \begin{CJK*}{GBK}{song} \CJKtilde \begin{tabularx}{10.5cm}{|p{3cm} |>{\setlength{\hsize}{.5\hsize}\centering}X |>{\setlength{\hsize}{1.5\hsize}}X|} %\hsize是自动计算的列宽度，上面{.5\hsize}与{1.5\hsize}中的\hsize前的数字加起来必须等于表格的弹性列数量。对于本例，弹性列有2列，所以“.5+1.5=2”正确。 %共3列，总列宽为10.5cm。第1列列宽为3cm，第3列的列宽是第2列列宽的3倍，其宽度自动计算。第2列文字左右居中对齐。注意：\multicolum命令不能跨越X列。 \hline 聪明的鱼儿在咬钩前常常排祠再三& 这是因为它们要荆断食物是否安全&知果它们认为有危险\\ \hline 它们枕不会吃& 如果它们判定没有危险& 它们就食吞钩\\ \hline 一眼识破诱饵的危险，却又不由自主地去吞钩的& 那才正是人的心理而不是鱼的心理& 是人的愚合而不是鱼的恳奋\\
2-1论文写作要求与格式规范(2009年修订)
广州中医药大学研究生学位论文基本要求与写作规范 为了进一步提高学位工作水平和学位论文质量，保证我校学位论文在结构和格式上的规范与统一，特做如下规定： 一、学位论文基本要求 （一）科学学位硕士论文要求 1.论文的基本科学论点、结论，应在中医药学术上和中医药科学技术上具有一定的理论意义和实践价值。 2.论文所涉及的内容，应反映出作者具有坚实的基础理论和系统的专门知识。 3.实验设计和方法比较先进，并能掌握本研究课题的研究方法和技能。 4.对所研究的课题有新的见解。 5.在导师指导下研究生独立完成。 6.论文字数一般不少于3万字，中、英文摘要1000字左右。 （二）临床专业学位硕士论文要求 临床医学硕士专业学位申请者在临床科研能力训练中学会文献检索、收集资料、数据处理等科学研究的基本方法,培养临床思维能力与分析能力,完成学位论文。 1.学位论文包括病例分析报告及文献综述。 2.学位论文应紧密结合中医临床或中西结合临床实际，以总结临床实践经验为主。 3.学位论文应表明申请人已经掌握临床科学研究的基本方法。 4.论文字数一般不少于15000字，中、英文摘要1000字左右。 （三）科学学位博士论文要求 1.研究的课题应在中医药学术上具有较大的理论意义和实践价值。 2.论文所涉及的内容应反映作者具有坚实宽广的理论基础和系统深入的专门知识，并表明作者具有独立从事科学研究工作的能力。 3.实验设计和方法在国内同类研究中属先进水平，并能独立掌握本研究课题的研究方法和技能。
4.对本研究课题有创造性见解，并取得显著的科研成果。 5.学位论文必须是作者本人独立完成，与他人合作的只能提出本人完成的部分。 6.论文字数不少于5万字，中、英摘要3000字；详细中文摘要(单行本)1万字左右。 （四）临床专业学位博士论文要求 1.要求论文课题紧密结合中医临床或中西结合临床实际，研究结果对临床工作具有一定的应用价值。 2.论文表明研究生具有运用所学知识解决临床实际问题和从事临床科学研究的能力。 3.论文字数一般不少于3万字，中、英文摘要2000字；详细中文摘要(单行本)5000字左右。 二、学位论文的格式要求 （一）学位论文的组成 博士、硕士学位论文一般应由以下几部分组成，依次为：1.论文封面；2. 原创性声明及关于学位论文使用授权的声明；3.中文摘要；4.英文摘要；5.目录； 6.引言； 7.论文正文； 8.结语； 9.参考文献；10.附录；11.致谢。 1.论文封面：采用研究生处统一设计的封面。论文题目应以恰当、简明、引人注目的词语概括论文中最主要的内容。避免使用不常见的缩略词、缩写字，题名一般不超过30个汉字。论文封面“指导教师”栏只写入学当年招生简章注明、经正式遴选的指导教师1人，协助导师名字不得出现在论文封面。 2．原创性声明及关于学位论文使用授权的声明（后附）。 3.中文摘要：要说明研究工作目的、方法、成果和结论。并写出论文关键词3～5个。 4.英文摘要：应有题目、专业名称、研究生姓名和指导教师姓名，内容与中文提要一致，语句要通顺，语法正确。并列出与中文对应的论文关键词3～5个。 5.目录：将论文各组成部分(1～3级)标题依次列出，标题应简明扼要，逐项标明页码，目录各级标题对齐排。 6.引言：在论文正文之前，简要说明研究工作的目的、范围、相关领域前人所做的工作和研究空白，本研究理论基础、研究方法、预期结果和意义。应言简
公文写作毕业论文写作要求和格式规范
（公文写作）毕业论文写作要求和格式规范
中国农业大学继续教育学院 毕业论文写作要求和格式规范 壹、写作要求 （壹）文体 毕业论文文体类型壹般分为：试验论文、专题论文、调查方案、文献综述、个案评述、计算设计等。学生根据自己的实际情况，能够选择适合的文体写作。 （二）文风 符合科研论文写作的基本要求：科学性、创造性、逻辑性、实用性、可读性、规范性等。写作态度要严肃认真，论证主题应有壹定理论或应用价值；立论应科学正确，论据应充实可靠，结构层次应清晰合理，推理论证应逻辑严密。行文应简练，文笔应通顺，文字应朴实，撰写应规范，要求使用科研论文特有的科学语言。 （三）论文结构和排列顺序 毕业论文，壹般由封面、独创性声明及版权授权书、摘要、目录、正文、后记、参考文献、附录等部分组成且按前后顺序排列。 1．封面：毕业论文（设计）封面（见文件5）具体要求如下： （1）论文题目应能概括论文的主要内容，切题、简洁，不超过30字，可分俩行排列； （2）层次：高起本，专升本，高起专； （3）专业名称：现开设园林、农林经济管理、会计学、工商管理等专业，应按照标准表述填写； （4）密级：涉密论文注明相应保密年限； （5）日期：毕业论文完成时间。 2．独创性声明和关于论文使用授权的说明：（略）。
3．摘要：论文摘要的字数壹般为300字左右。摘要是对论文的内容不加注释和评论的简短陈述，是文章内容的高度概括。主要内容包括：该项研究工作的内容、目的及其重要性；所使用的实验方法；总结研究成果，突出作者的新见解；研究结论及其意义。摘要中不列举例证，不描述研究过程，不做自我评价。 论文摘要后另起壹行注明本文的关键词，关键词是供检索用的主题词条，应采用能够覆盖论文内容的通用专业术语，符合学科分类，壹般为3～5个，按照词条的外延层次从大到小排列。 4．目录（目录示例见附件3）：独立成页，包括论文中的壹级、二级标题、后记、参考文献、和附录以及各项所于的页码。 5．正文：包括前言、论文主体和结论 前言：为正文第壹部分内容，简单介绍本项研究的背景和国内外研究成果、研究现状，明确研究目的、意义以及要解决的问题。 论文主体：是全文的核心部分，于正文中应将调查、研究中所得的材料和数据加工整理和分析研究，提出论点，突出创新。内容可根据学科特点和研究内容的性质而不同。壹般包括：理论分析、计算方法、实验装置和测试方法、对实验结果或调研结果的分析和讨论，本研究方法和已有研究方法的比较等方面。内容要求论点正确，推理严谨，数据可靠，文字精炼，条理分明，重点突出。 结论：为正文最后壹部分，是对主要成果的归纳和总结，要突出创新点，且以简练的文字对所做的主要工作进行评价。 6．后记：对整个毕业论文工作进行简单的回顾总结，对给予毕业论文工作提供帮助的组织或个人表示感谢。内容应尽量简单明了，壹般为200字左右。 7．参考文献：是论文不可或缺的组成部分。它既可反映毕业论文工作中取材广博程度，又可反映文稿的科学依据和作者尊重他人研究成果的严肃态度，仍能够向读者提供有关
配合前面的ntheorem宏包产生各种定理结构
%=== 配合前面的ntheorem宏包产生各种定理结构,重定义一些正文相关标题===% \theoremstyle{plain} \theoremheaderfont{\normalfont\rmfamily\CJKfamily{hei}} \theorembodyfont{\normalfont\rm\CJKfamily{song}} \theoremindent0em \theoremseparator{\hspace{1em}} \theoremnumbering{arabic} %\theoremsymbol{} %定理结束时自动添加的标志 \newtheorem{definition}{\hspace{2em}定义}[chapter] %\newtheorem{definition}{\hei 定义}[section] %!!!注意当section为中国数字时，[sction]不可用！ \newtheorem{proposition}{\hspace{2em}命题}[chapter] \newtheorem{property}{\hspace{2em}性质}[chapter] \newtheorem{lemma}{\hspace{2em}引理}[chapter] %\newtheorem{lemma}[definition]{引理} \newtheorem{theorem}{\hspace{2em}定理}[chapter] \newtheorem{axiom}{\hspace{2em}公理}[chapter] \newtheorem{corollary}{\hspace{2em}推论}[chapter] \newtheorem{exercise}{\hspace{2em}习题}[chapter] \theoremsymbol{$\blacksquare$} \newtheorem{example}{\hspace{2em}例}[chapter] \theoremstyle{nonumberplain} \theoremheaderfont{\CJKfamily{hei}\rmfamily} \theorembodyfont{\normalfont \rm \CJKfamily{song}} \theoremindent0em \theoremseparator{\hspace{1em}} \theoremsymbol{$\blacksquare$} \newtheorem{proof}{\hspace{2em}证明} \usepackage{amsmath}%数学 \usepackage[amsmath,thmmarks,hyperref]{ntheorem} \theoremstyle{break} \newtheorem{example}{Example}[section]
论文写作格式规范与要求(完整资料).doc
【最新整理，下载后即可编辑】 广东工业大学成人高等教育 本科生毕业论文格式规范（摘录整理） 一、毕业论文完成后应提交的资料 最终提交的毕业论文资料应由以下部分构成： （一）毕业论文任务书（一式两份，与论文正稿装订在一起）（二）毕业论文考核评议表（一式三份，学生填写表头后发电子版给老师） （三）毕业论文答辩记录（一份, 学生填写表头后打印出来，答辩时使用） （四）毕业论文正稿（一式两份，与论文任务书装订在一起），包括以下内容： 1、封面 2、论文任务书 3、中、英文摘要（先中文摘要，后英文摘要，分开两页排版） 4、目录 5、正文（包括：绪论、正文主体、结论） 6、参考文献 7、致谢 8、附录（如果有的话） （五）论文任务书和论文正稿的光盘
二、毕业论文资料的填写与装订 毕业论文须用计算机打印，一律使用A4打印纸，单面打印。 毕业论文任务书、毕业论文考核评议表、毕业论文正稿、答辩纪录纸须用计算机打印，一律使用A4打印纸。答辩提问记录一律用黑色或蓝黑色墨水手写，要求字体工整，卷面整洁；任务书由指导教师填写并签字，经主管院领导签字后发出。 毕业论文使用统一的封面，资料装订顺序为：毕业论文封面、论文任务书、考核评议表、答辩记录、中文摘要、英文摘要、目录、正文、参考文献、致谢、附录（如果有的话）。论文封面要求用A3纸包边。 三、毕业论文撰写的内容与要求 一份完整的毕业论文正稿应包括以下几个方面： （一）封面（见封面模版） （二）论文题目（填写在封面上，题目使用2号隶书，写作格式见封面模版） 题目应简短、明确，主标题不宜超过20字；可以设副标题。（三）论文摘要（写作格式要求见《摘要、绪论、结论、参考文献写作式样》P1～P2） 1、中文“摘要”字体居中，独占一页
Groff 应用
使用Groff 生成独立于设备的文档开始之前 了解本教程中包含的内容和如何最好地利用本教程，以及在使用本教程的过程中您需要完成的工作。 关于本教程 本教程提供了使用Groff(GNU Troff)文档准备系统的简介。其中介绍了这个系统的工作原理、如何使用Groff命令语言为其编写输入、以及如何从该输入生成各种格式的独立于设备的排版文档。 本教程所涉及的主题包括： 文档准备过程 输入文件格式 语言语法 基本的格式化操作 生成输出 目标 本教程的主要目标是介绍Groff，一种用于文档准备的开放源码系统。如果您需要在应用程序中构建文档或帮助文件、或为客户和内部使用生成任何类型的打印或屏幕文档(如订单列表、故障单、收据或报表)，那么本教程将向您介绍如何开始使用Groff以实现这些任务。 在学习了本教程之后，您应该完全了解Groff的基本知识，包括如何编写和处理基本的Groff输入文件、以及如何从这些文件生成各种输出。
先决条件 本教程的目标读者是入门级到中级水平的UNIX?开发人员和管理员。您应 该对使用UNIX命令行Shell和文本编辑器有基本的了解。 系统要求 要运行本教程中的示例，您需要访问运行UNIX操作系统并安装了下面这些软件的计算机(请参见本教程的参考资料部分以获取相关链接)： Groff。Groff分发版中包括groff前端工具、troff后端排版引擎和本教 程中使用的各种附属工具。 自由软件基金会将Groff作为其GNU Project中的一部分进行了发布，所 发布的源代码符合GNU通用公共许可证(GPL)并得到了广泛的移植，几乎对于所有的UNIX操作系统、以及非UNIX操作系统(如Microsoft?Windows?)都有相应 的可用版本。 在撰写本教程时，最新的Groff发布版是Version 1.19.2，对于学习本教 程而言，您至少需要Groff Version 1.17。 gxditview。从Version 1.19.2开始，Groff中包含了这个工具，而在以 前的版本中，对其进行了单独的发布。 PostScript Previewer，如ghostview、gv或showpage。 如果您是从源代码安装Groff，那么请参考Groff源代码分发版中的自述 文件，其中列举了所需的任何额外的软件，而在编译和安装Groff时可能需要 使用这些软件。 介绍Groff 用户通常在字处理软件、桌面发布套件和文本布局应用程序等应用程序环 境中创建文档，而在这些环境中，最终将对文档进行打印或导出为另一种格式。整个文档准备过程，从创建到最后的输出，都发生在单个应用程序中。文档通
TeX 使用指南(常见问题)
TeX 使用指南 常见问题（一） 1.\makeatletter 和\makeatother 的用法？ 答：如果需要借助于内部有\@字符的命令，如\@addtoreset，就需要借助于另两个命令 \makeatletter, \makeatother。 下面给出使用范例，用它可以实现公式编号与节号的关联。 \begin{verbatim} \documentclass{article} ... \makeatletter % '@' is now a normal "letter" for TeX \renewcommand\theequation{\thesection.\arabic{equation}} \@addtoreset{equation}{section} \makeatother % '@' is restored as a "non-letter" character for TeX \begin{document} ... \end{verbatim} 2.比较一下CCT与CJK的优缺点？ 答：根据王磊的经验，CJK 比CCT 的优越之处有以下几点： 1）字体定义采用LaTeX NFSS 标准，生成的DVI 文件不必像CCT 那样需要用patchdvi 处理后才能预览和打印。而且一般GB 编码的文件也不必进行预处理就可直接用latex 编译。2）可使用多种TrueType 字体和Type1 字体，生成的PDF 文件更清楚、漂亮。 3）能同时在文章中使用多种编码的文字，如中文简体、繁体、日文、韩文等。 当然，CCT 在一些细节上，如字体可用中文字号，字距、段首缩进等。毕竟CJK 是老外作的吗。 谈到MikTeX 和fpTeX, 应该说谈不上谁好谁坏，主要看个人的喜好了。MikTeX 比较小，不如fpTeX 里提供的TeX 工具，宏包全，但一般的情况也足够了。而且Yap 比windvi 要好用。fpTeX 是teTeX 的Windows 实现，可以说各种TeX 的有关软件基本上都包括在内。 3.中文套装中如何加入新的.cls文件？ 答：放在tex文件的同一目录下，或者miktex/localtexmf/tex/latex/下的某个子目录下，可以自己建一个。 4.怎样象第几章一样，将参考文献也加到目录？ 答：在参考文献部分加入 \addcontentsline{toc}{chapter}{参考文献}
论文的写作格式及规范
论文的写作格式及规范
附件9： 科学技术论文的写作格式及规范 用非公知公用的缩写词、字符、代号，尽量不出现数学式和化学式。 2作者署名和工作单位标引和检索，根据国家有关标准、数据规范为了提高技师、高级技师论文的学术质量，实现论文写的科学化、程序化和规范化，以利于科技信息的传递和科技情报的作评定工作，特制定本技术论文的写作格式及规范。望各位学员在注重科学研究的同时，做好科技论文撰写规范化工作。 1 题名 题名应以简明、确切的词语反映文章中最重要的特定内容，要符合编制题录、索引和检索的有关原则，并有助于选定关键词。 中文题名一般不宜超过20 个字，必要时可加副题名。英文题名应与中文题名含义一致。 题名应避免使作者署名是文责自负和拥有著作权的标志。作者姓名署于题名下方，团体作者的执笔人也可标注于篇首页地脚或文末，简讯等短文的作者可标注于文末。 英文摘要中的中国人名和地名应采用《中国人名汉语拼音字母拼写法》的有关规定；人名姓前名后分写，姓、名的首字母大写，名字中间不加连字符；地名中的专名和通名分写，每分写部分的首字母大写。 作者应标明其工作单位全称、省及城市名、邮编( 如“齐齐哈尔电业局黑龙江省齐齐哈尔市(161000) ”)，同时，在篇首页地脚标注第一作者的作者简介，内容包括姓名，姓别，出生年月，学位，职称，研究成果及方向。
3摘要 论文都应有摘要（3000 字以下的文章可以略去）。摘要的：写作应符合GB6447-86的规定。摘要的内容包括研究的目的、方法、结果和结论。一般应写成报道性文摘，也可以写成指示性或报道-指示性文摘。摘要应具有独立性和自明性，应是一篇完整的短文。一般不分段，不用图表和非公知公用的符号或术语，不得引用图、表、公式和参考文献的序号。中文摘要的篇幅：报道性的300字左右，指示性的100 字左右，报道指示性的200字左右。英文摘要一般与中文摘要内容相对应。 4关键词 关键词是为了便于作文献索引和检索而选取的能反映论文主题概念的词或词组，一般每篇文章标注3?8个。关键词应尽量从《汉语主题词表》等词表中选用规范词——叙词。未被词表收录的新学科、新技术中的重要术语和地区、人物、文献、产品及重要数据名称，也可作为关键词标出。中、英文关键词应一一对应。 5引言 引言的内容可包括研究的目的、意义、主要方法、范围和背景等。 应开门见山，言简意赅，不要与摘要雷同或成为摘要的注释，避免公式推导和一般性的方法介绍。引言的序号可以不写，也可以写为“ 0”，不写序号时“引言”二字可以省略。 6论文的正文部分 论文的正文部分系指引言之后，结论之前的部分，是论文的核心， 应按GB7713--87 的规定格式编写。 6.1层次标题
- 论文的写作格式及规范
- 英语专业论文写作要求与格式规范
- 公司文件书写格式规范
- 关于会议纪要的规范格式和写作要求
- 公文写作毕业论文写作要求和格式规范
- 论文写作格式规范与要求
- 山东农业大学毕业论文写作要求与格式规范-推荐下载
- 公文格式规范与常见公文写作
- 论文写作标准格式
- 2-1论文写作要求与格式规范(2009年修订)
- 论文写作标准格式
- 公文写作规范格式
- 2-1论文写作要求与格式规范(2009年修订)
- 调研报告字体格式要求 调研报告的写作要求及格式规范 精品
- 小学数学作业书写要求及格式规范
- 毕业论文写作要求与格式规范
- 论文写作格式规范与要求(完整资料).doc
- 英语论文格式及写作规范
- 论文写作格式规范与要求
- 政府公文写作格式规范