DOCSLIB.ORG

Linux Kernel and LKP Dynamics

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Linux Kernel and LKP Dynamics Linux kernel and LKP dynamics Wu Fengguang <[email protected]> December 17, 2016 Outline Linux 4.x changes 0day/LKP testing Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 2 / 16 Linux 4.0 1 Live patching 2 DAX - Direct Access, for persistent memory storage 3 KASan, kernel address sanitizer 4 "lazytime" option, for better update of file timestamps 5 Multiple lower layers in overlayfs 6 Support Parallel NFS server, default to NFS v4.2 7 dm-crypt scalability improvements DAX run fs on NVM, way fitting NVM into current Linux framework KASan one of the compiler aided runtime checkers overlayfs for Docker/container; misses NFS/CIFS support Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 3 / 16 Linux 4.1 1 Ext4 encryption support 2 Experimental cluster support for MD 3 Device mapper: new target that logs writes 4 Single user support 5 Virtual GEM driver for improved software rasterizers 6 Block device for persistent memory 7 Multiprotocol Label Switching 8 BPF programs can be attached to kprobes 9 ACPI support for the ARM64 architecture ext4 crypt convenient and efficient replacement for dm-crypt/eCryptfs BPF Berkeley Packet Filter => the universal in-kernel virtual machine => Linux’s DTrace Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 4 / 16 Linux 4.2 1 New driver amdgpu for modern AMD Radeon hardware 2 Add virtio gpu driver 3 Atomic modesetting API enabled by default 4 Stacking of security modules 5 Queued spinlocks become the default spinlock implementation 6 cgroup writeback support 7 Reintroduction of the H8/300 architecture dirty thrtl inode ownership tracking enforced (only) in CFQ iosched alternative: VFS layer throttling Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 5 / 16 Linux 4.3 1 The Ext3 filesystem has been removed 2 userfaultfd(), a system call for handling page-faults in user space 3 membarrier(), a system call for issuing memory barriers on a set of threads 4 New PID controller for limiting the number of PIDs in cgroups 5 Ambient capabilities 6 Introduce idle page tracking, a more precise way to track the memory being used by applications 7 Support for IPv6 Identifier Locator Addressing 8 Network light weight tunnels 9 Virtual Routing and Forwarding (Lite) support userfaultfd copy-on-access: quick QEMU migration; volatile ranges copy-on-write: sync dirtied pages IPv6 ILA net connection migration in datacenter Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 6 / 16 Linux 4.4 1 Faster and leaner loop device with Direct I/O and Asynchronous I/O support 2 3D support in virtual GPU driver 3 LightNVM adds support for Open-Channel SSDs 4 TCP listener handling completely lockless, making TCP servers faster and more scalable 5 Journalled RAID5 MD support 6 Unprivileged eBPF + persistent eBPF programs 7 perf + eBPF integration 8 Block polling support 9 mlock2() syscall allow users to request memory to be locked on page fault LightNVM many Vendors are supporting host-based control host OS: data placement, I/O scheduling, garbage collection SSD controller: managing flash chips, capacitors, etc. Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 7 / 16 Linux 4.5 1 Copy offloading with new copy_file_range(2) system call 2 Experimental PowerPlay supports brings high performance to the amdgpu driver 3 Btrfs free space handling scalability improvements 4 Support for GCC's Undefined Behavior Sanitizer (-fsanitize=undefined) 5 Forwarded Error Correction support in the device-mapper's verity target 6 Add MADV_FREE flag to madvise(2) 7 Better epoll multithread scalability 8 cgroup unified hierarchy is considered stable 9 Performance improvements for SO_REUSEPORT UDP sockets 10 Proper control of socket memory usage in the memory controller MADV_FREE lazy MADV_DONTNEED; for user-space memory allocator cgroup v2 keep kernel sane; leave war to systemd and docker Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 8 / 16 Linux 4.6 1 USB 3.1 SuperSpeedPlus (10 Gbps) support 2 Improve the reliability of the Out Of Memory task killer 3 Support for Intel memory protection keys 4 OrangeFS, a new distributed file system 5 Kernel Connection Multiplexor, a facility for accelerating application layer protocols 6 802.1AE MAC-level encryption (MACsec) 7 BATMAN V protocol 8 dma-buf: new ioctl to manage cache coherency between CPU and GPU 9 OCFS2 online inode checker 10 Support for cgroup namespaces 11 Add support for the pNFS SCSI layout MPX handy for user space to apply restrictions to large ranges of memory KCM atomic messages over TCP; uses BPF Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 9 / 16 Linux 4.7 1 Support for Radeon RX480 GPUs 2 Parallel directory lookups 3 New 'schedutil" frequency governor 4 Histograms of events in ftrace 5 perf trace calls stack 6 Allow BPF programs to attach to tracepoints 7 EFI 'Capsule' firmware updates 8 Support for creating virtual USB Device Controllers in USB/IP 9 Android's sync_file fencing mechanism considered stable 10 LoadPin, a security module to restrict the origin of kernel modules schedutil towards Energy Aware Scheduling Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 10 / 16 FPGA Reconfigurable computing for in memory database processing search intelligent network acceleration, DPDK machine and deep learning 4G/5G base station Video analytics blockchain other analytic algorithms.... half/half interests from embedded/server Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 11 / 16 FPGA: ways to widespread 1 standalization FPGA mgr Enumeration Config and assignment Orchestration => FPGA IP app store? 2 ease of use C/C++ C based (OpenCL) VHDL/HDL ... Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 12 / 16 0day/LKP testing: numbers The most comprehensive Linux test infrastructure. 80 servers 700+ kernel trees 2000 runtime test jobs 36000 build tests per day 150000 runtime tests per day =) 800 build reports per month 60 runtime reports per month Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 13 / 16 0day/LKP testing: principles 0 effort for developers shift left: test git pushes and LKML patches aim at fixing bugs: bisect and report to the relevant people up to 1000 levarage ratio: merge to test 100% test machines utilization: cyclic jobs get the most out of test runs: dozens of monitors, monitor boot/functional/throughput/latency/power etc. regressions at same time Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 14 / 16 0day/LKP testing: current status build tests: mature full automation near 100% build and static check coverage v4.9-rc2: 0 build warnings (x86_64 allmodconfig); Android: 40,000 warnings. runtime tests: there are rooms to improve auto reporting merge failures bisect effectiveness service stability ... costly and challenging to increase coverage Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 15 / 16 Thank you! Wu Fengguang (Intel OTC) Linux kernel and LKP dynamics 2016 Intel OTC 16 / 16.
Load more

Recommended publications
  • Security Assurance Requirements for Linux Application Container Deployments
    NISTIR 8176 Security Assurance Requirements for Linux Application Container Deployments Ramaswamy Chandramouli This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8176 NISTIR 8176 Security Assurance Requirements for Linux Application Container Deployments Ramaswamy Chandramouli Computer Security Division Information Technology Laboratory This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8176 October 2017 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology NISTIR 8176 SECURITY ASSURANCE FOR LINUX CONTAINERS National Institute of Standards and Technology Internal Report 8176 37 pages (October 2017) This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8176 Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. This p There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each ublication is available free of charge from: http publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.
    [Show full text]
  • Rootless Containers with Podman and Fuse-Overlayfs
    CernVM Workshop 2019 (4th June 2019) Rootless containers with Podman and fuse-overlayfs Giuseppe Scrivano @gscrivano Introduction 2 Rootless Containers • “Rootless containers refers to the ability for an unprivileged user (i.e. non-root user) to create, run and otherwise manage containers.” (https://rootlesscontaine.rs/ ) • Not just about running the container payload as an unprivileged user • Container runtime runs also as an unprivileged user 3 Don’t confuse with... • sudo podman run --user foo – Executes the process in the container as non-root – Podman and the OCI runtime still running as root • USER instruction in Dockerfile – same as above – Notably you can’t RUN dnf install ... 4 Don’t confuse with... • podman run --uidmap – Execute containers as a non-root user, using user namespaces – Most similar to rootless containers, but still requires podman and runc to run as root 5 Motivation of Rootless Containers • To mitigate potential vulnerability of container runtimes • To allow users of shared machines (e.g. HPC) to run containers without the risk of breaking other users environments • To isolate nested containers 6 Caveat: Not a panacea • Although rootless containers could mitigate these vulnerabilities, it is not a panacea , especially it is powerless against kernel (and hardware) vulnerabilities – CVE 2013-1858, CVE-2015-1328, CVE-2018-18955 • Castle approach : it should be used in conjunction with other security layers such as seccomp and SELinux 7 Podman 8 Rootless Podman Podman is a daemon-less alternative to Docker • $ alias
    [Show full text]
  • Reducing Power Consumption in Mobile Devices by Using a Kernel
    IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. Z, NO. B, AUGUST 2017 1 Reducing Event Latency and Power Consumption in Mobile Devices by Using a Kernel-Level Display Server Stephen Marz, Member, IEEE and Brad Vander Zanden and Wei Gao, Member, IEEE E-mail: [email protected], [email protected], [email protected] Abstract—Mobile devices differ from desktop computers in that they have a limited power source, a battery, and they tend to spend more CPU time on the graphical user interface (GUI). These two facts force us to consider different software approaches in the mobile device kernel that can conserve battery life and reduce latency, which is the duration of time between the inception of an event and the reaction to the event. One area to consider is a software package called the display server. The display server is middleware that handles all GUI activities between an application and the operating system, such as event handling and drawing to the screen. In both desktop and mobile devices, the display server is located in the application layer. However, the kernel layer contains most of the information needed for handling events and drawing graphics, which forces the application-level display server to make a series of system calls in order to coordinate events and to draw graphics. These calls interrupt the CPU which can increase both latency and power consumption, and also require the kernel to maintain event queues that duplicate event queues in the display server. A further drawback of placing the display server in the application layer is that the display server contains most of the information required to efficiently schedule the application and this information is not communicated to existing kernels, meaning that GUI-oriented applications are scheduled less efficiently than they might be, which further increases power consumption.
    [Show full text]
  • In Search of the Ideal Storage Configuration for Docker Containers
    In Search of the Ideal Storage Configuration for Docker Containers Vasily Tarasov1, Lukas Rupprecht1, Dimitris Skourtis1, Amit Warke1, Dean Hildebrand1 Mohamed Mohamed1, Nagapramod Mandagere1, Wenji Li2, Raju Rangaswami3, Ming Zhao2 1IBM Research—Almaden 2Arizona State University 3Florida International University Abstract—Containers are a widely successful technology today every running container. This would cause a great burden on popularized by Docker. Containers improve system utilization by the I/O subsystem and make container start time unacceptably increasing workload density. Docker containers enable seamless high for many workloads. As a result, copy-on-write (CoW) deployment of workloads across development, test, and produc- tion environments. Docker’s unique approach to data manage- storage and storage snapshots are popularly used and images ment, which involves frequent snapshot creation and removal, are structured in layers. A layer consists of a set of files and presents a new set of exciting challenges for storage systems. At layers with the same content can be shared across images, the same time, storage management for Docker containers has reducing the amount of storage required to run containers. remained largely unexplored with a dizzying array of solution With Docker, one can choose Aufs [6], Overlay2 [7], choices and configuration options. In this paper we unravel the multi-faceted nature of Docker storage and demonstrate its Btrfs [8], or device-mapper (dm) [9] as storage drivers which impact on system and workload performance. As we uncover provide the required snapshotting and CoW capabilities for new properties of the popular Docker storage drivers, this is a images. None of these solutions, however, were designed with sobering reminder that widespread use of new technologies can Docker in mind and their effectiveness for Docker has not been often precede their careful evaluation.
    [Show full text]
  • MINCS - the Container in the Shell (Script)
    MINCS - The Container in the Shell (script) - Masami Hiramatsu <[email protected]> Tech Lead, Linaro Ltd. Open Source Summit Japan 2017 LEADING COLLABORATION IN THE ARM ECOSYSTEM Who am I... Masami Hiramatsu - Linux kernel kprobes maintainer - Working for Linaro as a Tech Lead LEADING COLLABORATION IN THE ARM ECOSYSTEM Demo # minc top # minc -r /opt/debian/x86_64 # minc -r /opt/debian/arm64 --arch arm64 LEADING COLLABORATION IN THE ARM ECOSYSTEM What Is MINCS? My Personal Fun Project to learn how linux containers work :-) LEADING COLLABORATION IN THE ARM ECOSYSTEM What Is MINCS? Mini Container Shell Scripts (pronounced ‘minks’) - Container engine implementation using POSIX shell scripts - It is small (~60KB, ~2KLOC) (~20KB in minimum) - It can run on busybox - No architecture dependency (* except for qemu/um mode) - No need for special binaries (* except for libcap, just for capsh --exec) - Main Features - Namespaces (Mount, PID, User, UTS, Net*) - Cgroups (CPU, Memory) - Capabilities - Overlay filesystem - Qemu cross-arch/system emulation - User-mode-linux - Image importing from dockerhub And all are done by CLI commands :-) LEADING COLLABORATION IN THE ARM ECOSYSTEM Why Shell Script? That is my favorite language :-) - Easy to understand for *nix administrators - Just a bunch of commands - Easy to modify - Good for prototyping - Easy to deploy - No architecture dependencies - Very small - Able to run on busybox (+ libcap is perfect) LEADING COLLABORATION IN THE ARM ECOSYSTEM MINCS Use-Cases For Learning - Understand how containers work For Development - Prepare isolated (cross-)build environment For Testing - Test new applications in isolated environment - Test new kernel features on qemu using local tools For products? - Maybe good for embedded devices which has small resources LEADING COLLABORATION IN THE ARM ECOSYSTEM What Is A Linux Container? There are many linux container engines - Docker, LXC, rkt, runc, ..
    [Show full text]
  • Kernel Boot-Time Tracing
    Kernel Boot-time Tracing Linux Plumbers Conference 2019 - Tracing Track Masami Hiramatsu <[email protected]> Linaro, Ltd. Speaker Masami Hiramatsu - Working for Linaro and Linaro members - Tech Lead for a Landing team - Maintainer of Kprobes and related tracing features/tools Why Kernel Boot-time Tracing? Debug and analyze boot time errors and performance issues - Measure performance statistics of kernel boot - Analyze driver init failure - Debug boot up process - Continuously tracing from boot time etc. What We Have There are already many ftrace options on kernel command line ● Setup options (trace_options=) ● Output to printk (tp_printk) ● Enable events (trace_events=) ● Enable tracers (ftrace=) ● Filtering (ftrace_filter=,ftrace_notrace=,ftrace_graph_filter=,ftrace_graph_notrace=) ● Add kprobe events (kprobe_events=) ● And other options (alloc_snapshot, traceoff_on_warning, ...) See Documentation/admin-guide/kernel-parameters.txt Example of Kernel Cmdline Parameters In grub.conf linux /boot/vmlinuz-5.1 root=UUID=5a026bbb-6a58-4c23-9814-5b1c99b82338 ro quiet splash tp_printk trace_options=”sym-addr” trace_clock=global ftrace_dump_on_oops trace_buf_size=1M trace_event=”initcall:*,irq:*,exceptions:*” kprobe_event=”p:kprobes/myevent foofunction $arg1 $arg2;p:kprobes/myevent2 barfunction %ax” What Issues? Size limitation ● kernel cmdline size is small (< 256bytes) ● A half of the cmdline is used for normal boot Only partial features supported ● ftrace has too complex features for single command line ● per-event filters/actions, instances, histograms. Solutions? 1. Use initramfs - Too late for kernel boot time tracing 2. Expand kernel cmdline - It is not easy to write down complex tracing options on bootloader (Single line options is too simple) 3. Reuse structured boot time data (Devicetree) - Well documented, structured data -> V1 & V2 series based on this. Boot-time Trace: V1 and V2 series V1 and V2 series posted at June.
    [Show full text]
  • Linux Perf Event Features and Overhead
    Linux perf event Features and Overhead 2013 FastPath Workshop Vince Weaver http://www.eece.maine.edu/∼vweaver [email protected] 21 April 2013 Performance Counters and Workload Optimized Systems • With processor speeds constant, cannot depend on Moore's Law to deliver increased performance • Code analysis and optimization can provide speedups in existing code on existing hardware • Systems with a single workload are best target for cross- stack hardware/kernel/application optimization • Hardware performance counters are the perfect tool for this type of optimization 1 Some Uses of Performance Counters • Traditional analysis and optimization • Finding architectural reasons for slowdown • Validating Simulators • Auto-tuning • Operating System optimization • Estimating power/energy in software 2 Linux and Performance Counters • Linux has become the operating system of choice in many domains • Runs most of the Top500 list (over 90%) on down to embedded devices (Android Phones) • Until recently had no easy access to hardware performance counters, limiting code analysis and optimization. 3 Linux Performance Counter History • oprofile { system-wide sampling profiler since 2002 • perfctr { widely used general interface available since 1999, required patching kernel • perfmon2 { another general interface, included in kernel for itanium, made generic, big push for kernel inclusion 4 Linux perf event • Developed in response to perfmon2 by Molnar and Gleixner in 2009 • Merged in 2.6.31 as \PCL" • Unusual design pushes most functionality into kernel
    [Show full text]
  • Onload User Guide
    Onload User Guide Copyright © 2017 SOLARFLARE Communications, Inc. All rights reserved. The software and hardware as applicable (the “Product”) described in this document, and this document, are protected by copyright laws, patents and other intellectual property laws and international treaties. The Product described in this document is provided pursuant to a license agreement, evaluation agreement and/or non‐disclosure agreement. The Product may be used only in accordance with the terms of such agreement. The software as applicable may be copied only in accordance with the terms of such agreement. Onload is licensed under the GNU General Public License (Version 2, June 1991). See the LICENSE file in the distribution for details. The Onload Extensions Stub Library is Copyright licensed under the BSD 2‐Clause License. Onload contains algorithms and uses hardware interface techniques which are subject to Solarflare Communications Inc patent applications. Parties interested in licensing Solarflare's IP are encouraged to contact Solarflare's Intellectual Property Licensing Group at: Director of Intellectual Property Licensing Intellectual Property Licensing Group Solarflare Communications Inc, 7505 Irvine Center Drive Suite 100 Irvine, California 92618 You will not disclose to a third party the results of any performance tests carried out using Onload or EnterpriseOnload without the prior written consent of Solarflare. The furnishing of this document to you does not give you any rights or licenses, express or implied, by estoppel or otherwise, with respect to any such Product, or any copyrights, patents or other intellectual property rights covering such Product, and this document does not contain or represent any commitment of any kind on the part of SOLARFLARE Communications, Inc.
    [Show full text]
  • Multicore Operating-System Support for Mixed Criticality∗
    Multicore Operating-System Support for Mixed Criticality∗ James H. Anderson, Sanjoy K. Baruah, and Bjorn¨ B. Brandenburg The University of North Carolina at Chapel Hill Abstract Different criticality levels provide different levels of assurance against failure. In current avionics designs, Ongoing research is discussed on the development of highly-critical software is kept physically separate from operating-system support for enabling mixed-criticality less-critical software. Moreover, no currently deployed air- workloads to be supported on multicore platforms. This craft uses multicore processors to host highly-critical tasks work is motivated by avionics systems in which such work- (more precisely, if multicore processors are used, and if loads occur. In the mixed-criticality workload model that is such a processor hosts highly-critical applications, then all considered, task execution costs may be determined using but one of its cores are turned off). These design decisions more-stringent methods at high criticality levels, and less- are largely driven by certification issues. For example, cer- stringent methods at low criticality levels. The main focus tifying highly-critical components becomes easier if poten- of this research effort is devising mechanisms for providing tially adverse interactions among components executing on “temporal isolation” across criticality levels: lower levels different cores through shared hardware such as caches are should not adversely “interfere” with higher levels. simply “defined” not to occur. Unfortunately, hosting an overall workload as described here clearly wastes process- ing resources. 1 Introduction In this paper, we propose operating-system infrastruc- ture that allows applications of different criticalities to be The evolution of computational frameworks for avionics co-hosted on a multicore platform.
    [Show full text]
  • Programmer's Guide
    Programmer’s Guide Release 18.11.11 Jan 20, 2021 CONTENTS 1 Introduction 1 1.1 Documentation Roadmap...............................1 1.2 Related Publications..................................2 2 Overview 3 2.1 Development Environment..............................3 2.2 Environment Abstraction Layer............................4 2.3 Core Components...................................4 2.3.1 Ring Manager (librte_ring)..........................4 2.3.2 Memory Pool Manager (librte_mempool)..................4 2.3.3 Network Packet Buffer Management (librte_mbuf).............6 2.3.4 Timer Manager (librte_timer)........................6 2.4 Ethernet* Poll Mode Driver Architecture.......................6 2.5 Packet Forwarding Algorithm Support........................6 2.6 librte_net........................................6 3 Environment Abstraction Layer7 3.1 EAL in a Linux-userland Execution Environment..................7 3.1.1 Initialization and Core Launching......................8 3.1.2 Shutdown and Cleanup...........................8 3.1.3 Multi-process Support............................8 3.1.4 Memory Mapping Discovery and Memory Reservation..........8 3.1.5 Support for Externally Allocated Memory.................. 11 3.1.6 Per-lcore and Shared Variables....................... 12 3.1.7 Logs...................................... 12 3.1.8 CPU Feature Identification.......................... 12 3.1.9 User Space Interrupt Event......................... 13 3.1.10 Blacklisting.................................. 14 3.1.11 Misc Functions...............................
    [Show full text]
  • Hiding Process Memory Via Anti-Forensic Techniques
    DIGITAL FORENSIC RESEARCH CONFERENCE Hiding Process Memory via Anti-Forensic Techniques By: Frank Block (Friedrich-Alexander Universität Erlangen-Nürnberg (FAU) and ERNW Research GmbH) and Ralph Palutke (Friedrich-Alexander Universität Erlangen-Nürnberg) From the proceedings of The Digital Forensic Research Conference DFRWS USA 2020 July 20 - 24, 2020 DFRWS is dedicated to the sharing of knowledge and ideas about digital forensics research. Ever since it organized the first open workshop devoted to digital forensics in 2001, DFRWS continues to bring academics and practitioners together in an informal environment. As a non-profit, volunteer organization, DFRWS sponsors technical working groups, annual conferences and challenges to help drive the direction of research and development. https://dfrws.org Forensic Science International: Digital Investigation 33 (2020) 301012 Contents lists available at ScienceDirect Forensic Science International: Digital Investigation journal homepage: www.elsevier.com/locate/fsidi DFRWS 2020 USA d Proceedings of the Twentieth Annual DFRWS USA Hiding Process Memory Via Anti-Forensic Techniques Ralph Palutke a, **, 1, Frank Block a, b, *, 1, Patrick Reichenberger a, Dominik Stripeika a a Friedrich-Alexander Universitat€ Erlangen-Nürnberg (FAU), Germany b ERNW Research GmbH, Heidelberg, Germany article info abstract Article history: Nowadays, security practitioners typically use memory acquisition or live forensics to detect and analyze sophisticated malware samples. Subsequently, malware authors began to incorporate anti-forensic techniques that subvert the analysis process by hiding malicious memory areas. Those techniques Keywords: typically modify characteristics, such as access permissions, or place malicious data near legitimate one, Memory subversion in order to prevent the memory from being identified by analysis tools while still remaining accessible.
    [Show full text]
  • Linux on IBM Z
    Linux on IBM Z Pervasive Encryption with Linux on IBM Z: from a performance perspective Danijel Soldo Software Performance Analyst Linux on IBM Z Performance Evaluation _ [email protected] IBM Z / Danijel Soldo – Pervasive Encryption with Linux on IBM Z: from a performance perspective / © 2018 IBM Corporation Notices and disclaimers • © 2018 International Business Machines Corporation. No part of • Performance data contained herein was generally obtained in a this document may be reproduced or transmitted in any form controlled, isolated environments. Customer examples are without written permission from IBM. presented as illustrations of how those • U.S. Government Users Restricted Rights — use, duplication • customers have used IBM products and the results they may have or disclosure restricted by GSA ADP Schedule Contract with achieved. Actual performance, cost, savings or other results in IBM. other operating environments may vary. • Information in these presentations (including information relating • References in this document to IBM products, programs, or to products that have not yet been announced by IBM) has been services does not imply that IBM intends to make such products, reviewed for accuracy as of the date of initial publication programs or services available in all countries in which and could include unintentional technical or typographical IBM operates or does business. errors. IBM shall have no responsibility to update this information. This document is distributed “as is” without any warranty, • Workshops, sessions and associated materials may have been either express or implied. In no event, shall IBM be liable for prepared by independent session speakers, and do not necessarily any damage arising from the use of this information, reflect the views of IBM.
    [Show full text]