The Forgotten Interface: Windows Named Pipes
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Inter-Process Communication, Analysis, Guidelines and Its Impact on Computer Security
The 7th International Conference for Informatics and Information Technology (CIIT 2010) INTER-PROCESS COMMUNICATION, ANALYSIS, GUIDELINES AND ITS IMPACT ON COMPUTER SECURITY Zoran Spasov Ph.D. Ana Madevska Bogdanova T-Mobile Macedonia Institute of Informatics, FNSM Skopje, Macedonia Skopje, Macedonia ABSTRACT Finally the conclusion will offer a summary of the available programming techniques and implementations for the In this paper we look at the inter-process communication Windows platforms. We will note the security risks and the (IPC) also known as inter-thread or inter-application best practices to avoid them. communication from other knowledge sources. We will look and analyze the different types of IPC in the Microsoft II. INTER -PROCESS COMMUNICATION (IPC) Windows operating system, their implementation and the usefulness of this kind of approach in the terms of Inter-Process Communication (IPC) stands for many communication between processes. Only local techniques for the exchange of data among threads in one or implementation of the IPC will be addressed in this paper. more processes - one-directional or two-directional. Processes Special emphasis will be given to the system mechanisms that may be running locally or on many different computers are involved with the creation, management, and use of connected by a network. We can divide the IPC techniques named pipes and sockets. into groups of methods, grouped by their way of This paper will discuss some of the IPC options and communication: message passing, synchronization, shared techniques that are available to Microsoft Windows memory and remote procedure calls (RPC). We should programmers. We will make a comparison between Microsoft carefully choose the IPC method depending on data load that remoting and Microsoft message queues (pros and cons). -
An Introduction to Linux IPC
An introduction to Linux IPC Michael Kerrisk © 2013 linux.conf.au 2013 http://man7.org/ Canberra, Australia [email protected] 2013-01-30 http://lwn.net/ [email protected] man7 .org 1 Goal ● Limited time! ● Get a flavor of main IPC methods man7 .org 2 Me ● Programming on UNIX & Linux since 1987 ● Linux man-pages maintainer ● http://www.kernel.org/doc/man-pages/ ● Kernel + glibc API ● Author of: Further info: http://man7.org/tlpi/ man7 .org 3 You ● Can read a bit of C ● Have a passing familiarity with common syscalls ● fork(), open(), read(), write() man7 .org 4 There’s a lot of IPC ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 5 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 6 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memoryn attach ● Pseudoterminals tio a ● proc_vm_readv() / proc_vm_writev() ● Sockets ic n ● Signals ● Stream vs Datagram (vs uSeq. -
CS 5600 Computer Systems
CS 5600 Computer Systems Lecture 4: Programs, Processes, and Threads • Programs • Processes • Context Switching • Protected Mode Execution • Inter-process Communication • Threads 2 Running Dynamic Code • One basic function of an OS is to execute and manage code dynamically, e.g.: – A command issued at a command line terminal – An icon double clicked from the desktop – Jobs/tasks run as part of a batch system (MapReduce) • A process is the basic unit of a program in execution 3 Programs and Processes Process The running instantiation of a program, stored in RAM Program An executable file in long-term One-to-many storage relationship between program and processes 4 How to Run a Program? • When you double-click on an .exe, how does the OS turn the file on disk into a process? • What information must the .exe file contain in order to run as a program? 5 Program Formats • Programs obey specific file formats – CP/M and DOS: COM executables (*.com) – DOS: MZ executables (*.exe) • Named after Mark Zbikowski, a DOS developer – Windows Portable Executable (PE, PE32+) (*.exe) • Modified version of Unix COFF executable format • PE files start with an MZ header. – Mac OSX: Mach object file format (Mach-O) – Unix/Linux: Executable and Linkable Format (ELF) • designed to be flexible and extensible • all you need to know to load and start execution regardless of architecture 6 ABI - Application Binary Interface • interface between 2 programs at the binary (machine code) level – informally, similar to API but on bits and bytes • Calling conventions – -
IPC: Mmap and Pipes
Interprocess Communication: Memory mapped files and pipes CS 241 April 4, 2014 University of Illinois 1 Shared Memory Private Private address OS address address space space space Shared Process A segment Process B Processes request the segment OS maintains the segment Processes can attach/detach the segment 2 Shared Memory Private Private Private address address space OS address address space space space Shared Process A segment Process B Can mark segment for deletion on last detach 3 Shared Memory example /* make the key: */ if ((key = ftok(”shmdemo.c", 'R')) == -1) { perror("ftok"); exit(1); } /* connect to (and possibly create) the segment: */ if ((shmid = shmget(key, SHM_SIZE, 0644 | IPC_CREAT)) == -1) { perror("shmget"); exit(1); } /* attach to the segment to get a pointer to it: */ data = shmat(shmid, (void *)0, 0); if (data == (char *)(-1)) { perror("shmat"); exit(1); } 4 Shared Memory example /* read or modify the segment, based on the command line: */ if (argc == 2) { printf("writing to segment: \"%s\"\n", argv[1]); strncpy(data, argv[1], SHM_SIZE); } else printf("segment contains: \"%s\"\n", data); /* detach from the segment: */ if (shmdt(data) == -1) { perror("shmdt"); exit(1); } return 0; } Run demo 5 Memory Mapped Files Memory-mapped file I/O • Map a disk block to a page in memory • Allows file I/O to be treated as routine memory access Use • File is initially read using demand paging ! i.e., loaded from disk to memory only at the moment it’s needed • When needed, a page-sized portion of the file is read from the file system -
Interprocess Communication
06 0430 CH05 5/22/01 10:22 AM Page 95 5 Interprocess Communication CHAPTER 3,“PROCESSES,” DISCUSSED THE CREATION OF PROCESSES and showed how one process can obtain the exit status of a child process.That’s the simplest form of communication between two processes, but it’s by no means the most powerful.The mechanisms of Chapter 3 don’t provide any way for the parent to communicate with the child except via command-line arguments and environment variables, nor any way for the child to communicate with the parent except via the child’s exit status. None of these mechanisms provides any means for communicating with the child process while it is actually running, nor do these mechanisms allow communication with a process outside the parent-child relationship. This chapter describes means for interprocess communication that circumvent these limitations.We will present various ways for communicating between parents and chil- dren, between “unrelated” processes, and even between processes on different machines. Interprocess communication (IPC) is the transfer of data among processes. For example, a Web browser may request a Web page from a Web server, which then sends HTML data.This transfer of data usually uses sockets in a telephone-like connection. In another example, you may want to print the filenames in a directory using a command such as ls | lpr.The shell creates an ls process and a separate lpr process, connecting 06 0430 CH05 5/22/01 10:22 AM Page 96 96 Chapter 5 Interprocess Communication the two with a pipe, represented by the “|” symbol.A pipe permits one-way commu- nication between two related processes.The ls process writes data into the pipe, and the lpr process reads data from the pipe. -
Interprocess Communications (Pipes)
Multiple methods for Interprocess Communications Three examples: files, pipes, shared memory. In this figure, Local domain sockets would be conceptually similar to a named pipe. The second method refers to pipes Sources for these slides include: • W. Stevens, Unix Network Programming, Volumes 1 and 2 • M. Mitchell, J. Oldham, A. Samuel, Advanced Linux Programming 1 Interprocess Communication (IPC) ⚫ Linux supports the following IPC mechanisms: – Half duplex pipes – Full duplex pipes –only by using 2 pipes (other unix systems do support FD over a single pipe) – FIFOS (also called named pipes) – SYSV style message queues – SYSV style shared memory – Local Domain (UNIX Domain) sockets – Similar to a socket but modifications to the address/name aspect. (PF_LOCAL rather than PF_INET). – Sockets: Two processes can communicate using localhost. But it’s more efficient to use 2 pipes or local domain sockets. Pipe – used in a shell pipeline ⚫ Example of a pipeline - issue the following in a shell: – who | sort | wc 2 10 110 – The shell program creates three processes, two pipes are used as shown below. – The shell would use the dup2 call to duplicate the read end of each pipe to standard input and the write end to standard output. ⚫ int fd[2]; ⚫ pid_t pid; ⚫ pipe(fd); ⚫ pid = fork(); ⚫ If(pid == 0) { – dup2(fd[0], STDIN_FILENO); – exec(whatever); ⚫ } ⚫ The use of dup2 by a shell allows a program or filter to simply operate on data arriving through standard in….and sends output to standard out. It does not need to know the pipe descriptors involved…. 3 – Note – modified the pipeline- the figure assumes lp instead of wc . -
Half-Process: a Process Partially Sharing Its Address Space with Other Processes
Electronic Preprint for Journal of Information Processing Vol.20 No.1 Regular Paper Half-process: A Process Partially Sharing Its Address Space with Other Processes Kentaro Hara1,a) Kenjiro Taura1 Received: March 31, 2011, Accepted: September 12, 2011 Abstract: Threads share a single address space with each other. On the other hand, a process has its own address space. Since whether to share or not to share the address space depends on each data structure in the whole program, the choice of “a thread or a process” for the whole program is too much “all-or-nothing.” With this motivation, this paper proposes a half-process, a process partially sharing its address space with other processes. This paper describes the design and the kernel-level implementation of the half-process and discusses the potential applicability of the half-process for multi-thread programming with thread-unsafe libraries, intra-node communications in parallel pro- gramming frameworks and transparent kernel-level thread migration. In particular, the thread migration based on the half-process is the first work that achieves transparent kernel-level thread migration by solving the problem of sharing global variables between threads. Keywords: partitioned global address space, Linux kernel, thread migration, finite element method, reconfiguration, productivity 1. Introduction Threads share a single address space with each other. When one thread issues memory operations such as mmap()/munmap()/mprotect(), all threads can see the ef- fects immediately. When one thread updates a memory address, Fig. 1 The design of a half-process. all threads can see the update immediately. In addition, all programmer can enjoy both advantages of process and thread, threads can access the same data with the same address. -
Snap on Windows an Intel-Sponsored, Open-Source Telemetry Framework IT 447 April 4, 2017
Snap on Windows An Intel-sponsored, open-source telemetry framework IT 447 April 4, 2017 Phillip Anderson McKade Clements Devin Durtschi Mathew Kuhn Jesse Millar Coach: Dr. Jay Ekstrom Sponsor: Taylor Thomas Table of Contents Table of Contents Executive Summary Introduction Concept Definition Background Stakeholders Intel Companies with Windows Systems Operators of Windows Systems Open-source Maintainers of the Snap Project Members of the Snap Community Stakeholder Requirements Validation Verification System Definition System Requirements Logical Architecture Project Component Details Build Windows Test Environment Perfmon Plugin Sysinternals Plugin Active Directory Plugin Create an Automated Build Script for Snap Critical Path Verification and Validation Project Management Objective Statement List of Deliverables Conclusion References Appendix Source Code Constraint Matrix Governance Framework Communication Acceptance Documentation Gantt Chart Executive Summary Snap for Windows is a Brigham Young University Information Technology 2016-2017 capstone project. Snap is an open-source telemetry system headed by Intel, meant to facilitate the remote monitoring of large networks and company infrastructures. Snap works through three types of “plugins,” which allow for modularized collecting, processing, and publishing of system metrics. These metrics can include data such as cpu usage, number of processes running on a system, and memory available. Previously, Snap’s functionalities were constrained to Linux systems only, and were not compatible with Windows. This prevented a large portion of company infrastructures from utilizing Snap, as companies typically run the Windows operating system on a large portion of their network. The objective for this project included automating Snap’s build process onto Windows through a build script and creating three separate collector plugins based on the Windows’ Perfmon, Active Directory, and Sysinternals applications. -
Interacting Modelica Using a Named Pipe for Hardware-In-The-Loop Simulation
Interacting Modelica using a Named Pipe for Hardware-in-the-loop Simulation Interacting Modelica using a Named Pipe for Hardware-in-the-loop Simulation Arno Ebner Anton Haumer Dragan Simic Franz Pirker Arsenal Research Giefinggasse 2, 1210 Vienna, Austria phone: +43 50550 6663, fax: +43 50550 6595, e-mail: [email protected] Abstract tion for the system model considering the initial val- ues. The paper presents a concept and an implementation In some cases the user or other applications have to of Modelica simulation interaction using the operat- interact with the simulation, for example to: ing system inter-process communication method of • Start or interrupt the simulation the Named Pipe. The main aim of this presented • Change parameters or variables during the simu- work is to implement a hardware-in-the-loop simula- lation tion (HILS) environment based on Dymola which • Communicate with other applications, for exam- runs on a normal Microsoft Windows Personal Com- ple with another simulation environment puter. • Exchange data with an input/output-card or a pe- An energy storage test bench is connected by an ana- ripheral communication interface logue and digital data input/output card with the Dy- • Build up a hardware-in-the-loop simulation envi- mola simulation computer. With this proposed sys- ronment tem, particularly long-time simulations with sample rates up to 30 Hz can be executed very cost effective. Hardware-in-the-loop (HIL) is the integration of real Typical applications are simulations of drive cycles components and system models in a common simu- to test energy storage systems in electrified vehicles lation environment [1]. -
Linux/Unix Inter-Process Communication
Mohammad S. Hasan Faculty of Computing, Engineering & Technology Linux/Unix inter-process communication Mohammad S. Hasan Staffordshire University, UK Linux/Unix inter-process communication Slide 1 Mohammad S. Hasan Faculty of Computing, Engineering & Technology Lecture Outline Inter-process communication methods in Linux/Unix Files Pipes FIFOs Signals Sockets System V IPC - semaphores, messages, shared memory Linux/Unix inter-process communication Slide 2 Mohammad S. Hasan Faculty of Computing, Engineering & Technology Interprocess communication (IPC) There are many interprocess communication mechanisms in UNIX and Linux Each mechanism has its own system calls, advantages and disadvantages Files, pipes, FIFOs, signals, semaphores, messages, shared memory, sockets, streams We will look a number of them Linux/Unix inter-process communication Slide 3 Mohammad S. Hasan Faculty of Computing, Engineering & Technology Interprocess communication (IPC) (Cont.) Linux/Unix inter-process communication Slide 4 Mohammad S. Hasan Faculty of Computing, Engineering & Technology Files These can handle simple IPC but have 2 P1 main problems for serious IPC work: Writer if reader faster than writer, then reader reads EOF, but cannot tell whether it has simply caught up with writer or writer has File …. completed (synchronisation problem) …. …. writer only writes to end of file, thus files EOF can grow very large for long lived processes (disk/memory space problem) P2 Reader Linux/Unix inter-process communication Slide 5 Mohammad S. Hasan Faculty of Computing, Engineering & Technology Pipes You should already be familiar with pipe from practical exercises e.g. who | sort This sets up a one directional pipeline that takes the output from ‘who’ and gives it as input to ‘sort’ Linux/Unix inter-process communication Slide 6 Mohammad S. -
Automate Windows Environments with Ansible
Automate Windows Environments with Ansible Orcun Atakan [email protected] Sr. Solution Architect, Red Hat ANSIBLE AUTOMATION FOR WINDOWS What we’ll be discussing today What is Ansible? Windows Management with Ansible What is DSC? Why Use Ansible with DSC? Demo: Rolling update of a .NET application on Windows 2 37,000+ 2800+ 500,000+ Stars on GitHub Ansible modules Downloads a month 3 WHY ANSIBLE? (for Windows) SIMPLE POWERFUL AGENTLESS Human readable automation Enable many use cases Ideal for Windows remoting No special coding skills needed Works hand-in-hand with DSC resources No agents to exploit or update Tasks executed in order Easy platform enablement Standards-based WinRM Usable by every team Leverage Powershell Get productive quickly ANSIBLE AUTOMATION WORKS ACROSS TEAMS BUSINESS DEV/QA COMPUTE NETWORK/SECURITY I.T. OPERATIONS 5 WINDOWS AUTOMATION 100+ 1,300+ Windows Powershell DSC Modules resources ansible.com/windows WHAT CAN I DO USING ANSIBLE FOR WINDOWS Native Windows support uses PowerShell remoting to manage Windows in the same Ansible agentless way ● Install and uninstall MSIs ● Gather facts on Windows hosts ● Enable and disable Windows features ● Start, stop, and manage Windows Services ● Create and Manage local users and groups ● Manage Windows packages via Chocolatey package manager ● Manage and install Windows updates ● Fetch files from remote sites ● Push and execute any Powershell scripts 7 Playbook Example 1/2 - hosts: new_servers tasks: - name: ensure common OS updates are current win_updates: register: update_result -
System Calls & Signals
CS345 OPERATING SYSTEMS System calls & Signals Panagiotis Papadopoulos [email protected] 1 SYSTEM CALL When a program invokes a system call, it is interrupted and the system switches to Kernel space. The Kernel then saves the process execution context (so that it can resume the program later) and determines what is being requested. The Kernel carefully checks that the request is valid and that the process invoking the system call has enough privilege. For instance some system calls can only be called by a user with superuser privilege (often referred to as root). If everything is good, the Kernel processes the request in Kernel Mode and can access the device drivers in charge of controlling the hardware (e.g. reading a character inputted from the keyboard). The Kernel can read and modify the data of the calling process as it has access to memory in User Space (e.g. it can copy the keyboard character into a buffer that the calling process has access to) When the Kernel is done processing the request, it restores the process execution context that was saved when the system call was invoked, and control returns to the calling program which continues executing. 2 SYSTEM CALLS FORK() 3 THE FORK() SYSTEM CALL (1/2) • A process calling fork()spawns a child process. • The child is almost an identical clone of the parent: • Program Text (segment .text) • Stack (ss) • PCB (eg. registers) • Data (segment .data) #include <sys/types.h> #include <unistd.h> pid_t fork(void); 4 THE FORK() SYSTEM CALL (2/2) • The fork()is one of the those system calls, which is called once, but returns twice! Consider a piece of program • After fork()both the parent and the child are ..