<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type="text/xsl" href="static/style.xsl"?><OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"><responseDate>2026-09-18T18:20:21Z</responseDate><request verb="GetRecord" identifier="oai:dspace.mit.edu:1721.1/128627" metadataPrefix="dim">https://dspace.mit.edu/server/oai/request</request><GetRecord><record><header><identifier>oai:dspace.mit.edu:1721.1/128627</identifier><datestamp>2026-06-06T00:48:38Z</datestamp><setSpec>com_1721.1_7582</setSpec><setSpec>com_1721.1_7581</setSpec><setSpec>col_1721.1_131023</setSpec></header><metadata><dim:dim xmlns:dim="http://www.dspace.org/xmlns/dspace/dim" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:doc="http://www.lyncode.com/xoai" xsi:schemaLocation="http://www.dspace.org/xmlns/dspace/dim http://www.dspace.org/schema/dim.xsd">
   <dim:field mdschema="dc" element="contributor" qualifier="advisor" lang="en_US">Howard Shrobe, Hamed Okhravi, and Nathan Burow.</dim:field>
   <dim:field mdschema="dc" element="contributor" qualifier="author" lang="en_US">Switzer, Jennifer F.</dim:field>
   <dim:field mdschema="dc" element="contributor" qualifier="other" lang="en_US">Massachusetts Institute of Technology. Department of Electrical Engineering and Computer Science.</dim:field>
   <dim:field mdschema="dc" element="contributor" qualifier="department" lang="en_US">Massachusetts Institute of Technology. Department of Electrical Engineering and Computer Science</dim:field>
   <dim:field mdschema="dc" element="date" qualifier="accessioned">2020-11-24T17:31:54Z</dim:field>
   <dim:field mdschema="dc" element="date" qualifier="available">2020-11-24T17:31:54Z</dim:field>
   <dim:field mdschema="dc" element="date" qualifier="copyright" lang="en_US">2020</dim:field>
   <dim:field mdschema="dc" element="date" qualifier="issued" lang="en_US">2020</dim:field>
   <dim:field mdschema="dc" element="identifier" qualifier="uri">https://hdl.handle.net/1721.1/128627</dim:field>
   <dim:field mdschema="dc" element="identifier" qualifier="oclc" lang="en_US">1204268766</dim:field>
   <dim:field mdschema="dc" element="description" lang="en_US">Thesis: M. Eng., Massachusetts Institute of Technology, Department of Electrical Engineering and Computer Science, May, 2020</dim:field>
   <dim:field mdschema="dc" element="description" lang="en_US">Cataloged from student-submitted PDF of thesis.</dim:field>
   <dim:field mdschema="dc" element="description" lang="en_US">Includes bibliographical references (pages 55-60).</dim:field>
   <dim:field mdschema="dc" element="description" qualifier="abstract" lang="en_US">Type-safe languages undertake to prevent the type confusion vulnerabilities that arise in type-unsafe languages such as C++. One such type-safe language is Rust, which provides powerful type safety guarantees [1]. However, these guarantees are valid only for a single compilation unit. That is, they may not hold when multiple separately compiled processes communicate. In this work, we explore how type confusion vulnerabilities can still arise when multiple separately compiled, internally type-safe processes share information through inter-process communication (IPC). We propose safeIPC, a tool for eliminating IPC-facilitated type confusion in Rust. safeIPC is a Rust compiler extension that detects communications over IPC and inserts runtime checks to ensure that type safety is maintained. Programs instrumented with safeIPC throw a runtime error if the type of any data received over IPC is not equivalent to the type expected. Our analysis shows that safeIPC is effective in preventing type confusion vulnerabilities not prevented by Rust alone.</dim:field>
   <dim:field mdschema="dc" element="description" qualifier="statementofresponsibility" lang="en_US">by Jennifer F. Switzer.</dim:field>
   <dim:field mdschema="dc" element="description" qualifier="degree" lang="en_US">M.Eng.</dim:field>
   <dim:field mdschema="dc" element="description" qualifier="collection" lang="en_US">M.Eng. Massachusetts Institute of Technology, Department of Electrical Engineering and Computer Science</dim:field>
   <dim:field mdschema="dc" element="format" qualifier="extent" lang="en_US">60 pages</dim:field>
   <dim:field mdschema="dc" element="language" qualifier="iso" lang="en_US">eng</dim:field>
   <dim:field mdschema="dc" element="publisher" lang="en_US">Massachusetts Institute of Technology</dim:field>
   <dim:field mdschema="dc" element="rights" lang="en_US">MIT theses may be protected by copyright. Please reuse MIT thesis content according to the MIT Libraries Permissions Policy, which is available through the URL provided.</dim:field>
   <dim:field mdschema="dc" element="rights" qualifier="uri" lang="en_US">http://dspace.mit.edu/handle/1721.1/7582</dim:field>
   <dim:field mdschema="dc" element="subject" lang="en_US">Electrical Engineering and Computer Science.</dim:field>
   <dim:field mdschema="dc" element="title" lang="en_US">Preventing IPC-facilitated type confusion in Rust</dim:field>
   <dim:field mdschema="dc" element="type" lang="en_US">Thesis</dim:field>
   <dim:field mdschema="dc" element="format" qualifier="mimetype">application/pdf</dim:field>
   <dim:field mdschema="dspace" element="imported" lang="en_US">2020-11-24T17:31:54Z</dim:field>
   <dim:field mdschema="dspace" element="entity" qualifier="type">Publication</dim:field>
   <dim:field mdschema="mit" element="thesis" qualifier="degree" lang="en_US">Master</dim:field>
   <dim:field mdschema="mit" element="thesis" qualifier="department" lang="en_US">EECS</dim:field>
   <dim:field mdschema="others" element="access-status">unknown</dim:field>
   <dim:field mdschema="others" element="access-status">unknown</dim:field>
   <dim:field mdschema="cerif" element="openaire" authority="" confidence="-1">&lt;Publication xmlns="https://www.openaire.eu/cerif-profile/1.1/" id="067ff131-9304-4c8e-8d29-85b3999bb79c">
	&lt;Type xmlns="https://www.openaire.eu/cerif-profile/vocab/COAR_Publication_Types">http://purl.org/coar/resource_type/c_1843&lt;/Type>
	&lt;Language>eng&lt;/Language>
   	&lt;Title>Preventing IPC-facilitated type confusion in Rust&lt;/Title>
   	&lt;PublishedIn>
    	&lt;Publication>
      	&lt;/Publication>
   	&lt;/PublishedIn>
   	&lt;PublicationDate>2020&lt;/PublicationDate>
   	&lt;Authors>
      	&lt;Author>
        	&lt;DisplayName>Switzer, Jennifer F.&lt;/DisplayName>
         	&lt;Affiliation>
         		&lt;OrgUnit>
         		&lt;/OrgUnit>
         	&lt;/Affiliation>
      	&lt;/Author>
	&lt;/Authors>
   	&lt;Editors>
	&lt;/Editors>
    &lt;Publishers>
        &lt;Publisher>
            &lt;DisplayName>Massachusetts Institute of Technology&lt;/DisplayName>
            &lt;OrgUnit />
        &lt;/Publisher>
    &lt;/Publishers>
    &lt;License>http://dspace.mit.edu/handle/1721.1/7582&lt;/License>
    &lt;Keyword>Electrical Engineering and Computer Science.&lt;/Keyword>
   	&lt;Abstract>Type-safe languages undertake to prevent the type confusion vulnerabilities that arise in type-unsafe languages such as C++. One such type-safe language is Rust, which provides powerful type safety guarantees [1]. However, these guarantees are valid only for a single compilation unit. That is, they may not hold when multiple separately compiled processes communicate. In this work, we explore how type confusion vulnerabilities can still arise when multiple separately compiled, internally type-safe processes share information through inter-process communication (IPC). We propose safeIPC, a tool for eliminating IPC-facilitated type confusion in Rust. safeIPC is a Rust compiler extension that detects communications over IPC and inserts runtime checks to ensure that type safety is maintained. Programs instrumented with safeIPC throw a runtime error if the type of any data received over IPC is not equivalent to the type expected. Our analysis shows that safeIPC is effective in preventing type confusion vulnerabilities not prevented by Rust alone.&lt;/Abstract>
	&lt;Access xmlns="http://purl.org/coar/access_right" 
    >
    &lt;/Access>
&lt;/Publication>
</dim:field>
</dim:dim>
</metadata></record></GetRecord></OAI-PMH>