What occurs on a computer when data goes beyond the limits of a buffer select one a buffer overflow cross

(Arithmetic) Integer Overflows

An integer overflow occurs when you attempt to store inside an integer variable a value that is larger than the maximum value the variable can hold. The C standard defines this situation as undefined behavior (meaning that anything might happen). In practice, this usually translates to a wrap of the value if an unsigned integer was used and a change of the sign and value if a signed integer was used.

Integer overflows are the consequence of “wild” increments/multiplications, generally due to a lack of validation of the variables involved. As an example, take a look at the following code (taken from a vulnerable path that affected the OpenSolaris kernel;6 the code is condensed here to improve readability):

static int64_t

kaioc(long a0, long a1, long a2, long a3, long a4, long a5)

{

[…]

 switch ((int)a0 & ~AIO_POLL_BIT) {

[…]

 case AIOSUSPEND:

 error = aiosuspend((void *)a1, (int)a2, (timespec_t *)a3, [1]

 (int)a4, &rval, AIO_64);

 break;

[…]

/*ARGSUSED*/

static int

aiosuspend(void *aiocb, int nent, struct timespec *timout, int flag, long *rval, int run_mode)

{

[…]

 size_t ssize;

[…]

 aiop = curproc->p_aio;

 if (aiop == NULL || nent <= 0) [2]

 return (EINVAL);

 if (model == DATAMODEL_NATIVE)

 ssize = (sizeof (aiocb_t *) * nent);

 else

 ssize = (sizeof (caddr32_t) * nent); [3]

[…]

 cbplist = kmem_alloc(ssize, KM_NOSLEEP) [4]

 if (cbplist == NULL)

 return (ENOMEM);

 if (copyin(aiocb, cbplist, ssize)) {

 error = EFAULT;

 goto done;

 }

[…]

 if (aiop->aio_doneq) {

 if (model == DATAMODEL_NATIVE)

 ucbp = (aiocb_t **)cbplist;

 else

 ucbp32 = (caddr32_t *)cbplist;

[…]

 for (i = 0; i < nent; i++) { [5]

 if (model == DATAMODEL_NATIVE) {

 if ((cbp = *ucbp++) == NULL)

In the preceding code, kaioc() is a system call of the OpenSolaris kernel that a user can call without any specific privileges to manage asynchronous I/O. If the command passed to the system call (as the first parameter, a0) is AIOSUSPEND [1], the aiosuspend() function is called, passing as parameters the other parameters passed to kaioc(). At [2] the nent variable is not sanitized enough; in fact, any value above 0x3FFFFFFF (which is still a positive value that passes the check at [2]), once used in the multiplication at [3], will make ssize (declared as a size_t, so either 32 bits or 64 bits wide, depending on the model) overflow and, therefore, wrap. Note that this will happen only on 32-bit systems since nent is explicitly a 32-bit value (it is obviously impossible to overflow a 64-bit positive integer by multiplying a small number, as, for example, at [3], by the highest positive 32-bit integer). Seeing this in code form might be helpful; the following is a 32-bit scenario:

0x3FFFFFFF∗4=0xFFFFFFFC[fits in size__t]0x400000000∗4=0x100000000[does not fit in size_t and will result to 0]

In the preceding code, the integer value is cropped, which translates to a loss of information (the discarded bits). ssize is then used at [4] as a parameter to kmem_alloc(). As a result, much less space is allocated than what the nent variable initially dictated.

This is a typical scenario in integer overflow issues and it usually leads to other vulnerabilities, such as heap overflows, if later in the code the original value is used as a loop guard to populate the (now too small) allocated space. An example of this can be seen at [5], even if in this snippet of code nothing is written to the buffer and “only” memory outside it is referenced. Notwithstanding this, this is a very good example of the type of code path you should hunt for in case of an integer overflow.

Vulnerability details

This OpenSSH vulnerability is a perfect example of an integer overflow vulnerability. The vulnerability is caused by the following snippet of code:

1 nresp = packet_get_int( ) ;

2 if(nresp > 0) {

3 response - xraalloc (nresp * sizeof(char*});

4 for(i = 0 ;i < nresp;i + +) {

5 response[i]- packet_get_string(NULL);

6 }

7 }

An attacker has the ability to change the value of nresp (line 1) by modifying the code in the OpenSSH client. By modifying this value, one can change the amount of memory allocated by xmalloc (line 3). Specifying a large number for nresp, such as 0x40000400, prompts an integer overflow, causing xmalloc to allocate only 4096 bytes of memory. OpenSSH then proceeds to place values into the allocated pointer array (lines 4 through 6), dictated by the value of nresp (line 4), causing heap space to be overwritten with arbitrary data.

Memory errors

Memory errors usually derive from the exploitation of vulnerabilities (depicted as holes in a wall in Figure 21.1) existing in a given application due to software faults introduced during the software’s implementation. The most common software faults leading to memory errors are off-by-one, integer, and buffer overflow.

Off-by-one vulnerabilities [16] write one byte outside the bounds of allocated memory. They are often related to iterative loops iterating one time too many or common string functions incorrectly terminating strings. For instance, the bug reported by Frank Bussed [17] in the libpng library allowed remote attackers to cause an application crash via a crafted PNG image that triggered an out-of-bounds read during the copy of an error-message data.

Integer vulnerabilities [18] are usually caused by an integer exceeding its maximum or minimum boundary value. They can be used to bypass size checks or cause buffers to be allocated a size too small to contain the data copied into them. A recent bug discovered on the libpng library did not properly handle certain malformed PNG images [19]. It allowed remote attackers to overwrite memory with an arbitrary amount of data and possibly have other unspecified impact, via a crafted PNG image. Vendors affected included Apple, Debian GNU/Linux, Fedora, Gentoo, Google, Novell, Ubuntu, and SUSE.

Buffer overflows [20] are caused by overrunning the buffer’s boundary while writing data into a buffer. This allows attackers to overwrite data that controls the program execution path and hijack the program to execute the attacker’s code instead of the process code. A recent stack-based buffer overflow example involved the cbtls_verify function in FreeRADIUS, causing server crashes and possibly executing arbitrary code via a long “not after” timestamp in a client certificate [21].

Over the past decade, different techniques have been developed to prevent attacks from successfully exploiting these vulnerabilities, thus reducing their chance of causing memory errors.

Buffer Overflows

Despite being well known, buffer overflows are still one of the most common types of software vulnerabilities. Year after year, buffer overflows are discovered in well-known, widely used software, allowing attackers and worms to compromise hundreds of thousands of machines.

Buffer overflow vulnerabilities typically arise when data is written into a buffer without ensuring that the buffer is big enough to hold the data. If the size of the data is greater than the size of the buffer, the memory beyond the bounds of the buffer can be overwritten by part of the data. Depending on what the memory beyond the buffer is being used for, it may be possible for an attacker to supply data that will result in the execution of attacker-supplied code.

Buffer overflow vulnerabilities are most frequently found in code written in C and C++. These languages leave tasks such as type and boundary checking up to the developer, which means that programming mistakes can lead to vulnerabilities.

15.3 Application Security

Some steps that should be done when installing an application to help secure are:

Confirm that the version of the software being loaded doesn’t have known vulnerabilities.

Apply patches or upgrades to address any known vulnerabilities.

Remove or disable all unneeded default user accounts created by the application software, or change the passwords for those that have to remain.

If any default accounts are needed to modify, the password so the default isn’t being used.

Remove all of the manufacturer’s documentation from the server.

Remove all examples or test files from the server.

Remove any unneeded compilers, utilities, libraries, etc. from the server.

For externally facing servers modify welcome banners to remove any specific details, e.g., O/S type and version, name and version of the application software.

Display warning banners that advise that this is a secured system and any unauthorized persons logging in will be prosecuted to the full extent of the law.

13.4 Post-silicon Security and Trust Assessment for ICs

This section presents some of the commonly used post-silicon validation techniques, for example, fuzzing, negative testing, and white-box hacking. These activities inherently depend on human creativity, where tools and infrastructures primarily act as assistants, filling up gaps in human reasoning and providing recommendations.

1.3.5 Limitations of white-box vulnerability detection

There are two types of security testing methods: white-box testing and black-box testing.

White-box testing is based on knowledge of the system internals derived directly from the code (source or binary). The white-box testing is associated with testing of the software and has inside-out focus, targeting particular constructs, statements, code paths, or code sections. A technology used in security white-box vulnerability testing is known as static analysis and is commercialized in source and binary code analyzer tools. The promise of this technology is the 100% coverage of all code paths in the system. However, tools implementing this technology have several weaknesses producing inconclusive evidence of a system's trustworthiness.

Lack of complete system coverage – The tools provide some capabilities with proprietary and limited functionality, with each tool providing value only in subsets of the enterprise application space causing the need to use more than one static analysis tool to combine their strengths and avoid their weaknesses. As mentioned in the recent comparison of static analysis tools performed at NSA [Buxbaum 2007] “Organizations trying to automate the process of testing software for vulnerabilities have no choice but to deploy a multitude of tools.” Since current source/binary code analysis tools offer little interoperability, it is costly to evaluate, select and integrate the set of tools that provide an adequate coverage for the breadth of languages, platforms, and technologies that typical systems contain. Findings in one vulnerability report are not necessarily aligned with the pattern and condition of the vulnerability and therefore, reports from two tools for the same vulnerability many not be the same. For example, the evidence for buffer overflow vulnerability is scattered throughout the code: it involves a buffer write operation, a data item being written, another place where the buffer is allocated, and yet another place where the length of the buffer is calculated. There is a code path that allows an attacker to exploit the buffer overflow by providing some input into the application. In addition, a buffer overflow may be caused by another problem, such as an integer overflow. All this evidence has to be considered and reported in a single buffer overflow report using a common vocabulary and structure. Failure to use a common reporting standard leads to a situation where it is hard to merge reports from multiple vulnerability detection tools and achieve a significant improvement in the overall report quality, because the lack of interoperability and the common vocabulary makes it hard to 1) select the vulnerability that is reported by multiple tools; 2) for a given vulnerability, estimate the coverage of the same vulnerability pattern throughout the entire system; and 3) get coverage of the system by the multitude of tools.

Lack of aid in understanding the system – Vulnerability detections tools do not aid the team in understanding the system under assessment, an activity that is required for the evaluation team to make a conclusion about a system's trustworthiness, as well as to detect vulnerabilities that are specific to the system under evaluation—the knowledge that cannot be brought by the off-the-shelf vulnerability detection tools.

An automatic static analysis tool goes through the code, parses it, analyzes it, and searches for patterns of vulnerabilities. As a result, the tool produces a report describing the findings. As part of this process, a great deal of detailed knowledge of the system is generated because finding vulnerabilities requires a fine-grained understanding of the structure, control, and data flow of each application. However, as soon as the report is produced, this detailed knowledge disappears. It can no longer be used to systematically reproduce the analysis or to aid the assessment team to understand the system. It is only the list of vulnerabilities that they are provided with. A similar situation occurs during compilation. A compiler generates large amounts of fine-grained knowledge about the system, only to be discarded as soon as the object file is generated.

However, a consistent approach to representing and accumulating this knowledge is critical for a systematic and cost-efficient security evaluation, because not only do all code analysis capabilities need to share this knowledge, but also any inconsistencies in addressing the basic knowledge of the system will lead to bigger inconsistencies in derived reports.

An exploitable vulnerability is a complex phenomenon, so there are multiple possibilities to report it in a multitude of ways. The industry of vulnerability detection tools is still immature. There is no standardization on the nomenclature of vulnerabilities or on the common reporting practices, although several community efforts are emerging.

It is easy to make a case for the multi-stage analysis where a particular vulnerability detection capability is just one of the “data feeds” into the integrated system assessment model.

First, the original vulnerability analysis has to be augmented with additional assessment evidence, which is usually not provided by an off-the-shelf tool. For example, such evidence can be collected from people, processes, technology, and the environment of the system under evaluation. In addition, in a large number of situations, the findings from the automatic vulnerability detection capabilities need to be augmented by the results of the manual code reviews or evaluations of formal models.

Second, there is a gap between the off-the-shelf vulnerabilities that an automatic tool is looking for and the needs of a given system with its unique security functional requirements and threat model. Usually there are not enough inputs for an automatic tool to detect these vulnerabilities, so these analyses need to be performed. The inputs that are required for the additional vulnerability analysis are similar to the original analysis. This knowledge may include the specific system context, including the software and hardware environment in which the application operates, the threat model, specific architecture of the system, and other factors.

Third, other kinds of analysis in the broader context of systems assurance needs to be performed, in particular, architectural analysis, software complexity metrics, or penetration (black-box) testing.

In order to obtain a cohesive view of the security application, software evaluation teams often need to do painful point-to-point integrations between existing vulnerability detection capabilities and tools. Rarely do organizations choose this path.

Massive production of false positives and false negatives – There are some fundamental barriers to comprehensive code analysis, which leads to limitations of the vulnerability detection tools, and subsequently, to false negative and false positive report findings. In order to analyze a computation, all system components have to be considered, including the so-called application code, as well as the runtime platform and all runtime services, as some of the key control and data flow relationships are provided by the runtime framework, as the computation flows through the application code into the runtime platform and services and back to the application code. Application code alone, often written in more than one programming language, in most cases does not provide an adequate picture of the computation, as some segments of the flow are determined by the runtime platform and are not visible in the application code. For example, while a large number of control flow relationships between different activities in the application code are explicit (such as statements in a sequence, or calls from a statement to another procedure), some control flow relations are not visible in the code, including the so-called callbacks, where the application code registers a certain activity with the runtime framework (for example, an event handler or an interrupt handler) and it is the runtime framework that initiates the activity. Without the knowledge of such implicit relationships, the system knowledge is incomplete, leading to massive false positive and false negative entries in the report. While numbers of generated false negatives are unknown, the numbers of generated false positives are staggeringly high and “weeding” through a report to identify true positives is a costly process, causing limited use of such tools. To reduce the number of false reports some tools simply skip situations where they can not fully analyze a potential vulnerability within a short timeframe.

20.2.2 Attribute Specifications

Once we have defined an attribute name and type, we then use it to decorate items within a design. We write attribute specifications, nominating items that take on the attribute with particular values. The syntax rules for an attribute specification are

attribute_specification

    attribute identifier of entity_name_list : entity_class is expression ;

entity_name_list

    ( ( identifier

entity_class

    entity           

The first identifier in an attribute specification is the name of a previously declared attribute. The items to be decorated with this attribute are listed in the entity name list. Note that we use the term “entity” here to refer to any item in the design, not to be confused with an entity interface defined in an entity declaration. We adopt this terminology to remain consistent with the VHDL Language Reference Manual, since you may need to refer to it occasionally. However, we use the term as little as possible, preferring instead to refer to “items” in the design, to avoid confusion. The items to be decorated with the attribute are those named items of the particular kind specified by the “entity” class. The list of classes shown covers every kind of item we can name in a VHDL description, so we can decorate any part of a design with an attribute. Finally, the actual value for the attribute of the decorated items is the result of the expression included in the attribute specification. Here are some examples of attribute specifications using the attributes defined earlier:

attribute cell_name of std_cell : architecture is “DFF_SR_QQNN”;

attribute pin_number of enable : signal is 14;

attribute max_wire_delay of clk : signal is 50 ps;

attribute encoding of idle_state : literal is b“0000”;

attribute cell_position of the_fpu : label is ( 540 um, 1200 um );

In the case of an attribute declared to be of a composite type, we can write the attribute value in the form of an aggregate or string or bit-string literal. The type can be an unconstrained or partially constrained subtype, in which any index ranges not defined by the subtype are determined from the attribute value. For example, if we declare an attribute of a composite type:

type string_vector is array (positive range <>) of string;

attribute key_vector : string_vector;

we can decorate an item with the attribute as follows:

attribute key_vector of e : entity is

  (“66A6D 7DF3A 88CE1 8DEEB”, “012BD 2BEE9 98634 93FE1”);

Since the subtype for the attribute specifies index ranges in neither the top-level nor the element position, the corresponding index ranges of the aggregate are used to determine the index ranges for the attribute value, giving the ranges 1 to 2 for the top level and 1 to 23 for each element.

We now look at how attribute values may be specified for each of the classes of items shown in the syntax rule. For most classes of items, an attribute specification must appear in the same group of declarations as the declaration for the item being decorated. However, the first three classes shown in the syntax rule are design units that are placed in a design library as library units when analyzed. They are not declared within any enclosing declarative part. Instead, we can consider them as being declared in the context of the design library. The same also applies to packages that are declared as design units, as opposed to being declared locally within a design unit. However, this presents a problem if we wish to decorate an item of one of these classes with an attribute. For entities, architectures, configurations and packages, we solve this problem by placing the attribute specification in the declarative part of the design unit itself. For example, we decorate an architecture std_cell with the cell_name attribute as follows:

architecture std_cell of flipflop is

  attribute cell_name of std_cell : architecture is “DFF_SR_QQNN”;

  …  -- other declarations

begin

  …

end architecture std_cell;

In the case of packages, this rule applies whether a package is declared as a design unit or locally. The attribute specification must be included in the package declaration, not the package body. For example, we can decorate a package model_utilities with the optimize attribute as follows:

package model_utilities is

  attribute optimize : string;

  attribute optimize of model_utilities : package is “level_4”;

  …

end package model_utilities;

When we decorate subprograms we may need to distinguish between several overloaded versions. The syntax rule on  page 617 shows that we can include a signature to identify one version uniquely by specifying the types of its parameters and return value. Signatures were introduced in Chapter 11.

Example 20.5 Decorating a subprogram

If we have two overloaded versions of the procedure add_with_overflow declared in a process as shown below, we can decorate them using signatures in the attribute specification.

process is

  procedure add_with_overflow ( a, b : in integer;

                                sum : out integer;

                                overflow : out boolean ) is …

  procedure add_with_overflow ( a, b : in bit_vector;

                                sum : out bit_vector;

                                overflow : out boolean ) is …

  attribute built_in : string;

  attribute built_in of

    add_with_overflow [ integer, integer,

                        integer, boolean ] : procedure is

“int_add_overflow”;

  attribute built_in of

    add_with_overflow [ bit_vector, bit_vector,

                        bit_vector, boolean ] : procedure is

“bit_vector_add_overflow”;

begin

  …

end process;

The syntax rule also shows that we can identify an overloaded operator by writing the operator symbol as the function name. For example, if we declare a function to concatenate two lists of stimulus vectors:

function “&” ( a, b : stimulus_list ) return stimulus_list;

we can decorate it with an attribute as follows:

attribute debug : string;

attribute debug of “&” [ stimulus_list, stimulus_list

                         return stimulus_list ] : function is

                    “source_statement_step”;

The syntax rules for attribute specifications show the signature to be optional, and indeed, we can omit it when decorating subprograms. In this case, the attribute specification applies to all subprograms with the given name and class declared in the same declarative part as the attribute specification. For example, if we declare the following overloaded subprograms:

procedure add ( a, b : in integer; s : out integer );

procedure add ( a, b : in real; s : out real );

function add ( a, b : integer ) return integer;

function add ( a, b : real ) return real;

and write and attribute declaration and specifications:

attribute built_in : boolean;

atribute built_in of add : procedure is true;

attribute built_in of add : function is false;

the two procedures are decorated with the attribute value true, and the two functions are decorated with the attribute value false.

We can decorate a type, subtype or data object (a constant, variable, signal or file) by including an attribute specification after the declaration of the item. The attribute specification must appear within the same declarative part as the declaration of the item. For example, if we declare a resolved subtype resolved_mvl:

type mvl is (’X’, ‘0’, ‘1’, ‘Z’);

type mvl_vector is array ( integer range <>) of mvl;

function resolve_mvl ( drivers : mvl_vector ) return mvl;

subtype resolved_mvl is resolve_mvl mvl;

we can decorate it as follows:

type builtin_types is (builtin_bit, builtin_mvl, builtin_integer);

attribute builtin : builtin_types;

attribute builtin of resolved_mvl : subtype is builtin_mvl;

Generics and ports in the interface of an entity can be decorated with attributes. Generic constants are of constant class, generic types are of type class, generic subprograms are of procedure or function class, generic packages are of package class, and ports are of signal class. The interface list is considered to be in the declarative part of the entity. Hence, we write attribute specifications for generics and ports in the declarative part of the entity.

Example 20.6 Decorating generics and ports of an entity

Suppose the package physical_attributes declared the following attributes:

attribute layout_ignore : boolean;

attribute pin_number : positive;

We can declare an entity with decorated generic constants and ports as follows:

library ieee;  use ieee.std_logic_1164.all;

use work.physical_attributes.all;

entity \74x138\ is

  generic ( Tpd : time );

  port ( en1, en2a_n, en2b_n : in std_ulogic;

         s0, s1, s2 : in std_ulogic;

         y0, y1, y2, y3, y4, y5, y6, y7 : out std_ulogic );

  attribute layout_ignore of Tpd : constant is true;

  attribute pin_number of s0 : signal is 1;

  attribute pin_number of s1 : signal is 2;

  attribute pin_number of s2 : signal is 3;

  attribute pin_number of en2a_n : signal is 4;

  …

end entity \74x138\;

Subprogram parameters can also be decorated with attributes. The class is specified or implied in the interface list of the subprogram. We write the attribute specifications for subprogram parameters in the declarative part of the subprogram. Similarly, for uninstantiated subprograms, we can decorate the generics by writing attribute specifications in the declarative part. For uninstantiated packages, we can decorate the generics by writing attribute specification in the package declaration (not the package body). In both cases, the classes of generics are as described above for generics of entities.

Example 20.7 Decorating parameters of a subprogram

The following procedure has three parameters of different classes. Attribute specifications for the parameters are included in the declarative part of the procedure.

procedure mem_read ( address : in natural;

                     result : out byte_vector;

                     signal memory_bus : inout ram_bus ) is

  attribute trace of address : constant is “integer/hex”;

  attribute trace of result : variable is “byte/multiple/hex”;

  attribute trace of memory_bus : signal is

                      “custom/command=rambus.cmd”;

  …

begin

  …

end procedure mem_read;

We can decorate a component in a model by including an attribute specification along with the component declaration. An important point to realize is that the attribute decorates the template defined by the component declaration. It does not decorate component instances that use that template.

Example 20.8 Decorating a component declaration

The package below includes a component declaration for an and gate. The package imports two attributes, graphic_symbol and graphic_style, from a second package graphics_pkg in the library graphics and decorates the component template with each of these attributes.

library ieee;  use ieee.std_logic_1164.all;

library graphics;

package gate_components is

  use graphics.graphics_pkg.graphic_symbol,

      graphics.graphics_pkg.graphic_style;

  component and2 is

    generic ( prop_delay : delay_length );

    port ( a, b : in std_ulogic;  y : out std_ulogic );

  end component and2;

  attribute graphic_symbol of and2 : component is “and2”;

  attribute graphic_style of and2 : component is

                              “color:default, weight:bold”;

  …

end package gate_components;

If we wish to decorate a component instance or any other concurrent statement with an attribute, we do so by decorating the label of the statement. The label is implicitly declared in the declarative part of the architecture or block containing the concurrent statement. Hence, we place the attribute specification in that declarative part.

Example 20.9 Decorating a component instance

We might decorate a component instance in an architecture body with an attribute describing cell placement as follows:

architecture cell_based of CPU is

  component fpu is

    port ( … );

  end component;

  use work.cell_attributes.all;

  attribute cell_position of the_fpu : label is

                             ( 540 um, 1200 um );

  …

begin

  the_fpu : component fpu

    port map ( … );

  …

end architecture cell_based;

We can decorate sequential statements within a process or a subprogram in a similar way. The syntax rules for sequential statements show that each kind of sequential statement may be labeled. We decorate a sequential statement by specifying an attribute for the label. We place the attribute specification in the declarative part of the process or subprogram containing the sequential statement.

Example 20.10 Decorating a sequential statement

If we wish to decorate a loop statement in a process with the attribute synthesis_hint, we do so as follows:

controller : process is

  attribute synthesis_hint of control_loop : label is

                              “implementation:FSM(clk)”;

  …

begin

  …  -- initialization

  control_loop : loop

    wait until clk = ‘1’;

    …

  end loop;

end process controller;

When we introduced aliases and signatures in Chapter 11, we mentioned that enumeration literals can be thought of as functions with no parameters that return values of their enumeration types. We can take the same approach when decorating enumeration literals with attributes, in order to distinguish between literals of the same name from different enumeration types.

Example 20.11 Decorating an enumeration literal

If we have two enumeration types declared as

type controller_state is (idle, active, fail_safe);

type load_level is (idle, busy, overloaded);

we can decorate the literals of type controller_state as follows:

attribute encoding of

  idle [ return controller_state ] : literal is b“00”;

attribute encoding of

  active [ return controller_state ] : literal is b“01”;

attribute encoding of

  fail_safe [ return controller_state ] : literal is b“10”;

The signature associated with the literal idle indicates that it is of type controller_state, not load_level. As with attribute specifications for subprograms, if a signature is not included for a literal, all literals of the given name declared in the same declarative part as the attribute specification are decorated with the attribute.

When we declare a physical type we introduce a primary unit name and possibly a number of secondary unit names. Each of the unit names is a declared item and so may be decorated with attributes.

Example 20.12 Decorating a physical unit

The package below defines a physical type voltage. It also declares an attribute, resolution, and decorates each of the units of voltage with this attribute.

package voltage_defs is

  type voltage is range -2e9 to +2e9

    units

      nV;

      uV = 1000 nV;

      mV = 1000 uV;

      V = 1000 mV;

    end units voltage;

  attribute resolution : real;

  attribute resolution of nV : units is 1.0;

  attribute resolution of uV : units is 0.01;

  attribute resolution of mV : units is 0.01;

  attribute resolution of V : units is 0.001;

end package voltage_defs;

If we embed PSL code in a VHDL model, we can decorate declared properties and sequences. For example:

property SingleCycleRequest is

  always req -> next not req;

sequence ReadCycle is

  { ba; {bb[*]} && {ar[->]; dr[->]}; not bb };

attribute enable_heuristics of

            SingleCycleRequest : propery is true;

attribute enable_heuristics of ReadCycle : sequence is true;

The one remaining class of items that can be decorated with attributes is groups. We introduce groups in the next section and show examples of decorated groups.

If we return to the syntax rules for attribute specifications, shown on  page 617, we see that we can write the keyword others in place of the list of names of items to be decorated. If we do so, the attribute specification applies to all items of the given class in the declarative part that are not otherwise decorated with the attribute. Such an attribute specification must be the last one in the declarative part that refers to the given attribute name and item class.

Example 20.13 Decorating items not previously decorated

In the following architecture body, signals are decorated with attributes specifying the maximum allowable delays due to the physical layout. The two signals recovered_clk1 and recovered_clk2 are explicitly decorated with the attribute value 100 ps. The remaining signals are decorated with the value 200 ps.

library ieee;  use ieee.std_logic_1164.all;

use work.timing_attributes.all;

architecture structural of sequencer is

  signal recovered_clk1, recovered_clk2 : std_ulogic;

  signal test_enable : std_ulogic;

  signal test_data : std_ulogic_vector(0 to 15);

  attribute max_wire_delay of

    recovered_clk1, recovered_clk2 : signal is 100 ps;

  attribute max_wire_delay of others : signal is 200 ps;

  …

begin

  …

end architecture structural;

The syntax rules also show that we can use the keyword all in place of a list of item names. In this case, all items of the given class defined in the declarative part containing the attribute specification are decorated. Such an attribute specification must be the only one in the declarative part to refer to the given attribute name and item class.

Although we can only decorate an item with one value for a given attribute name, we can decorate it with several different attributes. We simply write one attribute specification for each of the attributes decorating the item. For example, a component instance labeled mult might be decorated with several attributes as follows:

attribute cell_allocation of

  mult : label is “wallace_tree_multiplier”;

attribute cell_position of

  mult : label is ( 1200 um, 4500 um );

attribute cell_orientation of

  mult : label is down;

If an item in a design is decorated with a user-defined attribute, we can refer to the attribute value using the same notation that we use for predefined attributes. The syntax rule for an attribute name referring to a user-defined attribute is

attribute_name

If the name of the item is unambiguous, we can simply write an apostrophe and the attribute name after the item name. For example:

std_cell‘cell_name

enable‘pin_number

clk‘max_wire_delay

v4 := idle_state‘encoding

the_fpu‘cell_position

In the case of attributes decorating subprograms or enumeration literals, it may be necessary to use a signature to distinguish between a number of alternative names. For example, we might refer to attribute values of different versions of an increment function as

increment [ bit_vector return bit_vector ] ‘built_in

increment [ std_ulogic_vector return std_ulogic_vector ] ‘built_in

Similarly, we might refer to attribute values of enumeration literals as

high [ return speed_range ] ‘representation

high [ return coolant_level ] ‘representation

While it is legal VHDL to refer to attribute values such as these in expressions, it is not good design practice to use attribute values to affect the structure or behavior of the model. It is better to describe structure and behavior using the language facilities intended for that purpose and use attributes to annotate the design with other kinds of information for use by other software tools. For this reason, we do not further discuss the use of attribute values in models. Software tools that use attributes should include documentation describing the required attribute types and their usage.

In Chapter 11, we introduced aliases as a way of defining alternate names for items in a design. In most cases, referring to an item using an alias is exactly the same as referring to it using its original name. The same interpretation holds when decorating items with attributes. When we use an alias of an item in an attribute specification, it is the original object denoted by the alias that is decorated, not the alias. This is the interpretation we saw for the predefined attributes discussed in the previous section. The exceptions are the predefined attributes that return the path name of an item and those that return information about the index ranges of arrays. One restriction on decorating data objects using aliases is that we may only do so using aliases that denote whole objects, not elements or slices of records or arrays. This restriction corresponds to the restriction that an attribute must decorate a whole object. The syntax rule for an attribute specification does not provide for naming parts of objects, since we can only write a simple identifier as an object name.

One final point to mention about user-defined attributes relates to component instantiation statements and to subprogram calls. In a component instantiation statement, actual signals are associated with formal ports of an entity. If the actual signal is decorated with an attribute, the attribute information is only visible in the context of the actual signal, namely, in the architecture body in which the signal is declared. It is not carried through to the instantiated entity. For example, if we have a signal s decorated with an attribute attr, we might use it as an actual signal in a component instantiation statement:

c1 : entity work.e(arch)

  port map ( p => s );

Within the architecture body arch, we cannot refer the attribute of the signal using the notation p’attr. This notation instead refers to the attribute attr of the port p, which can only be defined in the entity declaration.

In a subprogram call an actual parameter (such as a constant, variable, signal or file) is associated with a formal parameter of the subprogram. If the actual parameter is decorated with an attribute, that attribute information is likewise not carried through to the subprogram. The decoration is purely local to the region in which the actual object is declared.

VHDL-87, -93, and -2002

Since these versions of VHDL do not allow PSL code to be embedded within VHDL models, we cannot use the word property or sequence attribute specifications for the class of an item to be decorated.

VHDL-87

The syntax rules for attribute specifications in VHDL-87 do not allow us to name a character literal as an item to be decorated. Nor may we specify the entity class literal, units, group or file. Furthermore, we may not include a signature after an item name. Hence there is no way to distinguish between overloaded subprograms or enumeration literals; all items of the given name are decorated.

Relevant SQL language elements

SQL knows several basic language elements, including statements, select specifications, and search conditions over operators, functions, attributes, and objects. Most DBMSs allow basic obfuscation techniques for statements already. For example, the case of the characters used in the statement does not matter; we can use SELECT, select, or even sElECt. This is true for most keywords as well, but usually not for table names and other strings pointing to actual database data and structures; those elements are treated in a case-sensitive manner. So, whereas sELecT * frOm test works if the table test exists, sELECt * fROm tEsT will fail and raise a “Table not found” error. The most important statements are usually SELECT, INSERT, UPDATE, and DELETE for direct data retrieval and manipulation, as well as ALTER, DROP, and TRUNCATE for structural changes. Most DBMSs ship with features allowing direct interaction with the file system, manipulating the operating system Registry, or even executing arbitrary code. MySQL, for example, ships with INTO OUTFILE to actually write data to the hard disk of the DBMS server if the privilege context allows this.

Many DBMSs also support comments, and thereby allow you to mix comments into the statement declaration, as in SE/**/LE/**/CT. Most DBMSs support two kinds of comments: block comments via /**/ and one-line comments via #. But there are several special ways to work with comments and use them to prematurely end statements or just to perform basic obfuscation. We look at SQL and comments later in the section “Comments.”

7.5.1 Integer overflow attack

Integer overflow is a common security vulnerability in many applications, mainly based on ethereum smart contracts, which occurred primarily due to a lack of code validations. Smart contracts are a series of programme codes in which unique numbers determine an integer’s upper and lower limits. An integer overflow problem occurs when the value executed reaches its prescribed limits, causing the machine to halt specific errors.

A few solutions have been suggested to mitigate the risk of integer overflow attack in smart contracts; however, most of them focus on careful analysis, rewriting, verification of codes writing [304,315].