DOCSLIB.ORG

Junos® OS Release 19.3R3 for the ACX Series, EX Series, MX Series, NFX Series, PTX Series, QFX Series, SRX Series, and Junos Fusion

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Junos® OS Release 19.3R3 for the ACX Series, EX Series, MX Series, NFX Series, PTX Series, QFX Series, SRX Series, and Junos Fusion 1 Release Notes: Junos® OS Release 19.3R3 for the ACX Series, EX Series, MX Series, NFX Series, PTX Series, QFX Series, SRX Series, and Junos Fusion 15 July 2021 Contents Introduction | 10 Junos OS Release Notes for ACX Series | 10 What's New | 11 What's New in Release 19.3R3 | 11 What's New in Release 19.3R2 | 11 What’s New in Release 19.3R1-S1 | 11 What's New in Release 19.3R1 | 12 What's Changed | 19 What’s Changed in Release 19.3R3-S1 | 20 What's Changed in Release 19.3R3 | 20 What's Changed in Release 19.3R2-S6 | 20 What's Changed in Release 19.3R2 | 21 What's Changed in Release 19.3R1 | 21 Known Limitations | 23 General Routing | 23 Open Issues | 25 General Routing | 25 Platform and Infrastructure | 27 Virtual Chassis | 27 2 Resolved Issues | 27 Resolved Issues: 19.3R3 | 28 Resolved Issues: 19.3R2 | 30 Resolved Issues: 19.3R1 | 31 Documentation Updates | 34 Migration, Upgrade, and Downgrade Instructions | 35 Upgrade and Downgrade Support Policy for Junos OS Releases | 35 Junos OS Release Notes for EX Series Switches | 37 What's New | 37 What's New in 19.3R3 | 38 What's New in 19.3R2 | 38 What's New in 19.3R1 | 39 What's Changed | 47 What's Changed in 19.3R3 | 48 What's Changed in Release 19.3R2-S6 | 49 What's Changed in 19.3R2 | 50 What's Changed in 19.3R1 | 50 Known Limitations | 51 EVPN | 52 Infrastructure | 52 Platform and Infrastructure | 52 Open Issues | 53 Authentication and Access Control | 53 Infrastructure | 53 Interfaces and Chassis | 54 Layer 2 Features | 54 Network Management and Monitoring | 54 Platform and Infrastructure | 54 Virtual Chassis | 55 Resolved Issues | 56 Resolved Issues: 19.3R3 | 56 Resolved Issues: 19.3R2 | 61 Resolved Issues: 19.3R1 | 63 Layer 2 Ethernet Services | 64 3 Network Management and Monitoring | 64 Platform and Infrastructure | 64 Routing Protocols | 67 Subscriber Access Management | 68 User Interface and Configuration | 68 Virtual Chassis | 68 VPNs | 68 Documentation Updates | 68 Migration, Upgrade, and Downgrade Instructions | 69 Upgrade and Downgrade Support Policy for Junos OS Releases | 69 Junos OS Release Notes for Junos Fusion Enterprise | 70 What’s New | 71 What's New in Release 19.3R3 | 71 What's New in Release 19.3R2 | 71 What's New in Release 19.3R1 | 71 What’s Changed | 72 Known Limitations | 72 Open Issues | 73 Junos Fusion for Enterprise | 73 Resolved Issues | 74 Resolved Issues: 19.3R3 | 74 Resolved Issues: 19.3R2 | 74 Resolved Issues: 19.3R1 | 74 Documentation Updates | 75 Migration, Upgrade, and Downgrade Instructions | 75 Basic Procedure for Upgrading Junos OS on an Aggregation Device | 76 Upgrading an Aggregation Device with Redundant Routing Engines | 77 Preparing the Switch for Satellite Device Conversion | 78 Converting a Satellite Device to a Standalone Switch | 79 Upgrade and Downgrade Support Policy for Junos OS Releases | 79 Downgrading from Junos OS | 80 4 Junos OS Release Notes for Junos Fusion Provider Edge | 81 What's New | 81 What's New in Release 19.3R3 | 82 What's New in Release 19.3R2 | 82 What's New in Release 19.3R1 | 82 What's Changed | 82 Known Limitations | 83 Junos Fusion Provider Edge | 83 Open Issues | 84 Junos Fusion Provider Edge | 84 Resolved Issues | 85 Resolved Issues: 19.3R3 | 85 Resolved Issues: 19.3R2 | 85 Resolved Issues: 19.3R1 | 85 Documentation Updates | 86 Migration, Upgrade, and Downgrade Instructions | 86 Basic Procedure for Upgrading an Aggregation Device | 87 Upgrading an Aggregation Device with Redundant Routing Engines | 89 Preparing the Switch for Satellite Device Conversion | 90 Converting a Satellite Device to a Standalone Device | 91 Upgrading an Aggregation Device | 94 Upgrade and Downgrade Support Policy for Junos OS Releases | 94 Downgrading from Junos OS Release 19.3 | 94 Junos OS Release Notes for MX Series 5G Universal Routing Platform | 95 What's New | 96 What’s New in Release 19.3R3 | 96 What’s New in Release 19.3R2 | 96 What’s New in Release 19.3R1 | 115 What's Changed | 134 What’s Changed in Release 19.3R3-S1 | 135 What’s Changed in Release 19.3R3 | 135 What's Changed in Release 19.3R2-S6 | 138 What’s Changed in Release 19.3R2-S5 | 139 What’s Changed in Release 19.3R2 | 139 5 What’s Changed in Release 19.3R1 | 142 Known Limitations | 146 General Routing | 146 Infrastructure | 149 Interfaces and Chassis | 149 MPLS | 150 Platform and Infrastructure | 150 Routing Protocols | 151 Open Issues | 151 EVPN | 152 Forwarding and Sampling | 153 General Routing | 153 Infrastructure | 161 Interfaces and Chassis | 161 Layer 2 Ethernet Services | 162 MPLS | 162 Platform and Infrastructure | 163 Routing Protocols | 164 Services Applications | 166 Subscriber Access Management | 166 User Interface and Configuration | 166 VPNs | 166 Resolved Issues | 167 Resolved Issues: 19.3R3 | 167 Resolved Issues: 19.3R2 | 186 Resolved Issues: 19.3R1 | 195 Documentation Updates | 214 Migration, Upgrade, and Downgrade Instructions | 215 Basic Procedure for Upgrading to Release 19.3 | 216 Procedure to Upgrade to FreeBSD 11.x based Junos OS | 216 Procedure to Upgrade to FreeBSD 6.x based Junos OS | 219 Upgrade and Downgrade Support Policy for Junos OS Releases | 220 Upgrading a Router with Redundant Routing Engines | 221 Downgrading from Release 19.3 | 221 6 Junos OS Release Notes for NFX Series | 222 What’s New | 222 Release 19.3R3 New and Changed Features | 223 Release 19.3R2 New and Changed Features | 223 Release 19.3R1 New and Changed Features | 223 What's Changed | 224 What's Changed in Release 19.3R2-S6 | 224 Known Limitations | 225 Interfaces | 225 Platform and Infrastructure | 225 Virtual Network Functions (VNFs) | 226 Open Issues | 226 Interfaces | 226 High Availability (HA) | 227 Platform and Infrastructure | 227 Virtual Network Functions (VNFs) | 227 Resolved Issues | 228 Resolved Issues: 19.3R3 | 228 Resolved Issues: 19.3R2 | 229 Resolved Issues: 19.3R1 | 230 Documentation Updates | 232 Migration, Upgrade, and Downgrade Instructions | 232 Upgrade and Downgrade Support Policy for Junos OS Releases | 232 Basic Procedure for Upgrading to Release 19.3 | 233 Junos OS Release Notes for PTX Series Packet Transport Routers | 234 What's New | 235 What's New in Release 19.3R3 | 235 What's New in Release 19.3R2 | 235 What's New in Release 19.3R1 | 236 What's Changed | 243 What’s Changed in Release 19.3R3-S1 | 244 What's Changed in Release 19.3R3 | 244 Juniper Extension Toolkit (JET) | 245 What's Changed in Release 19.3R2-S6 | 245 7 What's Changed in Release 19.3R2 | 246 What's Changed in Release 19.3R1 | 246 Known Limitations | 248 General Routing | 248 Interfaces and Chassis | 249 Open Issues | 249 General Routing | 249 Routing Protocols | 250 Resolved Issues | 251 Resolved Issues: Release 19.3R3 | 251 Resolved Issues: Release 19.3R2 | 254 Resolved Issues: Release 19.3R1 | 255 Documentation Updates | 257 Migration, Upgrade, and Downgrade Instructions | 258 Basic Procedure for Upgrading to Release 19.3 | 258 Upgrade and Downgrade Support Policy for Junos OS Releases | 261 Upgrading a Router with Redundant Routing Engines | 262 Junos OS Release Notes for the QFX Series | 263 What's New | 263 What’s New in Release 19.3R3 | 264 What’s New in Release 19.3R2 | 264 What’s New in Release 19.3R1 | 264 What's Changed | 272 What’s Changed in Release 19.3R3-S1 | 273 What's Changed in Release 19.3R3 | 273 What's Changed in Release 19.3R2-S6 | 275 What's Changed in Release 19.3R2 | 276 What's Changed in Release 19.3R1 | 276 Known Limitations | 279 Class of Service (CoS) | 280 EVPN | 280 Platform and Infrastructure | 280 Infrastructure | 281 Layer 2 Features | 281 8 Routing Protocols | 282 Open Issues | 282 EVPN | 283 High Availability (HA) and Resiliency | 283 Infrastructure | 283 Interfaces and Chassis | 283 Junos Fusion Provider Edge | 284 Layer 2 Features | 284 Platform and Infrastructure | 284 Routing Protocols | 286 Virtual Chassis | 287 Resolved Issues | 287 Resolved Issues: Release 19.3R3 | 288 Resolved Issues: Release 19.3R2 | 296 Resolved Issues: Release 19.3R1 | 300 Documentation Updates | 307 Migration, Upgrade, and Downgrade Instructions | 308 Upgrading Software on QFX Series Switches | 308 Installing the Software on QFX10002-60C Switches | 311 Installing the Software on QFX10002 Switches | 311 Upgrading Software from Junos OS Release 15.1X53-D3X to Junos OS Release 15.1X53-D60, 15.1X53-D61.7, 15.1X53-D62, and 15.1X53-D63 on QFX10008 and QFX10016 Switches | 312 Installing the Software on QFX10008 and QFX10016 Switches | 314 Performing a Unified ISSU | 318 Preparing the Switch for Software Installation | 319 Upgrading the Software Using Unified ISSU | 319 Upgrade and Downgrade Support Policy for Junos OS Releases | 321 Junos OS Release Notes for SRX Series | 322 What’s New | 323 What’s New in Release 19.3R3 | 323 What’s New in Release 19.3R2 | 323 9 What’s New in Release 19.3R1 | 323 What's Changed | 331 What's Changed in Release 19.3R3 | 332 What's Changed in Release 19.3R2-S6 | 333 What's Changed in Release 19.3R2 | 334 What's Changed in Release 19.3R1 | 334 Known Limitations | 336 Authentication and Access Control | 337 J-Web | 337 Logical Systems and Tenant Systems | 338 Platform and Infrastructure | 338 VPNs | 338 Open Issues | 339 Flow-Based and Packet-Based Processing | 339 Intrusion Detection and Prevention (IDP) | 339 J-Web | 340 Routing Policy and Firewall Filters | 340 VPNs | 340 Resolved Issues | 341 Resolved Issues: Release 19.3R3 | 341 Resolved Issues: Release 19.3R2 | 347 Resolved Issues: Release 19.3R1 | 350 Documentation Updates | 358 Migration, Upgrade, and Downgrade Instructions | 358 Upgrade and Downgrade Support Policy for Junos OS Releases and Extended End-Of-Life Releases | 359 Upgrading Using ISSU | 360 Licensing | 360 Finding More Information | 361 Documentation Feedback | 361 Requesting Technical Support | 362 Self-Help Online Tools and Resources | 362 Opening a Case with JTAC | 363 Revision History | 363 10 Introduction Junos OS runs on the following Juniper Networks® hardware: ACX Series, EX Series, M Series, MX Series, NFX Series, PTX Series, QFabric systems, QFX Series, SRX Series, T Series, and Junos Fusion.
Load more

Recommended publications
  • A Lecture Note on Csc 322 Operating System I by Dr
    A LECTURE NOTE ON CSC 322 OPERATING SYSTEM I BY DR. S. A. SODIYA 1 SECTION ONE 1.0 INTRODUCTION TO OPERATING SYSTEMS 1.1 DEFINITIONS OF OPERATING SYSTEMS An operating system (commonly abbreviated OS and O/S) is the infrastructure software component of a computer system; it is responsible for the management and coordination of activities and the sharing of the limited resources of the computer. An operating system is the set of programs that controls a computer. The operating system acts as a host for applications that are run on the machine. As a host, one of the purposes of an operating system is to handle the details of the operation of the hardware. This relieves application programs from having to manage these details and makes it easier to write applications. Operating Systems can be viewed from two points of views: Resource manager and Extended machines. From Resource manager point of view, Operating Systems manage the different parts of the system efficiently and from extended machines point of view, Operating Systems provide a virtual machine to users that is more convenient to use. 1.2 HISTORICAL DEVELOPMENT OF OPERATING SYSTEMS Historically operating systems have been tightly related to the computer architecture, it is good idea to study the history of operating systems from the architecture of the computers on which they run. Operating systems have evolved through a number of distinct phases or generations which corresponds roughly to the decades. The 1940's - First Generation The earliest electronic digital computers had no operating systems. Machines of the time were so primitive that programs were often entered one bit at a time on rows of mechanical switches (plug boards).
    [Show full text]
  • Optimizing Storage Performance with Calibrated Interrupts
    Optimizing Storage Performance with Calibrated Interrupts Amy Tai, VMware Research; Igor Smolyar, Technion — Israel Institute of Technology; Michael Wei, VMware Research; Dan Tsafrir, Technion — Israel Institute of Technology and VMware Research https://www.usenix.org/conference/osdi21/presentation/tai This paper is included in the Proceedings of the 15th USENIX Symposium on Operating Systems Design and Implementation. July 14–16, 2021 978-1-939133-22-9 Open access to the Proceedings of the 15th USENIX Symposium on Operating Systems Design and Implementation is sponsored by USENIX. Optimizing Storage Performance with Calibrated Interrupts Amy Tai‡∗ Igor Smolyar†∗ Michael Wei‡ Dan Tsafrir†‡ †Technion – Israel Institute of Technology ‡VMware Research Abstract ever, creates a trade-off between request latency and the inter- After request completion, an I/O device must decide either rupt rate. For the workloads we inspected, CPU utilization in- to minimize latency by immediately firing an interrupt or to creases by as much as 55% without coalescing (Figure 12(d)), optimize for throughput by delaying the interrupt, anticipating while under even the minimum amount of coalescing, request that more requests will complete soon and help amortize the latency increases by as much as 10× for small requests, due interrupt cost. Devices employ adaptive interrupt coalescing to large timeouts. Interrupt coalescing is disabled by default heuristics that try to balance between these opposing goals. in Linux, and real deployments use alternatives (§2). Unfortunately, because devices lack the semantic information This paper addresses the challenge of dealing with expo- about which I/O requests are latency-sensitive, these heuris- nentially increasing interrupt rates without sacrificing latency.
    [Show full text]
  • Fitting Linux Device Drivers Into an Analyzable Scheduling Framework
    Fitting Linux Device Drivers into an Analyzable Scheduling Framework [Extended Abstract] ∗ Theodore P. Baker, An-I Andy Wang, Mark J. Stanovich Florida State University Tallahassee, Florida 32306-4530 [email protected], [email protected], [email protected] ABSTRACT models of the theory. More specifically, applying the theory re- quires that the system workload corresponds to models that have API extensions and performance improvements to the Linux oper- been studied, and that the system schedules the workload accord- ating system now enable it to serve as a platform for a range of ing to one of the algorithms whose performance on such workloads embedded real-time applications, using fixed-priority preemptive has been analyzed. Where a real-time system is implemented on scheduling. Powerful techniques exist for analytical verification of top of an operating system, these requirements apply to all the OS application timing constraints under this scheduling model. How- components as well as the user-level code. ever, when the application is layered over an operating system the operating system must be included in the analysis. In particular, In Linux and several other POSIX/Unix-compliant [31] operating the computational workloads due to device drivers and other in- systems, progress has been made in providing real-time constructs ternal components of the operating system, and the ways they are so that user-level programmers can write applications that adhere scheduled, need to match abstract workload models and schedul- to the theory of fixed-priority preemptive scheduling. Examples in- ing polices that are amenable to analysis. This paper assesses the clude preemptive priority-based real-time scheduling of user threads, degree to which the effects of device drivers in Linux can now be high-precision software timers, and turning off virtual memory man- modeled adequately to admit fixed-priority preemptive schedula- agement for certain memory regions.
    [Show full text]
  • Tolerating Malicious Device Drivers in Linux
    Tolerating Malicious Device Drivers in Linux Silas Boyd-Wickizer and Nickolai Zeldovich MIT CSAIL ABSTRACT driver isolation techniques trust the driver not to subvert the isolation, or not to livelock the system. If attackers This paper presents SUD, a system for running existing Linux device drivers as untrusted user-space processes. exploit a bug in the device driver [1, 5], they can proceed Even if the device driver is controlled by a malicious to subvert the isolation mechanism and compromise the adversary, it cannot compromise the rest of the system. entire system. While some systems can provide stronger One significant challenge of fully isolating a driver is to guarantees [28, 33], they rely on the availability of a fully- trusted, precise specification of the hardware device’s confine the actions of its hardware device. SUD relies on IOMMU hardware, PCI express bridges, and message- behavior, which is rarely available for devices today. signaled interrupts to confine hardware devices. SUD This paper presents the design and implementation of runs unmodified Linux device drivers, by emulating a SUD, a kernel framework that provides complete isolation Linux kernel environment in user-space. A prototype of for untrusted device drivers in Linux, without the need SUD runs drivers for Gigabit Ethernet, 802.11 wireless, for any special programming languages or specifications. sound cards, USB host controllers, and USB devices, and SUD leverages recent hardware support to implement it is easy to add a new device class. SUD achieves the general-purpose mechanisms that ensure a misbehaving same performance as an in-kernel driver on networking driver, and the hardware device that it manages, cannot benchmarks, and can saturate a Gigabit Ethernet link.
    [Show full text]
  • CS 4310: Operating Systems Lecture Notes - Student Version∗
    CS 4310: Operating Systems Lecture Notes - Student Version∗ Kyle Burke January 10, 2018 Contents -1.0 Using Chapel . 2 0 OS Basics 2 0.1 Interrupts . 2 1 Parallel Programming (using Chapel) 2 2 Hardware Threads 2 3 Concurrency 3 4 Semaphores 4 5 The Producer-Consumer Problem 4 5.1 Circular Queues . 4 6 Memory Management 6 7 Stack vs. Heap 8 7.1 Stack Management . 9 7.2 Heap Management . 9 8 Scheduling 9 8.1 Shortest-Job First . 10 8.2 First Come, First Serve . 13 8.3 Earliest-Deadline First . 14 8.4 Round Robin . 15 8.5 Hybrid Schedulers . 15 8.6 Examples . 15 9 Interrupts 20 10 File Systems 24 10.1 Fragmentation . 27 11 OS Security 31 12 History of OSes by Candace 31 ∗Created with lectureNotes.sty, which is available at: http://turing.plymouth.edu/~kgb1013/lectureNotesLatexStyle.php (or, GitHub: https://github.com/paithan/LaTeX-LectureNotes). Many or most of the answers to questions are hidden so that some of class will still be a challenge for students. 1 -1.0 Using Chapel 2 HARDWARE THREADS -1.0 Using Chapel This course was last taught with programming assignments given in Chapel1 using compiler version 1.14. This is a High-Performance Computing language designed to make parallel programming easier for computational scientists. Here are some comments about this language. • It makes launching threads and handling synchronization very easy. • It is missing many of the basic libraries that exist for common languages (e.g. Java). • Goal: focus on the 0 OS Basics 〈 Go over syllabus! 〉 Q: What are the responsibilities of an Operating System? What do they do? A: • TODO 0.1 Interrupts This material is currently in 9.
    [Show full text]
  • Towards Predictable Real-Time Performance on Multi-Core Platforms
    Towards Predictable Real-Time Performance on Multi-Core Platforms Submitted in partial fulfillment of the requirements for the degreee of Doctor of Philosophy in Electrical and Computer Engineering Hyoseung Kim B.S., Computer Science, Yonsei University, Seoul, Korea M.S., Computer Science, Yonsei University, Seoul, Korea arXiv:1607.08578v1 [cs.DC] 28 Jul 2016 Carnegie Mellon University Pittsburgh, PA, USA June 2016 Copyright © 2016 Hyoseung Kim Keywords: Cyber-physical systems, Real-time embedded systems, Safety-critical systems, Multi-core platforms, Operating systems, Virtualization, Predictable performance. Abstract Cyber-physical systems (CPS) integrate sensing, computing, communication and actu- ation capabilities to monitor and control operations in the physical environment. A key requirement of such systems is the need to provide predictable real-time performance: the timing correctness of the system should be analyzable at design time with a quantitative metric and guaranteed at runtime with high assurance. This requirement of predictability is particularly important for safety-critical domains such as automobiles, aerospace, defense, manufacturing and medical devices. The work in this dissertation focuses on the challenges arising from the use of modern multi-core platforms in CPS. Even as of today, multi-core platforms are rarely used in safety-critical applications primarily due to the temporal interference caused by contention on various resources shared among processor cores, such as caches, memory buses, and I/O devices. Such interference is hard to predict and can significantly increase task execution time, e.g., up to 12× on commodity quad-core platforms. To address the problem of ensuring timing predictability on multi-core platforms, we develop novel analytical and systems techniques in this dissertation.
    [Show full text]
  • Shared IRQ Line Considerations AN-PM-059
    Application Note Shared IRQ Line Considerations AN-PM-059 Abstract When IRQ line-sharing between multiple devices has been imposed by the target hardware design, a system failure may occur that is intrinsic to the Linux kernel. This document outlines recommendations to avoid such issues. Several solutions have been identified and each should be considered on its merits for the target platform under examination. AN-PM-059 Shared IRQ Line Considerations Contents Abstract ................................................................................................................................................ 1 Contents ............................................................................................................................................... 2 Figures .................................................................................................................................................. 2 1 Terms and Definitions ................................................................................................................... 3 2 References ..................................................................................................................................... 3 3 Introduction.................................................................................................................................... 4 4 Shared Interrupt Line .................................................................................................................... 4 4.1 Symptoms and Mode of Failure in the Linux
    [Show full text]
  • Towards Predictable Real-Time Performance on Multi-Core Platforms
    Towards Predictable Real-Time Performance on Multi-Core Platforms Submitted in partial fulfillment of the requirements for the degreee of Doctor of Philosophy in Electrical and Computer Engineering Hyoseung Kim B.S., Computer Science, Yonsei University, Seoul, Korea M.S., Computer Science, Yonsei University, Seoul, Korea Carnegie Mellon University Pittsburgh, PA, USA June 2016 Copyright © 2016 Hyoseung Kim Keywords: Cyber-physical systems, Real-time embedded systems, Safety-critical systems, Multi-core platforms, Operating systems, Virtualization, Predictable performance. Abstract Cyber-physical systems (CPS) integrate sensing, computing, communication and actu- ation capabilities to monitor and control operations in the physical environment. A key requirement of such systems is the need to provide predictable real-time performance: the timing correctness of the system should be analyzable at design time with a quantitative metric and guaranteed at runtime with high assurance. This requirement of predictability is particularly important for safety-critical domains such as automobiles, aerospace, defense, manufacturing and medical devices. The work in this dissertation focuses on the challenges arising from the use of modern multi-core platforms in CPS. Even as of today, multi-core platforms are rarely used in safety-critical applications primarily due to the temporal interference caused by contention on various resources shared among processor cores, such as caches, memory buses, and I/O devices. Such interference is hard to predict and can significantly increase task execution time, e.g., up to 12× on commodity quad-core platforms. To address the problem of ensuring timing predictability on multi-core platforms, we develop novel analytical and systems techniques in this dissertation.
    [Show full text]
  • Tolerating Malicious Device Drivers in Linux
    Tolerating Malicious Device Drivers in Linux The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Boyd-Wickizer, Silas and Nickolai Zeldovich. "Tolerating Malicious Device Drivers in Linux" USENIX Annual Technical Conference, June 23–25, 2010, Boston, MA, USA. As Published http://www.usenix.org/events/atc10/tech/full_papers/Boyd- Wickizer.pdf Publisher USENIX Association Version Author's final manuscript Citable link http://hdl.handle.net/1721.1/62238 Terms of Use Creative Commons Attribution-Noncommercial-Share Alike 3.0 Detailed Terms http://creativecommons.org/licenses/by-nc-sa/3.0/ Tolerating Malicious Device Drivers in Linux Silas Boyd-Wickizer and Nickolai Zeldovich MIT CSAIL ABSTRACT driver isolation techniques trust the driver not to subvert the isolation, or not to livelock the system. If attackers This paper presents SUD, a system for running existing Linux device drivers as untrusted user-space processes. exploit a bug in the device driver [1, 5], they can proceed Even if the device driver is controlled by a malicious to subvert the isolation mechanism and compromise the adversary, it cannot compromise the rest of the system. entire system. While some systems can provide stronger One significant challenge of fully isolating a driver is to guarantees [28, 33], they rely on the availability of a fully- trusted, precise specification of the hardware device’s confine the actions of its hardware device. SUD relies on IOMMU hardware, PCI express bridges, and message- behavior, which is rarely available for devices today. signaled interrupts to confine hardware devices. SUD This paper presents the design and implementation of runs unmodified Linux device drivers, by emulating a SUD, a kernel framework that provides complete isolation Linux kernel environment in user-space.
    [Show full text]
  • 111I.®@@ , Iw J , J '5 Expected 5 Expected 3 a Return to Timer :Ltimer Firings Normal Mode Duration W '5 L Expected 7 Timer Firings,Y Received 3
    US008533709B2 (12) United States Patent (10) Patent No.: US 8,533,709 B2 Nicholas et al. (45) Date of Patent: Sep. 10, 2013 (54) VIRTUALCHANGINGPROGRAMMABLE MACHINES FREQUENCY INTERRUPT T0 CONTROL OFAVIRTUAL TIMER IN 200336614073232006/0090092 A1 * 4/2006 Verhulstgakdiinentetlai‘if n e ......................a ' "" ~~~~~~~~~~~~ " ~~.. 713/400 VIRTUAL TIME OTHER PUBLICATIONS . Mock et a1. “Continuous clock s chroniZation in Wireless real-time (75) Inventors: Andrew Ernest Nicholas’ Beinevue’ WA applications”, Reliable Distributzid1 Systems, 2000, p. 125-132).* (Us); Rene Anton“) Vega’ Klrkland’ WA Cristian et a1. (“Clock Synchronization in the Presence of Omission (Us) and Performance Failures, and Processor Joins”, IBM Research, 16th IEEE Int. Symp. On Fault-tolerant Computing Systems, Vienna, Jul. (73) Assignee: Microsoft Cororation, Redmond, WA 19g6),* (US) Honeycutt, J., “Microsoft® Virtual PC”, Microsoft®, Nov. 2003, 1-27. ( * ) Notice: Subject to any disclaimer, the term of this patent is extended or adjusted under 35 * Cited by examiner U.S.C. 154(b) by 1649 days. Primary Examiner * Meng An (21) Appl. No.1 11/197,614 Assistant Examiner * Eric C Wai (74) Attorney, Agent, or Firm * Woodcock Washburn, LLP (22) Filed: Aug. 4, 2005 (57) ABSTRACT (65) Prior Publication Data . A catch-up mode that runs a v1rtua1 programmable rnterrupt US 2007/0033589 A1 Feb. 8, 2007 timer faster than a nominal rate to prevent time loss in a virtual machine can be implemented. If time loss is determined, a (51) Int- Cl- catch-up mode can be initiated to cause increased ?rings, G06F 9/45 5 (2006-01) beyond a nominal rate, of the programmable interrupt timer to (52) US Cl- adjust the clock of the virtual machine to the clock of the host USPC ...........................................................
    [Show full text]
  • Interrupt Storm Detection" Feature
    Development of "Interrupt Storm Detection" Feature October 2020 Issued by Kento Kobayashi, R&D Center, Sony Corporation Copyright 2020 Sony Corporation Agenda • Background • What is interrupt storm? • Cases of interrupt storms • Existing ways to debug interrupt storms for each cases • Our solution • Interrupt storm detection feature • Example of using interrupt storm detection feature for actual problem 2 26.Oct.2020 R&D Center, Sony Corporation Self introduction • Name • Kento Kobayashi • Company • Sony Corporation • Responsible for • Linux kernel and device drivers for Sony products. 3 26.Oct.2020 R&D Center, Sony Corporation Background 4 26.Oct.2020 R&D Center, Sony Corporation What is “Interrupt Storm”? • “Interrupt Storm” is a continuous hardware interrupt to CPU. • CPU needs to execute interrupt handlers continuously. • “Interrupt Storm” causes: • System hang-up due to high CPU utilization by the interrupt handler • Difficult to debug because console is not responding • To debug interrupt storm: # of Interrupts • Need to identify IRQ number which causes interrupt storm. • Cases of “Interrupt Storm”: • Case1 : Unhandled(Spurious) interrupt • Case2 : High-frequency handled interrupt time 5 26.Oct.2020 R&D Center, Sony Corporation Case1 : Unhandled(Spurious) interrupt • What is “Unhandled(Spurious) interrupt”? • Interrupt handler doesn’t handle hardware interrupt • Why “Unhandled(Spurious) interrupt” occur? • Problem of device driver. • Interrupt handler do nothing if that interrupt is not own interrupt. • Then interrupt status is not clear, so interrupt is raised continuously. • Example of “Unhandled(Spurious) interrupt” case • Shared IRQ by multiple device driver. • Interrupt handler is executed whether not own interrupt. • Then if interrupt handler not recognize as own interrupt wrongly, nobody handled raised interrupt.
    [Show full text]
  • Comparing and Improving Current Packet Capturing Solutions Based on Commodity Hardware
    Comparing and Improving Current Packet Capturing Solutions based on Commodity Hardware Lothar Braun, Alexander Didebulidze, Nils Kammenhuber, Georg Carle Technische Universität München Institute for Informatics Chair for Network Architectures and Services {braun,didebuli,kammenhuber,carle}@net.in.tum.de ABSTRACT tured by Endace [1]—was mandatory for capturing Gigabit Capturing network traffic with commodity hardware has be- or Multi-gigabit network traffic, if little or no packet loss was come a feasible task: Advances in hardware as well as soft- a requirement. With recent development progresses in bus ware have boosted off-the-shelf hardware to performance lev- systems, multi-core CPUs and commodity network cards, els that some years ago were the domain of expensive special- nowadays off-the-shelf hardware can be used to capture net- purpose hardware. However, the capturing hardware still work traffic at near wire-speed with little or no packet loss needs to be driven by a well-performing software stack in in 1 GE networks, too [2, 3]. People are even building mon- order to minimise or avoid packet loss. Improving the cap- itoring devices based on commodity hardware that can be turing stack of Linux and FreeBSD has been an extensively used to capture traffic in 10 GE networks [4, 5] covered research topic in the past years. Although the ma- However, this is not an easy task, since it requires careful jority of the proposed enhancements have been backed by configuration and optimization of the hardware and software evaluations, these have mostly been conducted on different components involved—even the best hardware will suffer hardware platforms and software versions, which renders a packet loss if its driving software stack is not able to handle comparative assessment of the various approaches difficult, the huge amount of network packets.
    [Show full text]