Specialization of Run-time Configuration Space at Compile-time An Exploratory Study

2025-05-03 0 0 944.93KB 14 页 10玖币

侵权投诉

Specialization of Run-time Conguration Space at

Compile-time: An Exploratory Study

Xhevahire Tërnava

Univ Rennes, CNRS, Inria, IRISA

F-35000 Rennes, France

xhevahire.ternava@irisa.fr

Mathieu Acher

Univ Rennes, CNRS, Inria, IRISA

Institut Universitaire de France (IUF)

F-35000 Rennes, France

mathieu.acher@irisa.fr

Benoit Combemale

Univ Rennes, CNRS, Inria, IRISA

F-35000 Rennes, France

benoit.combemale@irisa.fr

Abstract

Numerous software systems are highly congurable through

run-time options, such as command-line parameters. Users

can tune some of the options to meet various functional and

non-functional requirements such as footprint, security, or

execution time. However, some options are never set for a

given system instance, and their values remain the same

whatever the use cases of the system. Herein, we design a

controlled experiment in which the system’s run-time con-

guration space can be specialized at compile-time and com-

binations of options can be removed on demand. We perform

an in-depth study of the well-known

x264

video encoder and

quantify the eects of its specialization to its non-functional

properties, namely on binary size, attack surface, and per-

formance while ensuring its validity. Our exploratory study

suggests that the congurable specialization of a system has

statistically signicant benets on most of its analysed non-

functional properties, which benets depend on the number

of the debloated options. While our empirical results and

insights show the importance of removing code related to un-

used run-time options to improve software systems, an open

challenge is to further automate the specialization process.

Keywords:

program specialization, performance, run-time

variability, conguration options, debloating

1 Introduction

Modern software systems are highly congurable and ex-

pose to the users their abundant conguration options. By

setting conguration options’ values, a software system is

customized for dierent users to reach specic functionality

or performance goals (e.g., execution time, energy consump-

tion, quality of the result) without the need to modify its

source code. Such systems have a large and dierent number

of options. A considerable number of their options are set

at run-time, for example, a recent version of

curl

has about

205 compile-time options and 242 run-time options

, then

the

x264

video encoder has 39 compile-time options and 162

run-time options

. Run-time options are typically accessible

via command-line parameters, conguration les, or menu

1Documentation of curl: hps://curl.se/.

2hp://www.chaneru.com/Roku/HLS/X264_Seings.htm.

preferences. Such run-time variability is a strength since sys-

tem’s users have the exibility to tune their systems, owing

to their specic use case and deployment constraints.

However, (i) there is evidence that "a signicant percentage

(up to 54

1%) of parameters are rarely set by any user" [

] and

thus they unnecessarily "bloat" the software. Some options

are never tuned and their values remain the same for a given

usage, for example, depending on the user, the performed

activities, and the targeted environment. For instance, a user

or an organization may choose always to encode a video

with

x264

in an (ultra-)fast way. In this case, its run-time

conguration option of

--cabac

is always disabled, as it of-

fers better compression, but requires more processing power

to encode and decode a video. Apart from that, (ii) it is com-

mon to think that a library or a conguration option that

is unused today can be used in the future. In fact, quite the

opposite is true. Pieces of evidence show that the libraries

that are unused today in a software system (86% of them)

are unlikely to be ever used in the future [

]. Then, the

unused functionalities in a software system can threaten its

security, slow down its performance, aect its reliability, or

increase its maintenance [

]. Thus, run-time variability is

sometimes unnecessary and does not have to be embedded.

Based on this observation, we bring up the idea of special-

izing the run-time conguration space of a software system.

The goal is to retain only a subset of congurations that meet

a functional or a performance requirement and thus discard

the rest. Specically, we aim to debloat run-time options

that are never used within the source code, at compile-time.

Which options are unused depend on the system’s usage con-

text and they are inputs to the specialization process. Our

hypothesis is that the code of unused run-time options is a

manifestation of code bloat that may increase the binary size,

the attack surface, or slow down the system. For instance,

options that are never used induce dead code that can be

eliminated (e.g., by a compiler), thus improving the overall

system. This paper aims to investigate this hypothesis and

explore to what extent removing run-time options can bring

benets to the non-functional properties of software. To the

best of our knowledge, quantifying the benets (if any) has

received little attention.

arXiv:2210.14082v1 [cs.SE] 25 Oct 2022

Conference acronym ’XX, June 03–05, 2018, Woodstock, NY Xhevahire Tërnava, Mathieu Acher, and Benoit Combemale

Specializing the conguration space of a software sys-

tem has a long tradition since the seminal paper of Czar-

necki et.al., [

] and others (e.g., [

]). However, most of the works focused on the specializa-

tion of variability models where constraints among individ-

ual options (or across several options) are added to enforce

the conguration space. A missing part we investigate in this

paper is to propagate this specialization to the source code

of a congurable system. Specialization can also be seen as

a debloating problem where a subset of run-time options

to specialize are bloat of a congurable system. Several de-

bloating approaches are proposed in the literature. Most of

them provide a way for debloating the unused functionali-

ties from the external libraries or from high-level "features"

of a system [

]. Yet, to the best of our knowledge,

debloating run-time options of the congurable systems has

received little attention. An important specicity of our prob-

lem is that the specialization should be exible and is itself

congurable. That is, not all options are set once and for

all: in contrast, existing debloating techniques specialize the

system under study with a full conguration. Our proposal

is to annotate run-time options with compilation directives

throughout the source code. As such, the conguration space

of run-time options can be specialized at compile-time and

(combinations of) options can be removed on-demand. In

the future, the support for automation of these processes

asks for software language engineering (SLE) techniques.

To realize the idea of specializing a conguration space,

several new challenges need to be addressed, such as (i) to

locate the run-time options within the source code and (ii) to

take care of the system’s validity after its specialization. Our

research methodology is to statically annotate run-time op-

tions to mitigate the risk of synthesizing an unsound and

incomplete specialization. In this way, this controlled eort

limits the introduction of errors that could bias the benets

(if any) of specialization on non-functional properties. In

addition, we establish a ground truth for future automatic

program specializers and we report on insights from our

experience on the case of x264.

The contributions of this paper are as follows:

•

We propose a means for conguring the specialization

of a software system through debloating its unused

run-time conguration options at compile-time;

•

We analyze the resulting non-functional properties

(i.e., binary size, attack surface, and performance) un-

der two specialization scenarios of

x264

, showing im-

provements of the

x264

congurable system without

sacricing its interoperability and validity;

•

We made available the data for reproducing the ex-

periments and call to replicate our study for further

conrming or refuting our results 3.

3Companion page: hps://anonymous.4open.science/r/x264-6ED7

2 Background and motivating case study

In this section, we introduce the basic concepts of cong-

urable software systems and the system used as a case study.

2.1 Background

Users can congure a software system by setting the values

of its numerous options. Usually, an option carries a par-

ticular functionality, has a type of value (namely, Boolean,

integer, or string), and a binding time (namely, compile-time

or run-time). A conguration is an assignment of values to op-

tions at their specic binding time. Default values are also as-

signed to some options. Hence, users can build their custom

software by (de-)activating some options at compile-time or

run-time, but not only at these times [

]. The interest of

compile-time options is to embed in the resulting executable

program what is necessary for a given use case. Typically,

preprocessor directives (e.g., #ifdef in C/C++ projects) are

used to implement them. As for the run-time options, they

are (de-)activated prior to, or even during, the execution.

Command-line parameters, plugins, or conguration les

are examples of mechanisms that users can rely on to con-

trol them. In this work, we considered the run-time options,

which are set as command-line parameters during the soft-

ware’s load-time. Within the source code, run-time options

are implemented by ordinary control statements, such as

if statements, and locating them in code can be challeng-

ing as they are implicit. Nowadays software systems, such

x264

video encoder, are congurable and often provide

compile-time and run-time options to customize them.

2.2 Motivating case study

As a motivating system for this study is chosen the software

system of

x264 4

. It is a command-line video encoder im-

plemented in

, which has been used for the past 5 years to

evaluate the debloating approaches [

], is studied among

the highly congurable systems (e.g., [

]),

and has plenty of run-time options. We use the

x264

at its

recent commit

db0d417 5

. It has 114,475 lines of code (LoC)

237 les, 39 compile-time options, and 162 run-time options.

For example, it is possible to deactivate the support of

mp4

format at compile-time by using the

--disable-lsmash

op-

tion during the system build, as in the following.

$ ./ c on f ig ur e -- di sa bl e - l sm as h && m ak e

After the system’s build, the run-time options can be set.

They have an eect on the properties of the encoded video,

namely on its encoding time, bitrate, and frame rate. Here is

a possible usage of three run-time options in x264.

$ x 264 -- c ab ac - - mb tr ee - -mi xed - refs - o vi d .264 v id . y 4m

4hp://www.chaneru.com/Roku/HLS/X264_Seings.htm

5x264 software system: hps://github.com/mirror/x264

6Measured using the clocl tool: hps://github.com/AlDanial/cloc

Specialization of Run-time Configuration Space at Compile-time: An Exploratory Study Conference acronym ’XX, June 03–05, 2018, Woodstock, NY

The used

--cabac

--mbtree

, and

--mixed-refs

options are

Boolean. They also have their variant to negate their func-

tionality, for example, --mbtree has --no-mbtree.

x264

is a free software application for encoding video

streams into the H.264 compression format. It is often used as

a library in large systems, such as in space ight hardware

where its (i) binary size and (ii) performance matters. Besides,

(iii) a vulnerability in the

x264

’s (H.264 decoder) function

could be used to attack a larger system, such as the case with

the Cisco Meeting Servers

. Nowadays, the security of mod-

ern software systems is mostly threatened internally, that

is, by reusing their existing code, without the need for code

injection [

]. This kind of attack allows an attacker to exe-

cute arbitrary code on a victim’s machine. In this attack, the

attacker is able to chain some small code sequences (called

gadgets) and threaten the security of the system. Basically,

the exploited code sequences by the attacker end in a return

(RET or JMP) instruction. Therefore, one of the commonly

used metrics for measuring the attack surface in a system is

the number of code reuse gadgets that are available and which

can be exploited by an attacker [11,27,46].

Motivated by similar requirements, we analyse the eects

of specializing

x264

on these three non-functional properties,

namely on its binary size, attack surface, and performance.

3 Specialization approach

3.1 The vision for debloating unused run-time

options at compile-time

At the system level, the usual approach is to keep as much

variability as possible. All run-time options may somehow

be needed one day. Furthermore, packages, binaries, or build

instructions force users to take them all. However, this vari-

ability is sometimes unnecessary: in a given context, some

options may never be tuned and thus they always have the

same value for all actual use cases of a given instance of the

software. For instance,

--cabac

might always have the true

value. In this case, its corresponding variable in the source

code becomes a constant. By setting the option of

--no-cabac

will speed up the video encoding time, but the video quality

may deteriorate. Hence, the tune of run-time options de-

pends on the objectives and constraints of the user. Keeping

an option while actually always using the same value leads

to missed opportunities. First, by knowing that an option has

the same value, compilers do not have to make some assump-

tions and the generated code can be improved. Specically,

compilers can further apply optimizations and constant fold-

ing, including the propagation of constants and the removal

of dead code. Secondly, the presence of unused options at

run-time is likely (i) to increase the executable binary size,

since the related code will be included; (ii) can increase the

AVN443 encoder: hps://www.tvbeurope.com/production-post/visionary-

provides-hd-encoders-for-international-space-station.

8A vulnerability: hps://www.cvedetails.com/cve/CVE-2017-12311/.

attack surface (e.g., the number of code-reuse gadgets [

]);

and (iii) even slow down the system. The vision is that the

proactive removal of the unused run-time options can be

benecial to several non-functional properties of software.

To technically support this vision, developers should have

the means to debloat run-time options, for example, by lift-

ing them at compile-time, and thus specialize the original

program. With congurable specialization, developers can

build specialized packages (binaries) out of the specialized

program. For example, one can envision delivering new vari-

ants of

x264

x264-fast

– with fast encoding time,

x264-hq

– with high quality video encoding,

x264-secured

– with

fewer code-reuse gadgets, or

x264-tinyfast

– a small bi-

nary size yet fast

x264

. Importantly, they do not necessarily

specify a full and complete conguration: not all options are

subject to specialization since a part of the variability can

be preserved at run-time for addressing several usages. But,

some of the unneeded options that may improve the non-

functional properties and the performance of the system can

be eliminated from code. Our idea is inspired by the multi-

staged conguration [

] for a step-wise specialization

of variability models. In our case, specialization occurs at

the code level and regarding the run-time options.

3.2 Process for program specialization

To quantify the benets of such a vision, we report in this

paper about our experiments in debloating run-time options

x264

through program specialization (cf. Figure 1). To

achieve our vision, one should be able to specialize

x264

removing run-time conguration options on demand. This

implies removing the parts of source code that implement

such options, which is dierent from simply disabling those

options in a congurator or at the command-line parameter

level. Moreover, to be able to remove the unused run-time

options, they rst need to be located in the source code.

Hence, we propose a removal approach which is based on 4

tasks: (

)we rst comprehend the implementation of run-time

options, then (

)we annotate the corresponding code which

implement a given run-time option, and nally (

)we apply

a partial evaluator taking care of the actual code removal. In

addition to these three tasks, we conducted the last task (

)

which consists in validating the program specialization by

comparing the resulting debloated program with the original

one according to a given conguration of run-time options.

The experiments conducted for these 4 tasks in the con-

text of run-time options in C-based systems, taking

x264

as an illustrative example, are presented in the following.

As a partial evaluator, we decided to use the preprocessor

switches [

] and all the optimizations (e.g., dead code elim-

ination) provided by GCC (in grey in Figure 1). A partial

evaluator is a method for simplifying programs when pro-

gram parameters are known [

]. For instance, when it

is known that a run-time conguration option in a given

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

SpecializationofRun-timeConfigurationSpaceatCompile-time:AnExploratoryStudyXhevahireTërnavaUnivRennes,CNRS,Inria,IRISAF-35000Rennes,Francexhevahire.ternava@irisa.frMathieuAcherUnivRennes,CNRS,Inria,IRISAInstitutUniversitairedeFrance(IUF)F-35000Rennes,Francemathieu.acher@irisa.frBenoitCombemaleUnivRe...

展开>> 收起<<

Specialization of Run-time Configuration Space at Compile-time An Exploratory Study.pdf

共14页,预览3页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

Specialization of Run-time Configuration Space at Compile-time An Exploratory Study

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: