Code reuse attacks such as return-oriented programming (ROP) have become prevalent techniques to exploit memory corruption vulnerabilities in software programs. A variety of corresponding defenses ...has been proposed, of which some have already been successfully bypassed -- and the arms race continues. In this paper, we perform a systematic assessment of recently proposed CFI solutions and other defenses against code reuse attacks in the context of C++. We demonstrate that many of these defenses that do not consider object-oriented C++ semantics precisely can be generically bypassed in practice. Our novel attack technique, denoted as counterfeit object-oriented programming (COOP), induces malicious program behavior by only invoking chains of existing C++ virtual functions in a program through corresponding existing call sites. COOP is Turing complete in realistic attack scenarios and we show its viability by developing sophisticated, real-world exploits for Internet Explorer 10 on Windows and Fire fox 36 on Linux. Moreover, we show that even recently proposed defenses (CPS, T-VIP, vfGuard, and VTint) that specifically target C++ are vulnerable to COOP. We observe that constructing defenses resilient to COOP that do not require access to source code seems to be challenging. We believe that our investigation and results are helpful contributions to the design and implementation of future defenses against control flow hijacking attacks.
The electronic Ligand Builder and Optimization Workbench (eLBOW) is a program module of the PHENIX suite of computational crystallographic software. It is designed to be a flexible procedure that ...uses simple and fast quantum‐chemical techniques to provide chemically accurate information for novel and known ligands alike. A variety of input formats and options allow the attainment of a number of diverse goals including geometry optimization and generation of restraints.
We present pyOpt, an object-oriented framework for formulating and solving nonlinear constrained optimization problems in an efficient, reusable and portable manner. The framework uses ...object-oriented concepts, such as class inheritance and operator overloading, to maintain a distinct separation between the problem formulation and the optimization approach used to solve the problem. This creates a common interface in a flexible environment where both practitioners and developers alike can solve their optimization problems or develop and benchmark their own optimization algorithms. The framework is developed in the Python programming language, which allows for easy integration of optimization software programmed in Fortran, C, C+ +, and other languages. A variety of optimization algorithms are integrated in pyOpt and are accessible through the common interface. We solve a number of problems of increasing complexity to demonstrate how a given problem is formulated using this framework, and how the framework can be used to benchmark the various optimization algorithms.
En el presente artículo se plantea una solución algorítmica al problema de aproximarse a la raíz cuadrada de un número dado, basándose en el método que utilizaron los babilonios y aprovechando los ...recursos computacionales modernos. Para implementar esta solución algorítmica, se ha acudido a la programación funcional a través del lenguaje Scheme entorno DrRacket versión 6.1, a la programación imperativa en lenguaje C++ entorno DevC++ versión 4.9.9.2 y a la programación orientada a objetos en lenguaje Java entorno Eclipse Java EE IDE for Web Developers Version: Luna Service Release 2 (4.4.2). La metodología utilizada se enmarca en la investigación científica de orden cuantitativo y tecnológico de carácter instrumental. El algoritmo presentado y la metodología utilizada se han compartido con los estudiantes de Ingeniería de Sistemas y Computación de la Universidad Tecnológica de Pereira. Los resultados obtenidos han sido significativamente favorables en lo cuantitativo toda vez que se ha podido establecer un enlace entre lo teórico y lo práctico así como en lo tecnológico pues ha permitido promover entre los estudiantes de programación la idea de que cuando la lógica está clara, el paradigma y el lenguaje de programación automáticamente se aclaran. Con esta experiencia investigativa queda claro que es posible implementar soluciones antiguas a problemas tradicionales de las matemáticas sin perder el norte de su eficiencia y efectividad y así como encontrar diferencias y coincidencias entre diferentes paradigmas de programación.
GenASiSBasics provides Fortran 2003 classes furnishing extensible object-oriented utilitarian functionality for large-scale physics simulations on distributed memory supercomputers. This ...functionality includes physical units and constants; display to the screen or standard output device; message passing; I/O to disk; and runtime parameter management and usage statistics. This revision – Version 3 of Basics – includes a significant name change, some minor additions to functionality, and a major addition to functionality: infrastructure facilitating the offloading of computational kernels to devices such as GPUs.
Program Title: SineWaveAdvection, SawtoothWaveAdvection, and RiemannProblem (fluid dynamics example problems illustrating GenASiSBasics); ArgonEquilibrium and ClusterFormation (molecular dynamics example problems illustrating GenASiSBasics)
Program Files doi:http://dx.doi.org/10.17632/6w9ygpygmc.2
Licensing provisions: GPLv3
Programming language: Fortran 2003 (tested with GNU Compiler Collection 8.1.0, Intel Fortran Compiler 18.0.3, Cray Compiler Environment 8.6.5, IBM XL Fortran 16.1.0)
Journal reference of previous version: Computer Physics Communications 214 (2017) 247
Does the new version supersede the previous version?: Yes
Reasons for the new version: This version includes a significant name change, some minor additions to functionality, and a major addition to functionality: infrastructure facilitating the offloading of computational kernels to devices such as GPUs.
Summary of revisions:
The class VariableGroupForm – a major workhorse for handling set of related fields – has been renamed StorageForm.
The ability to use unicode characters in standard output has been added, but is currently only supported by the GNU Compiler Collection (GCC). This capability is used to display exponents as numerical superscripts, as well as symbols such as ħ, ⊙, and Å in the display of relevant units. It is made operational by the line Display omitted which is now included in the machine-specific makefile fragments with a GCC suffix in the Build/Machines directory.
There are some changes to units and constants. The geometrized units of past releases (G=c=k=1, with a fundamental unit of meter) have been replaced by natural units (ħ=c=k=1, with MeV as the fundamental unit). Lorentz–Heaviside electromagnetic units are employed (permeability μ=1; no factors of 4π in the Maxwell equations). This refers to numbers as processed internally by the code; as described in the initial release, users can employ the members of the UNIT singleton for input/output purposes, that is, to specify or display numbers with any available units they wish. A number of units have been added, and the specification all units has been put on a more rational basis in keeping with six of the seven standard SI base units (meter, kilogram, second, ampere, kelvin, mole; we have not needed the candela; see 3). Some physical and astrophysical constants have also been added. All constants have been updated to 2018 values 4.
For notifications to standard output, a few tweaks to ignorability levels have been made in various classes. The default output to screen is now less verbose (ignorability INFO_1, our designation for messages of significance just below WARNING).
A couple of additions have been made to MessagePassing: null subcommunicators are accommodated, and an AllToAll_V method has been added to CollectiveOperation_R_Form.
Enhancements to timer functionality have been made. The class TimerForm now has a member Level, which is specified in order to control indentation in screen output. Some functionality has been added to PROGRAM_HEADER_Singleton to work with timers. A method TimerPointer returns a pointer to a timer with a specified Handle (typically a meaningfully named integer). The new members TimerLevel and TimerDisplayFraction of PROGRAM_HEADER_Singleton, which can be set from the command line, can be used to suppress output from timings deemed insignificant, based on timer level or a measured time interval falling below a specified fraction of the total execution time.
The most significant addition in functionality in this release is the addition of infrastructure to offload computational kernels to hardware accelerators such as GPUs using OpenMP device-related directives and runtime library routines in OpenMP 4.5 and later.22https://www.openmp.org/specifications/.This infrastructure, implemented in a new subdivision Devices (see Fig. 1), provides lower-level routines to perform memory management between the host (CPU) and device (GPU) including data allocation, data movement between host and device, and device-to-host memory address association. The routines are implemented as Fortran wrappers to the OpenMP runtime library and CUDA33https://developer.nvidia.com/about-cuda.routines written in C. Additional methods and an option utilizing the lower-level Devices routines have been added to our StorageForm class. They are: UpdateHost() and UpdateDevice() to copy data from device to host and host to device, respectively; AllocateDevice() to allocate memory on the device mirroring the allocation on the host; and PinnedOption as an optional flag to the Initialize() method to allocate the host memory in a page-locked region to facilitate faster data transfer between host and device. A detailed description of the implementation of this functionality can be found in 5.
To deal with different levels of compiler support for device-related OpenMP directives, we use the preprocessor in some source files in Devices to guard against attempted compilation of unsupported features. Preprocessor macro substitution is also utilized in OpenMP directives to switch between multi-threading parallelism on CPUs and offload parallelism to GPUs. Setting the makefile variable ENABLE_OMP_OFFLOAD to 1 – which is the default in the machine-specific makefile Makefile_POWER_XL for the XL compiler on POWER-based supercomputers – sets the appropriate flags and preprocessing to enable compilation for OpenMP offload parallelism. Alternatively, the command Display omitted sets this variable when make is invoked from the command line.
Information regarding the number of devices available to the program, the kind of OpenMP parallelism enabled (i.e. multi-threading or offload), and the selected OpenMP loop scheduling are displayed at runtime by PROGRAM_HEADER_Singleton. When offload parallelism is enabled, the loop scheduling is automatically set to static with chunk-size of 1. With multi-threading parallelism, the schedule defaults to guided but can be overridden at runtime by setting the environment variable OMP_SCHEDULE appropriately.
The example problem RiemannProblem in the Examples directory under the Basics division has been modified to exploit the GPUs using this new functionality. The computational kernels for the problem have been annotated with new OpenMP directives (via the appropriate preprocessor macros) such that they are offloaded to the GPUs when offload parallelism is enabled during compilation. In 5 we demonstrate the weak scaling of this example problem up to 8000 GPUs on the Summit supercomputer at the Oak Ridge Leadership Computing Facility.44https://www.olcf.ornl.gov/olcf-resources/compute-systems/summit/.Figs. 2 and 3 show a visualization of the three-dimensional version of RiemannProblem at 12803 resolution executed with 1000 GPUs.
Nature of problem: By way of illustrating GenASiSBasics functionality, solve example fluid dynamics and molecular dynamics problems.
Solution method: For fluid dynamics examples, finite-volume. For molecular dynamics examples, leapfrog and velocity-Verlet integration.
External routines/libraries: MPI 1 and Silo 2
Additional comments including restrictions and unusual features: The example problems named above are not ends in themselves, but serve to illustrate our object-oriented approach and the functionality available though GenASiSBasics. In addition to these more substantial examples, we provide individual unit test programs for each of the classes comprised by GenASiSBasics.
GenASiSBasics is available in the CPC Program Library and also at https://github.com/GenASiS.
http://www.mcs.anl.gov/mpi/
https://wci.llnl.gov/simulation/computer-codes/silo
https://en.wikipedia.org/wiki/SI_base_unit
M. Tanabashi et al. (Particle Data Group), Phys. Rev. D 98 (2018) 030001
Budiardja, R.D. and Cardall, C.Y., “Targeting GPUs with OpenMP Directives on Summit: A Simple and Effective Fortran Experience,” submitted for publication Parallel Computing: Systems and Applications, arXiv:1812.07977 physics.comp-ph,
OpenSMOKE++ is a general framework for numerical simulations of reacting systems with detailed kinetic mechanisms, including thousands of chemical species and reactions. The framework is entirely ...written in object-oriented C++ and can be easily extended and customized by the user for specific systems, without having to modify the core functionality of the program. The OpenSMOKE++ framework can handle simulations of ideal chemical reactors (plug-flow, batch, and jet stirred reactors), shock-tubes, rapid compression machines, and can be easily incorporated into multi-dimensional CFD codes for the modeling of reacting flows. OpenSMOKE++ provides useful numerical tools such as the sensitivity and rate of production analyses, needed to recognize the main chemical paths and to interpret the numerical results from a kinetic point of view. Since simulations involving large kinetic mechanisms are very time consuming, OpenSMOKE++ adopts advanced numerical techniques able to reduce the computational cost, without sacrificing the accuracy and the robustness of the calculations.
In the present paper we give a detailed description of the framework features, the numerical models available, and the implementation of the code. The possibility of coupling the OpenSMOKE++ functionality with existing numerical codes is discussed. The computational performances of the framework are presented, and the capabilities of OpenSMOKE++ in terms of integration of stiff ODE systems are discussed and analyzed with special emphasis. Some examples demonstrating the ability of the OpenSMOKE++ framework to successfully manage large kinetic mechanisms are eventually presented.
Program title: OpenSMOKE++
Catalogue identifier: AEVY_v1_0
Program summary URL:http://cpc.cs.qub.ac.uk/summaries/AEVY_v1_0.html
Program obtainable from: CPC Program Library, Queen’s University, Belfast, N. Ireland
Licensing provisions: GNU General Public License, version 3
No. of lines in distributed program, including test data, etc.: 146353
No. of bytes in distributed program, including test data, etc.: 4890534
Distribution format: tar.gz
Programming language: C++.
Computer: Any computer that can run a C++ Compiler.
Operating system: Tested on Microsoft Windows 7, Ubuntu 14.4.
RAM: From a few Mb to several Gb depending on the size of the system being simulated.
Classification: 22.
External routines: Eigen, Boost C++ Libraries, RapidXML
Nature of problem: Evolution of reacting gas mixtures with detailed description of thermodynamic, kinetic and transport data.
Solution method: Stiff systems of Ordinary differential Equations, whose solution is obtained using methods based on the Backward Differentiation Formulas (BDF) (LU factorization of dense matrices is required).
Additional comments: The code was specifically conceived for managing homogeneous, reacting mixtures including thousands of species and reactions.
Running time: Problem-dependent, from seconds (small kinetics) to hours
We are developing a new lattice QCD code set "Bridge++" aiming at extensible, readable, and portable workbench for QCD simulations, while keeping a high performance at the same time. Bridge++ covers ...conventional lattice actions and numerical algorithms. The code set is constructed in C++ with an object oriented programming. In this paper we describe fundamental ingredients of the code and the current status of development.
We present a comprehensive study of an implementation of the Smalltalk object oriented system, one of the first and purest object-oriented programming environment, searching for scaling laws in its ...properties. We study ten system properties, including the distributions of variable and method names, inheritance hierarchies, class and method sizes, system architecture graph. We systematically found Pareto - or sometimes log-normal - distributions in these properties. This denotes that the programming activity, even when modeled from a statistical perspective, can in no way be simply modeled as a random addition of independent increments with finite variance, but exhibits strong organic dependencies on what has been already developed. We compare our results with similar ones obtained for large Java systems, reported in the literature or computed by ourselves for those properties never studied before, showing that the behavior found is similar in all studied object oriented systems. We show how the Yule process is able to stochastically model the generation of several of the power-laws found, identifying the process parameters and comparing theoretical and empirical tail indexes. Lastly, we discuss how the distributions found are related to existing object-oriented metrics, like Chidamber and Kemerer's, and how they could provide a starting point for measuring the quality of a whole system, versus that of single classes. In fact, the usual evaluation of systems based on mean and standard deviation of metrics can be misleading. It is more interesting to measure differences in the shape and coefficients of the data?s statistical distributions.
Placement of attributes/methods within classes in an object-oriented system is usually guided by conceptual criteria and aided by appropriate metrics. Moving state and behavior between classes can ...help reduce coupling and increase cohesion, but it is nontrivial to identify where such refactorings should be applied. In this paper, we propose a methodology for the identification of Move Method refactoring opportunities that constitute a way for solving many common feature envy bad smells. An algorithm that employs the notion of distance between system entities (attributes/methods) and classes extracts a list of behavior-preserving refactorings based on the examination of a set of preconditions. In practice, a software system may exhibit such problems in many different places. Therefore, our approach measures the effect of all refactoring suggestions based on a novel entity placement metric that quantifies how well entities have been placed in system classes. The proposed methodology can be regarded as a semi-automatic approach since the designer will eventually decide whether a suggested refactoring should be applied or not based on conceptual or other design quality criteria. The evaluation of the proposed approach has been performed considering qualitative, metric, conceptual, and efficiency aspects of the suggested refactorings in a number of open-source projects.
PDF
