Maxime Bélair
email: maxime.belair@orange.com

Sylvie Laniepce
email: s.laniepce@orange.com

Jean-Marc Menaud
email: jean-marc.menaud@imt-atlantique.fr

Leveraging Kernel Security Mechanisms to Improve Container Security: a Survey

Keywords: Security and privacy → Virtualization and security, Access control, • Computer systems organization → Cloud computing, • General and reference → Surveys and overviews Container, Security, Virtualization, Virtualization Boundary, LSM, NFV

Containerization is a lightweight virtualization technique reducing virtualization overhead and deployment latency compared to full VM; its popularity is quickly increasing.

However, due to kernel sharing, containers provide less isolation than full VM. Thus, a compromised container may break out of its isolated context and gain root access to the host server. This is a huge concern, especially in multi-tenant cloud environments where we can find running on a single server containers serving very different purposes, such as banking microservices, compute nodes or honeypots. Thus, containers with specific security needs should be able to tune their own security level.

Because OS-level defense approaches inherited from time-sharing OS generally requires administrator rights and aim to protect the entire system, they are not fully suitable to protect usermode containers. Research recently made several contributions to deliver enhanced security to containers from host OS level to (partially) solve these challenges.

In this survey, we propose a new taxonomy on container defense at the infrastructure level with a particular focus on the virtualization boundary, where interactions between kernel and containers take place. We then classify the most promising defense frameworks into these categories.

INTRODUCTION

Containerization is a lightweight virtualization technique in which containers are virtual domains offering usermode execution context, while sharing the host kernel at the host level. Containers are isolated from each other and from the host. Containers interact with the host kernel by sending system calls (syscalls) through the virtualization boundary. Compared to full virtualization, containerization reduces virtualization overhead and resource usage, offers reduced deployment latency and finally improves reusability [START_REF] Felter | An Updated Performance Comparison of Virtual Machines and Linux Containers[END_REF]. For these reasons, the popularity of containers in cloud-based environments is quickly increasing with popular tools such as LXC [START_REF] Lezcano | LXC GitHub repository[END_REF], Docker [START_REF] Merkel | Docker: Lightweight Linux Containers for Consistent Development and Deployment[END_REF] or Kubernetes [START_REF]Kubernetes GitHub repository[END_REF].

On the other hand, due to kernel sharing, containers have a greater attack surface than full VMs thus provide less isolation. Therefore, a compromised container may break out of its isolated context and gain access to the host server. For instance, the recent vulnerability CVE-2019-5736 [25] [START_REF] Frichette | PoC for CVE-2019-5736-PoC[END_REF] lets a maliciously crafted container arbitrarily rewrite the containerization's core software (runC, used in most containerization engines) enabling to get full root access over the host, incidentally taking control of the other containers collocated on the node and providing an entry point in the DeMilitarized Zone (DMZ) for further attacks. This risk is also increased by the fact that untrustworthy containers can be downloaded and executed directly from the internet (e.g. Docker Hub). In multi-tenant cloud environments, we can find running on a single server containers serving very different purposes, such as banking microservices, webservers, compute nodes or honeypots. Since companies commonly use thousands or even millions of containers simultaneously, manual defense approaches provided by the administrator are not very practical.

For these reasons, containers with specific OS-level security needs should be able to tune their own security level. But this is not currently possible because OS-level security frameworks generally apply to the whole system meaning that security cannot be applied only to a single container. Because containers are designed to run without administrator rights, they cannot use the numerous already existing tools that require administrator privileges. Finally, because container design differs from full VM or Unix process, related defense approaches are often unsuitable for containers.

Several recent defense approaches try to tackle these issues by leveraging cooperation between the container and the host. Because all the interactions required to setup defense mechanisms must go through the virtualization boundary, it is an interesting point to look at to design security primitives. Therefore, in this survey, we propose a new taxonomy for container OS-level defense at infrastructure level with a strong focus on data transmitted through the virtualization boundary.

If previous studies already featured guides for container defense [START_REF] Souppaya | Application container security guide[END_REF], to the best of our knowledge no study featured a clear container defense taxonomy and especially with the focus of the data transmitted through the virtualization boundary.

In the remainder of this paper, we further present containerization and associated security challenges (2), we then propose a new taxonomy and we classify some of the most promising defense approaches [START_REF] Arnautov | SCONE: Secure Linux Containers with Intel SGX[END_REF]. We explore container security in a use case : Network Function Virtualization (4) and we finally discuss future research directions on container security managed by the host (5).

BACKGROUND: CONTAINERS AND ISOLATION

While modern OSes provide a good level of hardware abstraction and isolation (e.g. a process cannot see the memory of other processes), the level of software isolation remains low, even for nonroot processes (e.g. a process can have information about other processes with commands like ps).

Virtualization is an old technique that improves the level of software isolation of a process (or a set of processes) from other virtualized processes. In early implementations, the whole OS was virtualized, sometimes with extra features such as hypercalls or optimized drivers.

Containerization is a more recent approach than full virtualization providing OS-level virtualization that is, userspace virtualization while abstracting the kernel. In some regards, containers can be seen as a successor of chroot [START_REF]Chroot man page[END_REF], a first attempt to isolate processes. Container's isolation is provided by Linux namespaces [START_REF] Rosen | Resource management:Linux kernel Namespaces and cgroups[END_REF] (providing isolation for pid, mount points, network, ...). Thus a container can be configured to finely sandbox an environment.

In the remaining of this section, we present Linux Security Modules (LSM), a powerful defense framework targeting Linux and the challenges faced by container security at OS-level including why tools like LSM cannot be easily adapted to containers to improve their security.

Linux Security Modules

LSM [START_REF] Wright | Linux Security Modules: General Security Support for the Linux Kernel[END_REF] is a kernel-level security framework initially targeting Linux (i.e. not containers). LSM composes the standard approach to provide orthogonal access control models [START_REF] Sandhu | Access Control Models[END_REF] to Unix's Discretionary Access Control (DAC). LSM design is very flexible and can offer a broad range of security types. These controls are implemented in LSM modules which are built above the LSM framework. Due to their common base, these modules use the same primitives and can be used interchangeably at boot time, although currently, only one major module can be used by the OS, loaded at boot-time. Some of the most widely used LSM modules are:

• SELinux [START_REF] Smalley | Implementing SELinux as a Linux security module[END_REF] provides a file labeling system enabling Mandatory Access Control (MAC) or Role-Based Access Control (RBAC) usage to finely enforce policies. This framework is powerful and flexible yet complex to use. Because labeling has to be done manually, SELinux is not really adapted to cloud environments; • AppArmor [START_REF] Bauer | Paranoid Penguin: An Introduction to Novell AppArmor[END_REF] is another alternative to provide Mandatory Access Control (MAC) or Role Based access control (RBAC).

AppArmor confines individual programs to a set of files, capabilities, network accesses and rlimits. AppArmor is often considered easier to use than SELinux; • Integrity Measurement Architecture (IMA) [START_REF] Sailer | Design and Implementation of a TCG-based Integrity Measurement Architecture[END_REF] provides system integrity enforcement by calculating hash values of specific files and verifying their adherence to expected values. These controls are enforced by a Trusted Platform Module (TPM), a hardware chip widely deployed on modern processors. However, TPM has a limited number of registers, it cannot control an arbitrary number of containers. In its current design, LSM usage and policies enforcement can only be handled by the system administrator.

Technically, the LSM framework provides a convenient set of kernel hooks placed at strategical points. Modules subscribe to these hooks allowing them to execute security code just before an operation of interest is made by a process, such as a file creation or a network packet reception. Thus, LSM modules can take appropriate actions matching policies defined for this particular operation. Because modules are built over the LSM framework, they can dereference kernel pointers (e.g. the second argument of the syscall 'open' is the address of the file path to open) giving them the visibility needed to finely enforce policies. Due to the efficiency of the LSM approach, research is in progress to adapt it to containers, as further detailed in section 3 of this survey.

Container security

As stated above, partially because of the weaker isolation of containers than full-VM environments, containers with specific OS-level security needs should be able to tune their own security level. But, while numerous OS-level or full-VM defense frameworks already exist, they are generally not suitable for container defense due to these limitations [START_REF] Sun | Security Namespace: Making Linux Security Frameworks Available to Containers[END_REF]:

• Mandatory: Administrator rights are required to use these frameworks. Because under normal circumstances, containers do not have administrator rights over the host, they cannot use of the numerous security techniques that require it; • Global: As these frameworks apply to the whole system, they cannot be used to protect only a subset of the system (such as a single container); • Unsuitable for container architecture: By design, container security faces different challenges than full-VM security. A main challenge in full virtualization environments is that the hypervisor does not always know the guest's semantics, thus cannot easily provide security. This problem, known as semantic gap [START_REF] Hebbal | Virtual Machine Introspection: Techniques and Applications[END_REF], is not an issue here as containers share their semantics with the host. Lastly, container adoption is partially due to its good performance compared to full VMs. A significant part of traditional techniques incurs a non-negligible overhead and is therefore not adapted for container defense.

These concerns are particularly evident in LSM modules that cannot be easily adapted to containers due to their mandatory and global design. Additionally, if namespacing the LSM framework itself seems very appealing because it would overcome above concerns and would allow a container to safely use alternate LSM modules, research showed that in its current design, namespacing LSM at framework level is a very hard challenge [START_REF] Johansen | Making Linux Security Modules available to Containers: Stacking and Namespacing the LSM[END_REF] mostly because of the lack of semantics information at framework level and of the use of global variables for networking (e.g. secids, secmark, ...). Due to this limitation at framework level, LSM modules have to handle namespacing by themselves to be useful for container security. Currently, if namespacing is already implemented in Ap-pArmor, allowing both a container and its host to use AppArmor simultaneously, this feature is still under discussion or development for other LSM modules. Therefore, to the best of our knowledge, every adaptation attempt of LSM up to now is either specific to a single module, ad hoc or makes the framework only available to the host. As detailed in the remaining of this paper, the goal of enabling containers to transparently use all LSM modules on their own is not yet reached.

NEW TAXONOMY FOR CONTAINER DEFENSE

In this section, we describe some approaches for the infrastructure (host OS) to improve the security level of a container. We classify these techniques regarding how the data required to setup and enforce security (if any) is transmitted between the container and the host-kernel.

• Configuration-based defense: Policies are defined and enforced solely by the host as a configuration file or string; • Code-based defense: The container pushes code in the host kernel to enforce policies. The kernel executes it when the container makes an operation related to these policies; • Rule-based defense: The container pushes string rules to the kernel. They are interpreted and enforced by a handler in the host kernel. We argue that this taxonomy is complete because either no data is transmitted from the container to the host, and then the defense mechanism is configuration-based, or data is transmitted. In the latter case, either the pushed data is code or not in which case data can be seen as rules.

In the remaining of this section, we further detail these categories. We claim that this categorization clearly underlines the interests and the inherent limitations of these techniques. We also classify some of the main defense frameworks.

Configuration-based defense

The Configuration-based approaches enable the host to customize with a configuration file the properties of a container such as its network interfaces or its mounted directories. Used in most containerization engines, this method is flexible and easily usable from the host. A well-configured container has significantly improved security properties. For instance, Docker provides a way to tune containers' isolation with appropriate command line interface arguments or within the DockerFile. This technique is also heavily used by containers orchestrators. For instance, Marathon [START_REF] Mesosphere | Marathon[END_REF] provides a REST API to manage containers including their security. However, because this technique is static and must be enforced by the host, there is no generic way for a container to handle or update its own configuration. Thus, a container cannot use this approach to enforce its own security policies. Additionally, if this technique may be efficient for a well-known container, it is way more limited to protect an arbitrary container whose behavior is unknown.

Containerization engines already provide ways to use some Linux Security primitives for containers through configuration files or strings. Containerization engines also provide a way to customize rights more finely than root/non-root with capabilities such as "create a port under 1024" or "use the setuid syscall". Efforts are made to further protect individual containers by allowing the host to apply customized LSM modules' policies. For instance, Ap-pArmor [START_REF] Bauer | Paranoid Penguin: An Introduction to Novell AppArmor[END_REF] or Tomoyo [START_REF] Harada | Task Oriented Management Obviates Your Onus on Linux[END_REF] security profiles can be attached to a container and similar work is in progress for other LSMs. These measures provide a first step to container security by enforcing isolation and restricting the attack surface. But this protection remains limited due to i) the restricted number of features available, ii) the fact that only the system administrator can use configurationbased approaches and iii) their static nature (policies are enforced at creation time and cannot be modified by the container).

DIVE [START_REF] De | Integrity verification of Docker containers for a lightweight cloud environment[END_REF] is a very recent approach allowing an orchestrator to check the integrity of a given container on a remote compute node. DIVE relies on a modified version of IMA [START_REF] Sailer | Design and Implementation of a TCG-based Integrity Measurement Architecture[END_REF] supporting containers and a remote attestation framework (OpenAttestation). Container's integrity is checked at host level, that is without any interaction with the container. If a container is compromised, the orchestrator can request the rebuild of this single container (meaning the whole system). Therefore, with the help of DIVE, the infrastructure can periodically check that the hosted containers are not compromised. Yet, since DIVE only monitors files' integrity, it cannot detect any malicious in-memory modifications. As a significant part of attacks, for instance buffer overflows, can lead to in-memory modifications, DIVE in its current form does not satisfy all the security needs of containers.

Cilium [START_REF]Cilium GitHub repository[END_REF] is another framework for network security by making a level 7 proxy usable to further confine containers. It enables to tune for each class of container which access points of a Rest API are accessible. This is particularly useful in microservices environments where a malicious access to poorly designed APIs could lead to attacks such as confused deputy [START_REF] Hardy | The Confused Deputy: (or Why Capabilities Might Have Been Invented)[END_REF]. Because Cilium uses eBPF (extended Berkeley Packet Filter) and can work with XDP (eXpress Data Path), it can improve packet throughput compared to iptables. Yet, Cilium's focus is very tight, so it must be associated with other frameworks to significantly improve security.

Code-based defense

The Code-based approaches enable containers to push code to the host kernel. When the container performs a monitored action on a given object, the container-pushed code is executed to verify the operation's legality. Therefore, this flexible technique allows a container to implement and enforce its own security logic. This technique is especially promising in multi-tenant cloud environments where containers' security needs can be very dissimilar. Because this approach allows a sensitive container to enforce its own policies by defining and pushing code controlling its security to the kernel, it mitigates potential compromises without relying on external tools (which would need to be installed system-wide by the administrator). The most known code pushing technique, called eBPF [START_REF] Anand | A presentation of eBPF[END_REF] is a standard feature of Linux Kernel and is considered as relatively mature. Because the kernel can check the innocuousness of the code pushed by the container but does not modify it, this technique cannot be customized by the host to provide security. However, this technique allows code provided by an untrusted environment to be executed directly inside the host's kernel which could potentially lead to vulnerabilities or Denial of Service (DoS) if not properly sanitized. The sanitization process reduces the possibilities of eBPF code by restricting usable code, forbidding loops, limiting the code size, ... Due to these limitations, very complex inputs cannot be parsed and handled by eBPF. Finally, writing correct and fast defense code can be complex for a standard container user (helpers can sometimes abstract the code generation). [START_REF]Presentation of Seccomp BPF[END_REF] is a sandbox mechanism integrated to the Linux Kernel that permits to tighten container's attack surface by applying policies to syscalls based on eBPF code. But since this code cannot dereference syscall kernel pointers, this filtering remains too coarse grained to significantly improve container's security.

Seccomp-BPF

Landlock LSM [START_REF] Salaun | File access-control per container with Landlock[END_REF] has recently been proposed to let a nonadministrative process (e.g. a container) finely sandbox itself to limit its own rights thus mitigating potential compromises. Landlock limits Trusted Computing Base (TCB) modifications using mature and trusted software (LSM, eBPF) with few modifications. Landlock is designed to be stackable with other LSM modules and mainly provides to unprivileged containers files access control. At high level, Landlock provides a way for non-root containers to push eBPF code in the host kernel, like in seccomp-bpf, but as Landlock is based on LSM framework, it can dereference kernel pointers, thus enabling more precise access restriction. Technically, Landlock setups maps containing the policies to enforce, for instance the access control policy applicable to a particular directory. It then pushes the code in charge of enforcing these policies to the right hooks in the kernel. Thus, at execution, when a monitored operation is executed (e.g open a file), the eBPF code checks its compliance. Yet, Landlock suffers from drawbacks. First, it can only enforce integrity and policies on files (as network cannot be mounted dynamically without administrative rights). Second, the current implementation (v8) requires administrative rights [START_REF] Salaün | Landlock Documentation about administrator rights[END_REF] to create eBPF maps, that limits its interest in real-world scenarios. Finally, writing eBPF program for Landlock can sometimes be complex although Landlock provides an abstraction layer to apply read-write, read-only and deny policies for files. Therefore, Landlock does not satisfy all the security needs of containers on itself.

Rule-based defense

The Rule-based approaches enable containers to push string rules to the host, which are interpreted and enforced by the host kernel. Policies can be expressed as standard strings (e.g. {file:"/etc/passwd", expected:"0xF2A72CC5"}) more easily writable than eBPF code. Therefore, with a such technique, cloud operators keep some control over container security because they can manage the set of security tools a container can interact with. As the host proactively enforces these policies, it can check their legality and their innocuousness at run-time. On the other side, this technique is less flexible than code-based defense because the addition of a new security feature requires kernel recompilation by the administrator. Thus, a container with specific security needs may not have the tools it needs to fulfill its security needs and cannot add its custom policies.

Pledge [START_REF] De | a new mitigation mechanism (Hackfest '15)[END_REF] provides a simple sandboxing mechanism to restrict the behavior of processes (possibly a container), thus mitigating potential compromises. Unlike seccomp-bpf, pledge is based on the allowance of a set of behaviors and not syscalls (e.g. stdio for libc access, rpath for read-only access to files...). These policies are enforced with the help of a new syscall (pledge). Kernel hooks enable to control the syscall legality at usage. Pledge can be called several times to further reduce abilities (because the rights at usage can often be lower than at initialization). Yet, Pledge behavior remains coarse grained and this framework is very specific to OpenBSD.

Security Namespace [START_REF] Sun | Security Namespace: Making Linux Security Frameworks Available to Containers[END_REF] is a recent proposal aiming to enable containers to use LSM modules to improve their own security. Security Namespace does not provide a generic model to adapt LSM modules to containers (which would be difficult since these modules differ greatly in design and details) but offers a "manual" adaptation of some of them (IMA, Apparmor) and aims at providing a model to adapt the others. In order to do that, a new 'Security' namespace abstraction is defined in addition to the seven already existing namespaces. Security Namespace relies on the same mechanisms as the others namespaces (e.g. a flag on syscalls clone, fork or unshare for creation) so it can be used transparently by containers.

A key feature of Security Namespace is the automatic detection and management of inconsistent policies about any file (e.g. readonly vs read-write access) which could lead to a false feeling of security or to a Denial of Service. At system initialization, LSM hooks handlers are installed with an empty list of policies to handle. Policies can then be pushed as string rules from the container to the framework and are appended to the list in the kernel. When an operation is made over a resource, every Security Namespace that has visibility over it checks the conformity to the policy. The access is granted only when allowed by all these Security Namespaces. Because Security Namespace requires intensive modifications over kernel base and the LSM modules to use these modules and works with only a subset of LSM modules (i.e. no genericity), it cannot be seen as a general solution to container security in its current implementation. The first column shows whether the framework is configurationbased (C), code-based (X) or rule-based (R). We remind that configuration-based approaches allow the host to define and handle containers' protection on its own while code-based and rule-based approaches allows the container to initiate a "demand" of protection, fulfilled by the host kernel. The second column shows whether the technique provides fine or coarse grained security (e.g. for a framework monitoring syscalls: whether it can restrict syscalls to precisely match a defined behavior). Customizability column [START_REF] Arnautov | SCONE: Secure Linux Containers with Intel SGX[END_REF] shows whether the approach can provide further protection services that it was not explicitly designed for. Because Landlock and Seccomp-BPF enable (within some restrictions) to push any valid BPF code to the host, thus, they can provide a further customized security service while other approaches have a fixed set of features. The following column (4) shows whether policies are defined directly in the software to be protected (e.g. the task running in a container), meaning source code modifications are required to enforce policies in this software. Because Pledge and Seccomp-BPF provide mechanisms for a process to confine itself while other frameworks confine a full environment, modifications have to be made directly in the source code of this software and thus are less suitable to protect closed-source software. Genericity and integration column [START_REF] De | Integrity verification of Docker containers for a lightweight cloud environment[END_REF] shows whether the framework has been designed in a generic way, is well integrated into production environments and is usable in real life scenarios. For instance, in its current version, Landlock actually requires administrator rights to work thus limiting its usability in production where containers run in usermode. Overall, despite no solution provides a general solution to all security concerns related to containers, some frameworks cover a broader scope than others, as shown in the last column [START_REF] De | a new mitigation mechanism (Hackfest '15)[END_REF].

Recap chart

C DIVE [5] C Cilium [19] C Seccomp-BPF [11] X Landlock [28] X Pledge [6] R Security NS [35] R
The following section illustrates why leveraging techniques presented in this survey can be needed for containers and how they can help to improve their security level in a use case, namely Telecom's Network Function Virtualization (NFV).

USE CASE: CONTAINER-BASED NETWORK FUNCTION VIRTUALIZATION

Telecom networks used to contain a broad range of proprietary hardware appliances such as routers, firewalls or carrier-grade NAT (Network Address Translation) that need to be deployed, operated and updated physically, leading to complexities in the architecture.

NFV is an inexorable trend consisting in virtualizing and centralizing these appliances into industry standard compute servers to simplify these architectures, reduce costs and improve overall reliability. In such a scenario, each appliance is virtualized into a (set of) full VM(s) specialized in a specific task. But, due to container's greater performance and flexibility, containerization receives more and more attention to virtualize network functions in research environments.

Nevertheless, because data handled in NFV environments come directly from untrusted and potentially malicious users, NFV security remains not perfect and any compromise may have a strong impact on the operator's infrastructure and incidentally on users (e.g. the theft of users' network history). Due to these concerns and because of NFV's restrictive standards, the use of containers remains very limited in production environments.

Operators should therefore leverage additional security measures to get enough confidence in their architecture to safely use containers and take advantage of their improved properties. In NFV environments, Telecom operators operate their own infrastructure with administrator rights (unlike in multi-tenant cloud environments). Therefore, with NFV, they have a higher flexibility to use cutting-edge security frameworks including these presented in this paper, even these requiring administrator rights. Therefore, adapting container security to NFV environments seems to be a promising line of application.

As shown in this survey, defense can be initiated either by a container or by the host. We show here that both ways can be relevant to protect containerized NFV networks. It has to be understood that these two approaches are not exclusive and an operator willing to perform defense in depth should consider both.

NFV containers can be protected without interaction with the host using configuration-based tools (i.e. the security is initiated and enforced by the host). With such techniques, the infrastructure is able to finely tune the NFV isolation, integrity and access rights. This can be done not only by configuring namespaces and tuning DAC access, but also by integrating additional Access Control Models, filtering network accesses at OSI level three or seven, ... Configuring the defense of a well known and documented NFV is not a complex process since its behavior is known, it is possible to restrict NFV capacities to the minimum without altering its operation. This process can be more complex for greybox NFVs where configuration attempts have to be done "blindly" and could for instance block an exceptional but essential case resulting in an incorrect behavior and a false positive.

Additionally, NFV containers can proactively participate to their own defense (relying on security primitives delivered by the host) leveraging code-based or rule-based defense to improve their confidence in their security. With such an approach, containers can use on their own security tools (based on the LSM framework or not) exposed by the host. They can also execute an 'arbitrary' policy code with mechanisms such as eBPF thus achieving very high flexibility. Besides defense in depth, third parties sometimes deliver NFV as greybox containers. In this case, security policies have to be defined by the third-party because it would be challenging (and sometimes contractually forbidden) for an operator to reverse-engineer the greybox NFV to define security (the operator remains in charge of comprehensively testing the containers). Thus, although it can seem intuitive to use only host-defined policies to centralize security, this is not always possible nor desirable. For instance, a third party might want to be guaranteed that the security policies he defined are enforced. A way to achieve this is to enforce them from the container, therefore with code-based or rule-based techniques.

In conclusion, container security is a strong problematic for a broad range of industries, such as Telecom relying in NFV. Because container security approaches still have some limitations (as shown in section 3), research have to be made to overcome them.

DISCUSSION AND FUTURE WORKS

In this paper, we presented a new taxonomy for container security with a particular focus on data transmitted through the virtualization boundary. We showed that each type of defense offers distinct features and does not have the same limitations. We believe that our classification can help understanding and designing new security features for containers. To the best of our knowledge, this is the first study of its kind.

Containerization is still a relatively young and evolving technology but is widely used in cloud environments. However, its security is still in an early phase and faces unsolved challenges.

Making LSM usable by individual containers would significantly improve their security and is therefore a promising line of research. This remains a hard problem as LSM modules are very diverse, regarding their objectives, architecture and implementation details. Some research aim to design a new namespace to generically handle security. Another line of research which remains to be explored is to rethink LSM architecture to ease its integration with containers.

Some approaches aim to design hybrid abstractions with the advantages of both containers and Light VMs. For instance, gVisor [START_REF]GVisor GitHub repository[END_REF] creates a new container abstraction in which a userspace kernel checks and proxies syscalls to the host kernel, improving security at the cost of size and performance overheads and reduced syscall compatibility. Lighter VMs and optimized hypervisors that are competitive in performance with containers while keeping better isolation and security properties are also proposed [1][10]. Finally, some approaches [START_REF] Manco | My VM is Lighter (and Safer) Than Your Container[END_REF][32] create new abstractions usable like containers but internally using library OS [START_REF] Engler | Exokernel: An Operating System Architecture for Application-level Resource Management[END_REF], allowing greater performance and tightened attack surface but remain complex to use and often require to fully rewrite software.

Complementarily to kernel-level defense, some approaches aim to improve container security by interacting directly with the hardware. For instance, Scone [START_REF] Arnautov | SCONE: Secure Linux Containers with Intel SGX[END_REF] enables containers to deport critical code execution into a secure "enclave" leveraging Intel Software Guard eXtension (SGX) [START_REF] Hoekstra | Using Innovative Instructions to Create Trustworthy Software Solutions[END_REF]. This mechanism allows to protect containers from a malicious host. Yet, Scone incurs a high overhead and requires non-trivial software modifications. Finally, due to critical vulnerabilities found in SGX [START_REF] Schwarz | Practical Enclave Malware with Intel SGX[END_REF] cloud operators may want to disable SGX, incidentally disabling Scone.

Figure 1

 1 Figure1provides a comparison of the security frameworks above presented.

Figure 1 :

 1 Figure 1: Comparison of security frameworks


C Bruggeman

M Altmaier

D Bosbach

S Churakov

D Galson

Bernd Grambow

F Mcevoy

Th Stumpf

"EURADSCIENCE", A NETWORK OF RESEARCH ORGANISATIONS FOR RADIOACTIVE WASTE MANAGEMENT SCIENCE WITHIN EUROPE

published or not. The documents may come

• Link also to academia -Some TSOs, identified as research organisations, if interested

• VTT, CIEMAT

• Currently, 28 members from 14 countries

• National research centers, universities/academia, radwaste R&D programme managers, small and medium enterprises

EURADScience structure Research organisations' interest in EURAD

• Embedding techno-scientific research in a progressively demanding societal context -Serving society with independent science/building confidence and credibility in radioactive waste management -Define state of the art in understanding of system components behaviour, beyond national programme boundaries -Building confidence in safety assessments and underlying scientific assumptions for many decades to come

• EURAD as a tool for Building a European knowledge platform on waste disposal

-

  , D.BOSBACH, S.CHURAKOV, D.GALSON, B.GRAMBOW, F.McEVOY, Th.STUMPF The role of research organisations Research organisations grouping -a brief history of time • Embedded within the EURATOM Framework Programmes • From single partner to multi partner contracts • Continued efforts for collaboration in large integrated projects • Implementation-driven projects become the new standard • From JOPRAD to EURAD -the new era of Joint Programming • Research organisations recognised as independent mandated actor group Courtesy of C.Davies, EC, DG RTD • Key challenge: continuously developing the scientific frontier in view of the extremely long timescales associated with the generation and storage of radioactive wastes, and the development, operating and closing of geological repositories • Vision: To act as an independent, cross-disciplinary, inclusive network ensuring scientific excellence and credibility to radioactive waste management Why RE grouping? -Mission Mission: • Research organisations are at the centre of developing a longterm vision for the scientific and technical challenges that are inherently linked to safe waste management and disposal, beyond national borders and specific implementation programmes • Research organisations have a primary focus on long-term knowledge management and development, and are key to maintaining competence and know-how • Nationally funded research organisations identified as Mandated Actors within EURAD form the membership of the Research Entities College -EURADScience will support the functioning of this college To work inclusive towards mandated actors within EURAD • Importance with respect to EURAD governance -To selectively involve other research organisations • Setting up a structure and reflection on role of the grouping -Transparency • Invited research organisations -Formally mandated actors under EURAD • 20 individual organisations -Linked Third Parties, identified as (important) research organisations

-

  Safeguarding existing knowledge and attracting next generation of experts • EURAD as a tool for structured, long-term R&D commitment -Develop and maintain high-level research infastructures across Europe -Continuously further develop scientific knowledge promoting confidence building and keeping up to speed with scientific progress in a pro-active manner • Structured communication and interaction with other Platforms (IGD-TP, SITEX, waste producers) -Multilateral rather than bilateral Updating the Strategic Research Agenda • Focus shift from "geological disposal" (JOPRAD) to "from cradle to grave" (nuclear back-end, EURAD), including -Pre-disposal activities -Legacy waste, including small (problematic) inventories -(Near-)surface disposal -(New) nuclear developments Holistic view on nuclear activities • Providing and developing cutting-edge nuclear research facilities and instrumentation (for applied and fundamental scientific studies) • Attracting young scientists' interest (educating and training of next generation experts) • Re-thinking priorities in view of EURAD research programme Updating the Strategic Research Agenda • Some examples (non-exhaustive, non-binding) -Innovative fuels (ATF fuels and claddings) -Innovative waste forms (ceramic, geopolymers, plasma, spray coatings, organo-mineral composites, etc.) -Innovative waste disposal concepts (including effect of next generation fuel cycles) -Natural analogues/site-specific analogues -Biosphere models and impact of climate change/extremely long time scales -Further development of complete, transparent and quality assured thermodynamic databases -Linking bottom up to top down approaches using very complex systems, including mineral assemblages, competition effects, micro-organisms, redox, colloids -Develop and evaluate concepts and methods for handling (including retrieving), characterization, treating, conditioning, storing and re-disposal of historical (very old) wastes -Integral experiments (including mock-ups) -Deep Borehole disposal -Atomistic simulations and how they can contribute to the safety case • Networking and sustaining the European research infrastructures

Development of a Strategic Research Agenda

-Representatives from advanced and less advanced programmes


Joachim Delannoy

Suzanne Lafon

Yukina Koga

Etienne Reyssat

David Quéré

Étienne Reyssat

The dual role of viscosity in capillary rise

Washburn's law classically describes the dynamics of wetting liquids inside porous media [START_REF] Washburn | The dynamics of capillary flow[END_REF]. It predicts that the position of the liquid front increases as the square root of time, as long as gravity can be neglected. As also discussed by Bell and Cameron [START_REF] Bell | The flow of liquids through capillary spaces[END_REF], and by Lucas [START_REF] Lucas | Ueber das Zeitgesetz des kapillaren Aufstiegs von Flüssigkeiten[END_REF], this law, first established in the simple geometry of capillary tubes, results from a balance between the driving capillary force and viscous friction along the walls.

Denoting the meniscus position and velocity as z and 𝑧, the tube radius as r and the liquid surface tension and viscosity by 𝛾 and 𝜂, these two forces respectively scale as 𝛾r and 𝜂z𝑧, whose balance leads to Washburn's equation:

𝑧 𝑡 ~ 𝛾𝑟𝑡 𝜂 !/! (1)
In the case of partial wetting (characterized by the contact angle 𝜃0 > 0 made by the liquid on the tube wall), the driving force is weakened by a factor cos 𝜃0, which yields a dynamics slowed down by a factor cos 1/2 𝜃0, compared to eq. ( 1). Washburn's law is famous for many reasons: (1) Beyond the simple case of tubes, it generally describes the impregnation of much more complex media such as paper, fabrics, sand and rough surfaces [START_REF] Perwuelz | Experimental Study of Capillary Flow in Yarns[END_REF][START_REF] Lago | Capillary rise in porous media[END_REF][START_REF] Marmur | Kinetics of penetration into uniform porous media: Testing the equivalentcapillary concept[END_REF][START_REF] Nia | Theoretical Analysis of Capillary Rise in Porous Media[END_REF]. [START_REF] Bell | The flow of liquids through capillary spaces[END_REF] It allows in principle to deduce a characteristic radius of invasion from impregnation dynamics, or, if the latter quantity is already known, the contact angle inside the porous medium [START_REF] Marmur | Characterization of porous media by the kinetics of liquid penetration: the vertical capillaries model[END_REF][START_REF] Bachmann | Extended methodology for determining wetting properties of porous media[END_REF]. (3) It clearly highlights the efficiency of impregnation at small distance z, as qualitatively observed when a liquid (ink for instance) contacts porous structures (paper for instance).

The dynamics at short time and short scale must be questioned, since eq. ( 1) predicts an unphysical diverging velocity in this limit. As first discussed by Bosanquet [START_REF] Bosanquet | On the flow of liquids into capillary tubes[END_REF], the viscous dynamics is preceded by an inertial regime during which liquid is brought in motion. Neglecting the liquid viscosity and the influence of gravity, the dynamics in this regime results from a balance between inertia (scaling as 𝜌𝑟 ! 𝑧 ! ) and capillary force (scaling as 𝛾r), which yields a constant meniscus speed c ~ (𝛾/𝜌𝑟) !/! [START_REF] Quéré | Inertial capillarity[END_REF], a velocity of typically 10 cm/s in millimetric tubes. The transition towards the Washburn regime happens when both dynamics cross, that is, after a time 𝜏 ~ 𝜌r 2 /𝜂 [START_REF] Fries | The transition from inertial to viscous flow in capillary rise[END_REF]. This time can be reinterpreted as the time necessary for the viscous boundary layer to diffuse across the tube width, and it is easily observable for wide tubes (at least millimetric, or even larger as found in microgravity environment) and for liquids of low viscosity such as water and light oils. Conversely, we expect the inertial regime to be almost invisible in very thin tubes and/or for viscous liquids. In a millimetric tube, for instance, with an oil 300 times more viscous than water, the time 𝜏 is 3 ms, and the corresponding spatial extension c𝜏 is only a fraction of a millimeter -making this regime undistinguishable from the establishment of the meniscus at the onset of the rise.

However, the beginning of the rise of a viscous wetting liquid in a millimetre-wide tube is far from obeying Washburn's law. The experiment, sketched in figure 1a, consists in following the meniscus height z (defined between the bath level and the bottom of the rising meniscus) after making a vertical glass tube (inner radius r = 0.5 mm) contact a bath of viscous silicone oil (𝛾 = 21 mN/m, 𝜌 = 980 kg/m 3 , 𝜂 = 350 mPa.s and 𝜃0 = 0). As seen in figure 1b (red curve), the rise is slow (two minutes are necessary to reach the equilibrium height of 8 mm), but it constantly deviates from Washburn's law. The beginning of the rise, specifically, is observed to take place at a finite and constant velocity (of ~1.7 mm/s) in contradiction with the prediction of eq. ( 1). This observation is confirmed by plotting the same data in logarithmic scales (inset in the figure): the first second of the rise indeed obeys a scaling law with exponent 1, as highlighted by a dotted line, confirming the existence of a regime of constant speed at short time. Interestingly, Washburn briefly noted in his original paper that he needed to precoat the tubes with a thin liquid film to get a satisfactory agreement between data and theoretical expectations. Such films can be deposited by moving a slug of oil inside the tube with a well-defined velocity, allowing us to control the film thickness [START_REF] Bretherton | The motion of long bubbles in tubes[END_REF] (see the supplementary information). If performing the same capillary rise experiment as

previously, yet in a tube precoated by a film of silicone oil with a thickness ε = 24 µm (much smaller than the tube radius r), we observe an impressively enhanced dynamics of the rise at all scales (blue data in figure 1b): after one second, the meniscus is about twice higher than in a dry tube, and the final equilibrium is reached in about 40 s, that is, three times quicker. However, the same data plotted in logarithmic scales reveal that the very beginning of the rise still (yet more briefly) takes place at a constant speed, but this speed is now 7.2 mm/s, larger by a factor ~4 than previously. In both cases, the Washburn regime is not observed, because the linear rise brings the meniscus at a height such that gravity becomes significant, another source of deviation from eq. ( 1)

where it is neglected. This can be circumvented by using a thinner tube, as reported in figure 1c, where we report the rise of a silicone oil with viscosity 𝜂 = 50 mPa.s in a tube twice thinner (r = 0.23 mm) either dry (red data) or prewet by a film of thickness 𝜀 = 4 µm (blue data). Dynamics remains quicker in the prewet tubes, but the log-log plot displayed in the inset reveals that the regime of constant speed has significantly shrunk in the dry case, and even became invisible in the wet case, so that Washburn's law (the dashed line with slope 1/2 drawn in the figure) can now be observed. Our experiments thus show that dry tubes of millimetre-size diameter are invaded by viscous liquids at a constant velocity V, which corrects the singular character of Washburn's law at short time, yet without influence of inertia -always negligible at the scale of our experiments. This regime appears more clearly in the case of dry tubes (where it concerns typically the first millimetre of the rise), even if it can also be observed at smaller scales in prewet tubes, which makes us suspect a viscous origin for the effect. This is confirmed in figure 2, where we plot the meniscus velocity V at short time (deduced from plots such as figure 1) as a function of the oil viscosity 𝜂 varied by a The meniscus velocity V decreases as the oil becomes more viscous, from ~11 mm/s (for 𝜂 = 50 mPa.s) to ~0.5 mm/s (for 𝜂 = 1000 mPa.s). The corresponding Reynolds numbers defined at the scale of the tubes, Re = 𝜌Vr/𝜂, range between 5.10 -4 and 10 -1 , which confirms that inertia can be neglected. Conversely, the logarithmic scales in figure 2 evidence that V decreases as 1/𝜂, confirming that the capillary action is opposed in this regime by a viscous force. Interestingly, data obtained at a given viscosity with tubes of radii varying between 0.13 and 0.70 mm nearly superimpose, which suggests a local viscous dissipation instead of the global one assumed in Washburn's law (eq. 1).

Dissipation indeed also happens close to the moving contact line, at the scale of the meniscus, whose motion is accompanied by a deformation so as to form a dynamic contact angle 𝜃(V), as sketched in figure 1a. Illuminated with white light from below, the meniscus is observed in the time-lapse photograph of figure 3a to rise at constant velocity with a flattened shape whose stationary nature is evidenced by its identical apparent thickness. We subtracted in this image the outside meniscus that may mask the field of interest, and highlighted the tube walls with red lines. At larger scale, that is, later (figure 3b), the meniscus slows down markedly (the constant spacing in the figure In the linear regime, the local balance of forces determines θ, which in turn sets the meniscus velocity V -both found, consistently, to be constant in this regime (figure 3a).

Approximating the contact line region by a wedge with (small) apparent angle 𝜃, as sketched in figure 4a, the shear stress scales as 𝜂V/𝜃x, where x is the distance to the wedge tip. Integrating the latter formula with respect to x and along the tube perimeter yields a friction Fw ≈ 𝜂rV/𝜃 ln r/𝜀, where the macroscopic and microscopic cutoff lengths r and 𝜀 in the logarithmic term respectively correspond to the meniscus size and to the thickness of the film on which the wedge advances [START_REF] Snoeijer | Moving contact lines: scales, regimes and dynamical transitions[END_REF]. The way the dynamic angle 𝜃 in Fw depends on V is classically obtained by balancing Fw by the capillary force Fc ≈ 𝛾r (1cos 𝜃) opposing the viscous deformation of the wedge. At small angle 𝜃, this balance yields Cox-Voinov-Tanner law [START_REF] Tanner | The spreading of silicone oil drops on horizontal surfaces[END_REF][START_REF] Cox | The dynamics of the spreading of liquids on a solid surface. Part 1. Viscous flow[END_REF][START_REF] Voinov | Hydrodynamics of wetting[END_REF], that is, 𝜃 3 ≈ 𝜂V/𝛾 ln r/𝜀, which makes explicit the viscous friction in the wedge, Fw ≈ r 𝛾 1/3 (𝜂V ln r/𝜀) 2/3 , and highlights its non-linear character in velocity. We have two ways of expressing the macroscopic balance of forces governing the dynamics of the rising column. (1) On the one hand, a consequence of the wedge friction Fw is to modify the Laplace pressure responsible for the rise, owing to the generation of a dynamic contact angle 𝜃 at the front, as sketched in figure 1a. The modified Laplace force 𝛾r cos 𝜃 can then be balanced by the Poiseuille friction in the column FP ≈ 𝜂z𝑧, which yields an equation for the rise dynamics. (2) On the other hand, an elementary jump of the stationary meniscus by a quantity dz in figure 4a suppresses a surface area of liquid scaling as rdz, corresponding to a decrease of surface energy 𝛾rdz -hence a driving force scaling as 𝛾r. Conversely, we have to consider two viscous frictions, that in the wedge, Fw, and that in the column, FP ≈ 𝜂z𝑧, and the force balance on the liquid column can be written: γr ≈ Fw + FP. Since the wedge friction is itself balanced by the capillary force Fc ≈ 𝛾r (1 -cos 𝜃), we recover the expression derived in [START_REF] Washburn | The dynamics of capillary flow[END_REF].

Assuming that the wedge friction dominates the global Poiseuille friction at short time (Fw >> FP), the balance of forces becomes: 𝛾r ≈ Fw ≈ r 𝛾 1/3 (𝜂V ln r/𝜀) 2/3 , which provides the initial meniscus velocity:

𝑉 ≈ 𝛾 𝜂 ln 𝑟/ε (2) ! V " y r (b) # h # V " x y z (a)
r A dominant dissipation in the meniscus leads to a constant velocity of propagation, in agreement with the observations in figures 1, 2 and 3. For an initially dry tube and a wetting liquid, the film is typically a precursor film propagating ahead of the meniscus, hence with a molecular thickness (𝜀 ≈ a ≈ 1 nm) [START_REF] Leger | Liquid spreading[END_REF]. In such conditions, the coefficient ln r/𝜀 ranges from 12 to 13 as the tube radius varies between 0.13 mm and 0.7 mm and its logarithmic nature makes it quite insensitive to the size chosen for its thickness (in the range of a few Angströms). This term lowers the visco-capillary speed 𝛾/𝜂 in eq. ( 2) by about one order of magnitude. For a silicone oil with a viscosity 𝜂 = 350 mPa.s, our scaling argument predicts V to be typically 5 mm/s, comparable (yet slightly larger) than reported in figures 1b and 2.

Equation ( 2) also explains why the meniscus will initially move faster in prewet tubes.

The prewetting film can be seen as a thick precursor of the meniscus, which lowers the logarithmic factor and thus increases the speed. For a film whose thickness is typically 20 µm, the term ln r/𝜀 is reduced by a factor 4 (compared to ln r/a), which multiplies the speed V by the same amount, in agreement with the observations in figure 1. In any case, the velocity V remains much smaller than the inertial velocity (𝛾/𝜌r) 1/2 ≈ 10 cm/s, which underlines once again the negligible role of inertia in our experiments.

The range of the viscous linear regime, before the Washburn behavior, can finally be discussed. The global Poiseuille force FP ≈ 𝜂z𝑧 is negligible compared to the line friction Fw ≈ r 𝛾 1/3 (𝜂V ln r/𝜀) 2/3 as long as the travelled distance z is smaller than L ≈ r ln r/𝜀, a length sensitive to the state of the tube (dry or prewet), and typically of millimetric amplitude, as found experimentally (insert in figure 1b). L is roughly proportional to r, which explains why the linear regime is significantly longer in figure 1b than in figure 1c. Moreover, these arguments justify why Washburn did not observe this regime, in experiments where tubes were thin (r = 0.15 mm) and prewet -making the distance L smaller than here by one order of magnitude. More generally, the radius r is micrometric in many experiments reported in the literature (especially those with porous media), which makes the linear viscous regime macroscopically unobservable.

We expect from eq. ( 2) an initial capillary number Ca = 𝜂V/𝛾 ≈ 1/ ln r/𝜀, ranging between 0.07 and 0.09, about 3 times larger than the value measured in figure 2 (Ca = 0.03). We can describe the moving meniscus in a more accurate way (figure 4b). As originally performed by Voinov [START_REF] Cox | The dynamics of the spreading of liquids on a solid surface. Part 1. Viscous flow[END_REF], it is obtained by balancing the capillary pressure with the normal stress exerted by the flow on the free surface. The bending of the interface induces a Laplace pressure in the fluid pc = 𝛾 sin 𝛼 d𝛼/dy where 𝛼(y) is the angle between the liquid-gas interface and the solid at a distance y from the tube walls (figure 4b). As shown by Moffatt [START_REF] Moffatt | Viscous and resistive eddies near a sharp corner[END_REF], the motion in a liquid wedge induces a pressure on the free surface pf = 2𝜂V/y sin 2 𝛼/(𝛼 -sin𝛼 cos𝛼) (see also the SI). The balance pc = pf can be integrated between 𝛼 = 0 for y = 𝜀 (at the top of the meniscus) and 𝛼 = 𝜃 for y = h, the local thickness of the dynamical meniscus. We deduce an equation relating 𝜃 and h for a given velocity V:

𝑉 = 𝛾 𝜂 ln ℎ/ε α -sin α cos α 2 sin α dα ! ! (3)
In the limit of small 𝜃, eq. ( 3) reduces to the classical Cox-Voinov law: 𝜃 3 ≈ 9𝜂V/𝛾 ln h/𝜀, an approximation that holds up to 𝜃 < 3𝜋/4 [START_REF] Voinov | Hydrodynamics of wetting[END_REF]. In the geometry of a tube, we can plug the condition 𝜃(r) = 𝜋/2 in eq. ( 3), which provides an analytical expression for the velocity V:

𝑉 𝜀 ≈ 𝜋 ! 72 𝛾 𝜂 ln 𝑟/ε (4)
We recover the scaling expression (2) with a numerical coefficient ∼0.43, so that the capillary number 𝜂V/𝛾 of the initial rise is expected to range between 0.032 (for r = 0.70 mm) and 0.037 (for r = 0.13 mm), as typically observed in figure 2. In these experiments, the tube radius is roughly varied by a factor 5, which, according to eq. ( 4), only modifies the rising velocity by 15%, -in agreement with the very small variations observed in figure 2 and found to highlight the local character of the dissipation in this regime. Put together, eqs. ( 3) and ( 4) yield 𝜃 ≈ 𝜋/2 (ln h/𝜀 / ln r/𝜀) 1/3 , which depicts that 𝜃 quickly approaches 𝜋/2 even at small thicknesses h. For instance, we expect 𝜃 ≈ 0.4𝜋 for h = 1 µm in a dry tube (𝜀 ≈ 1 nm) with radius r = 0.5 mm. Hence we understand the meniscus flatness observed in figure 3a to be a hallmark of the early viscous regime.

We can be more quantitative by looking at the way the meniscus velocity depends on the thickness 𝜀 of the prewetting film, which is expected from eq. ( 4) to be a logarithmic variation. The thickness 𝜀 can be varied much more broadly than the tube radius, firstly between dry tubes (for which we expect a nanoscopic precursor film 𝜀 ≈ 1 nm) and prewet tubes (𝜀 ≈ 10 µm); secondly, in the wet regime where 𝜀 can be easily tuned by changing the inclination of the tube during precoating: by modifying the advancing speed of the prewetting slug, we could vary the coating film thickness 𝜀 from 1 µm to 24 µm (see the SI). For each thickness 𝜀, we can measure the initial speed V of the rise, which is displayed in figure 5. We observe two main facts: (1) The meniscus velocity V jumps from 1.7 mm/s for dry tubes (red dots) to 3.7 mm/s for the thinnest coating (𝜀 ≈ 1 µm), in agreement with our model that predicts that the velocity should double when the film thickness increases from 1 nm (precursor film on a dry tube) to 1 µm (prewetting film). (2) The meniscus velocity is a slowly increasing function of the coating thickness that roughly doubles when multiplying the coating thickness by a factor of 25, again in full agreement with expectations: without any adjustable parameter, eq. ( 3) is observed in figure 5 to nicely describe the slow rise of the velocity V as a function of 𝜀, even if it slightly overestimates it at large 𝜀. In this limit, as stressed earlier, the range of the viscous linear regime is limited, and the accuracy of the measurements consequently decreases: the transition to the Washburn regime occurs early, which might explain why the observed velocity is found in this limit to be systematically (slightly) below the expectations.

In summary, we showed in this paper that the capillary rise of viscous liquids is first linear in time. We interpreted this observation by considering the friction close to the moving contact line, whose local character explains the existence of an initial, finite speed of rise. This system offers a unique opportunity to test a specificity of the hydrodynamic model of line friction, that is, its celebrated logarithmic divergence (eqs. 2 and 3). By varying the thickness of the film on which the meniscus progresses, we could probe the logarithmic factor of Voinov's model -a factor treated here not as an adjustable parameter (as it is most often in the literature) but as a physical quantity whose content can be varied and tested. The agreement between the model and the experiments was found to be quantitative -a valuable information in a field where such direct observations are rare. liquid-gas interface, which implies f'(0) = 1, f(0) = 0, f(𝛼) = 0 and f''(𝛼) -f(𝛼) = 0.

Solving the Stokes equation with these boundaries conditions for 𝜓 = V r f(𝜃) yields:

𝜓 = 𝑟𝑉 𝛼 sin 𝜃 -𝜃 sin 𝛼 cos 𝜃 -α 𝛼 -sin 𝛼 cos 𝛼 ≡ 𝑟𝑉. 𝑔 ! 𝜃 (SI.1)
where we introduced the function g𝛼 for clarity. The pressure gradient obeys ∇p = 𝜂∆u, and its projection along the radial coordinate is:

!" !" = 𝜂 ! ! ! ! !! ! + ! ! ! ! ! ! ! !! ! + ! ! !! ! !" - ! ! ! !! ! !! - ! ! ! ! = !" ! ! [𝑔 ! ! 𝜃 + 𝑔 ! ! 𝜃 ] (SI.2)
Integrating along r at the liquid-air boundary (𝜃 = 𝛼) gives the pressure induced by the fluid motion on the moving interface:

𝑝 ! 𝛼 = - !" ! 𝑔 ! ! 𝛼 + 𝑔 ! ! 𝛼 = !!! ! !"# ! ! !!!"# ! !"# ! (SI.3)
where y = r/sin 𝛼 represents the local thickness of liquid as defined in figure 4b.

Prewetting the tubes

In order to prewet the tube walls, we place a slug of oil with centimetric length l and tilt the tube by an angle 𝛽 with respect to the vertical. The slug reaches a steady state as its weight ~𝜌r 2 lg cos 𝛽 is balanced by the viscous friction ~𝜂lU, where U is the slug velocity that can be controlled by the inclination of the tube (figure SI.2 (a)). For each experiment with prewet tubes, we measure the velocity U by timing the descent in tubes of known length. The thickness 𝜀 of the deposited film is then calculated using Bretherton's formula 𝜀 = 1.34 r (𝜂U/𝛾) 2/3 [START_REF] Bretherton | The motion of long bubbles in tubes[END_REF]. As seen in figure SI.2 (b), 𝜀 can also by deduced from the shortening ∆l of the liquid slug along its descent. In this case, we measure 𝜀 = r ∆l/2U∆t = 21 µm, in good agreement with the value expected using Bretherton's formula, that is, 22 µm. When the drop reaches the end of the tube, we remove it gently by absorbing the oil with a paper, and then perform the experiment presented in figure 1 with the other side of the tube.

Meniscus shape and macroscopic contact angle

Eq. 3 is an implicit equation between h and 𝜃 = dh/dx that we can integrate using a numerical solver (such as ode15i with MATLAB). The shape of the meniscus depends on its velocity, whose initial value is given by eq. 4: V ≈ 𝛾𝜋 3 / (72 ln r/𝜀). Later, the meniscus speed 𝑧 decreases during the rise because of bulk viscous dissipation and gravity. We sketch the meniscus in figure SI3, where we highlight the coexistence of dynamic and static parts drawn with solid and dashed lines, respectively. . Sketch of the matching between the static and dynamical part of the meniscus. On the left part of the sketch, the static meniscus is a portion of sphere with radius of curvature r* while the dynamic meniscus is described in SI1. The matching between the two menisci is done for y = h and 𝛼 = 𝜃, when the two curvatures balance.

The size h of the dynamical meniscus can be obtained from the matching of the curvatures between the part influenced by the flow and the static part of the meniscus (with a spherical shape of radius r*). The curvature induced by the flow in the dynamical part is 2Ca sin 2 (𝛼)/y(𝛼 -cos 𝛼 sin 𝛼) (see SI1) and it is 1/r* = cos 𝜃/(r -h) in the static part of the meniscus, which yields:

ℎ = 2 𝐶𝑎 𝑟 -ℎ !"# ! !"# ! !!!"# ! !"# ! (SI.4)
Using eq. ( 3), we obtain an implicit equation between h and 𝜃 for a meniscus advancing on a film of thickness 𝜀 in a tube of radius r.

ℎ !" ! ! !!! = !"# ! !"# ! !!!"# ! !"# ! !!!"# ! !"# ! ! !"# ! dα ! ! (SI.5)
Combined with eq. SI4, we obtain a relation between the angle 𝜃 and the thickness of the dynamical meniscus h with the velocity of the meniscus (figure SI4). 4) for a meniscus advancing on film of liquid of thickness 𝜀 = 1nm.

The size of the dynamical meniscus h approaches r as the meniscus velocity 𝑧 is close to the initial velocity V (defined by eq. 4). As the meniscus slows down, the size h of the dynamical region rapidly becomes small whereas the angle 𝜃 is still rather large. For instance in a tube of radius 0.7 mm, when the velocity has decreased by a factor 2, the thickness of the dynamic meniscus is h ≈ 100 µm and the contact angle 𝜃 is above 𝜋/3 a consequence is that 𝜃 appears as a macroscopic contact angle, that depends on the meniscus velocity. We recover in figure SI5.a the shape of the dynamic meniscus with eq. 3 (y < h(𝑧), solid line), and the static part of curvature r* = [r -h(𝑧)]/cos 𝜃(𝑧) (y > h(𝑧), dashed line).

We can also retrieve the global behavior of the rising liquid column: the meniscus is driven by a force 2𝜋𝛾r cos 𝜃(𝑧) and slowed down by viscous friction in the bulk (8𝜋𝜂z𝑧) and gravity (𝜋r 2 𝜌gz) which yields the differential equation SI.6:

2𝑟𝛾 cos 𝜃(𝑧) = 8𝜂𝑧𝑧 + 𝑟 ! 𝜌𝑔𝑧 (SI.6)

We integrate equation SI.6 to recover the evolution of the meniscus height and compare the numerical integration to the data in figures SI5.b and SI5.c. As seen in the figure SI5, the numerical integration (black dashed lines) gives accurate results for both dry (red) and prewet (blue) tubes, without any adjustable parameter.

The small difference obtained between the numerical and experimental results could reflect small imperfections of the preweting or precursor film thickness.

Figure 1 .

 1 Figure 1. Rise dynamics in vertical tubes invaded by a viscous wetting oil. Tubes are either dry (red data) or prewet (blue data). (a) Sketch of the experiment with a wetting liquid. Blue and white represent liquid and air, respectively. The meniscus at a height z(t) has an apparent contact angle 𝜃. The origin of time is taken when the tube contacts the liquid. (b) The oil viscosity 𝜂 is 350 mPa.s, the tube radius is r = 0.5 mm and the thickness of the prewetting film is 𝜀 = 24 µm. The insert shows the data in logarithmic scales, and both dotted lines have a slope 1. (c) Same experiment with 𝜂 = 50 mPa.s, r = 0.23 mm and 𝜀 = 4 µm. In the logarithmic plot of the insert, the prewet tube now provides a Washburn regime with slope 1/2 (dashed line) while the initial dynamics in the dry tube remains linear (slope 1, dotted line).

  between 50 mPa.s and 1000 mPa.s, keeping the surface tension at a constant value 𝛾 = 21.0 ± 0.2 mN/m.

Figure 2 .

 2 Figure 2. Initial velocity V of a viscous wetting liquid invading a capillary tube as a function of its viscosity 𝜂. The surface tension of the silicone oils used in this experiment is 𝛾 = 21.0 ± 0.2 mN/m and the colours indicate the radius of the tube. The black line is a fit with slope -1.

10 ⌘

 10 (mPa.s) V (mm/s) r = 0.13 mm r = 0.23 mm r = 0.51 mm r = 0.70 mm is obtained by increasing the time interval between successive images) and it simultaneously thickens, a consequence of the relaxation of the dynamic contact angle θ towards its equilibrium value 𝜃0 = 0. Hence, the meniscus shape in figures 3a and 3b allows us to distinguish the two successive viscous regimes of invasion.

Figure 3 .

 3 Figure 3. (a) Time-lapse evolution of a viscous oil (𝜂 = 50 mPa.s) rising in a dry glass tube (r = 0.23 mm). The picture represents the meniscus at t = 36, 48, 60 and 72 ms (from bottom to top). The outside meniscus was masked for clarity. (b) Time-lapse evolution of a viscous oil (𝜂 = 350 mPa.s) rising in a glass tube (r = 0.7 mm). The picture shows the meniscus at t = 1.4, 4.2, 11 and 92 s (from bottom to top). In figures (a) and (b), the light source, placed under the bath, highlights the curvature, which makes the meniscus appear in white.

Figure 4 .

 4 Figure 4. Simplified (a) and more realistic (b) shapes of a wetting meniscus advancing at a speed V in a tube of radius r. 𝜀 denotes the thickness of the film on which the meniscus progresses, θ is the apparent (dynamic) contact angle and x is the vertical distance from the tip of the wedge.

Figure 5 .

 5 Figure5. Initial velocity V of a silicone oil (𝜂 = 350 mPa.s, 𝛾 = 21 mN/m) rising in a tube of radius r = 0.5 mm as a function of the thickness 𝜀 of the oil film on which the meniscus rises. Dots show the experimental data for dry (red) and prewet (blue) tubes. Equation 3 is drawn with a black line, without any adjustable parameter.

Figure SI2 .

 SI2 Figure SI2. (a)Sketch of an oil slug (in blue) of initial length l advancing at a constant speed U in a tube of radius r inclined by an angle 𝛽 to the vertical. As it moves, the slug deposits a liquid film of thickness 𝜀 on the tube walls. (b) Pictures of a drop advancing in a tube with r = 0.5 mm and 𝛽 = 50°. In the left picture, the drop length is l = 16.7 mm. In the right picture, that is, ∆t =100s later, the drop has progressed by ∆z = 37 mm, at velocity U = 0.37 mm/s, and its length has become l = 13.5 mm. The thickness of the deposited film deduced from the slug shortening is 21 µm.

  Figure SI3. Sketch of the matching between the static and dynamical part of the meniscus. On the left part of the sketch, the static meniscus is a portion of sphere with radius of curvature r* while the dynamic meniscus is described in SI1. The matching between the two menisci is done for y = h and 𝛼 = 𝜃, when the two curvatures balance.

Figure SI4 .

 SI4 Figure SI4. (a) Thickness of the dynamical meniscus divided by the tube radius and (b) macroscopic contact angle as a function of the meniscus velocity v divided by the initial velocity V obtained from eq. (4) for a meniscus advancing on film of liquid of thickness 𝜀 = 1nm.

Figure

  Figure SI5. (a) Meniscus shape at different steps of the rise of a viscous oil (𝜂 = 350 mPa.s) in a dry tube (𝜀 = 1 nm) with radius r = 0.7 mm (from bottom to top, t = 0, 0.1, 0.2, 0.3, 0.4, 1.2, 3.5, 9.5, 75.5, 150 s, corresponding to a ratio 𝑧/V = 1, 0.96, 0.89, 0.76, 0.51, 0.24, 0.09, 0). The solid and dashed lines respectively represent the meniscus part influenced by line friction and the static region (portion of a sphere). In (b) and (c), we compare the data from figures 1.b and 1.c (coloured lines) and the corresponding numerical integration (dashed black lines) of equation SI.6. (b) Silicone oil of viscosity 𝜂 = 350 mPa.s rising in capillary tube of radius r = 0.5 mm either dry (𝜀 = 1 nm) or prewet (𝜀 = 24 µm). (c) Silicone oil of viscosity 𝜂 = 50 mPa.s rising in capillary tube of radius r = 0.23 mm either dry (𝜀 = 1 nm) or prewet (𝜀 = 4 µm).

Physique & Mécanique des Milieux Hétérogènes, UMR 7636 du CNRS, ESPCI Paris, PSL Research University, Sorbonne Université, Université Paris Diderot, 75005 Paris, France.

Acknowledgment

We would like to thank Claire Doré and Nicolas Roméo for preliminary experiment, and Hugo Perrin and Christophe Clanet for fruitful discussions.

The dual role of viscosity in capillary rise

Joachim Delannoy, Suzanne Lafon, Yukina Koga, Étienne Reyssat & David Quéré

Supplementary Information

Derivation of the viscous friction in the meniscus

Here, we briefly recall the derivation by Moffatt of the pressure exerted by a viscous fluid moving in a corner, a situation sketched in figure SI1 [START_REF] Leger | Liquid spreading[END_REF]. Denoting the wedge angle as 𝛼 and its speed as V, the flow is described in the reference frame of the moving wedge by a stream function 𝜓, that verifies ur = 1/r(∂𝜓/∂𝜃), and u𝜃 = -∂𝜓/∂r, where ur and u𝜃 are the radial and tangential velocities in coordinates (r, 𝜃).


B Grambow

C Bruggeman

EURADSCIENCE the grouping and vision of European research entities in the first European Joint Programme

EURAD Vision and goals

Vision

A step change in European collaboration towards safe radioactive waste management (RWM), including disposal, through the development of a robust and sustained science, technology and knowledge management programme that supports timely implementation of RWM activities and serves to foster mutual understanding and trust between participants. Goals Support the implementation of the Waste Directive in EU Member-States (MS), taking into account the various stages of advancement of national programmes:

• Support MS in developing and implementing their national RD&D programmes for the safe long-term management of their full range of different types of radioactive waste; • Develop and consolidate existing knowledge for the safe start of operation of the first geological disposal facilities for spent fuel, HLW, and other long-lived radioactive waste, and supporting optimization linked with the stepwise implementation of geological disposal; • Enhance knowledge management and transfer between organisations, MS and generations.

The role of research entities RE grouping within JOPRAD on the feasibility of a European Joint Programming

REs in EURAD

• REs as LTPs -59 LTPs, mostly defined as "research organisations"

• National research centres, universities, waste producers • Some LTP linked to WMO: BRGM…

• Some research organisations mandated as TSO -VTT, CIEMAT

A network of research entities "EuradScience"

••

  Waste handling, characterisation, treatment, packaging • Interim storage • Transportation between facilities • Radionuclide inventory and source term • Waste acceptance criteria • Multi-national, regional or shared facilities Spent Fuel and high-level waste disposal canisters • Containers for LLI and LLW • Clay-based backfills, plugs and seals • Cementitious-based backfills, plugs and seals • Salt backfills • EBS system understanding Theme 4 Geoscience to understand rock properties, radionuclide transport and longterm geological evolution. • Long-term stability (uplift, erosion and tectonics) • Perturbations (gas, temperature and chemistry) • Aqueous pathways and radionuclide migration Theme 5 Facility design and the practicalities of construction, operations and closure. • Facility and disposal system design • Constructability, demonstration and verification testing • Health and safety during transport, construction, operations and closure • Monitoring and retrievability Theme 6 Siting and licensing. • Site selection process • Detailed site investigation • Licensing Theme 7 Performance assessment, safety analyses and safety case development • Integration of safety-related information • Performance assessment and system models • Treatment of uncertainties Roadmap

•

  Demonstrating safety and environmental protection of radioactive waste disposal facilities is associated with prominent scientifictechnical long-term challenges -Unique challenges in the history of science -Stringent demands to prevent migration of radiotoxic material to the environment limiting the quality of life for future generations -Complexity of disposal system and its components • Spatial scale features from nm to km • Time scale features from s to Myears • Multi-disciplinarity • Process coupling -Time-scales for implementing geological disposal -Credibility of safety assessments

Theme 1 Managing implementation and oversight of a RWM programme

	Phase 0: Policy,	Phase 1: Site	Phase 2: Site	Phase 3: Facility	Phase 4: Facility
	framework and	evaluation and site	characterisation	construction;	operation and
	programme	selection	Includes detailed	Includes final	closure
	establishment	Includes	design and site	design and site	Includes
	Includes conceptual	preliminary site(s)	safety	safety case/	maintenance and
	design and	design and generic	case/analyses for	analyses for	update of license
	preliminary safety	safety	construction license	operational	documentation, as
	analyses	case(s)/analyses		license	required
	• Programme planning
	• Organisation
	• Resources

• Networks IGDTP and SITEX orientated their work in the feasibility study by their Strategic Research Agendas (SRA) • Associated to the JOPRAD project, REs grouped to define their own SRA in record time form 2015-2016 • RE working group (22 partners) -Advanced and less advanced programs

Theme 2 Radioactive waste characterisation, processing and storage and source term understanding for disposal.

Updating the JOPRAD RE-SRA

• Focus shift from "geological disposal" (JOPRAD) to "from cradle to grave" (nuclear back-end, EURAD), including Updating the JOPRAD RE-SRA

• Some examples -Innovative waste forms (ceramic, geopolymers, plasma, spray coatings, organo-mineral composites, etc.) -Natural analogues/site-specific analogues -Biosphere models: how to increase credibility? -Transparent and quality assured thermodynamic databases -Linking bottom up to top down approaches in complex systems, including mineral assemblages, competition effects, micro-organisms, redox, colloids Next steps (3)

• EuradScience could also reflect on how to organize research in Europe (also beyond EURAD)

-Number of specialists on certain themes go down.

-Number of dedicated facilities (like hot cells) go down.

-Coordination of specialist groups working on specific topics.

-Access to research infrastructure as topic on its own;

• Should also be paid, but this has never been pursued.

• EuradScience could also play a role in evaluating scientic progress made within EURAD, relative to road map of EURAD and scientific long term vision…

Future actions for EuradScience (Executive Group to take initiative)

-Definition of the structure