Show simple item record

dc.contributor.authorChisnall, DTen
dc.contributor.authorDavis, Ben
dc.contributor.authorGudka, Ken
dc.contributor.authorBrazdil, Den
dc.contributor.authorJoannou, Aen
dc.contributor.authorWoodruff, Jen
dc.contributor.authorMarkettos, ATen
dc.contributor.authorMaste, JEen
dc.contributor.authorNorton, Ren
dc.contributor.authorSon, Sen
dc.contributor.authorRoe, Men
dc.contributor.authorMoore, SWen
dc.contributor.authorNeumann, PGen
dc.contributor.authorLaurie, Ben
dc.contributor.authorWatson, RNMen
dc.date.accessioned2017-05-19T10:41:43Z
dc.date.available2017-05-19T10:41:43Z
dc.identifier.urihttps://www.repository.cam.ac.uk/handle/1810/264315
dc.description.abstractJava provides security and robustness by building a high-level security model atop the foundation of memory protection. Unfortunately, any native code linked into a Java program – including the million lines used to implement the standard library – is able to bypass both the memory protection and the higher-level policies. We present a hardware-assisted implementation of the Java native code interface, which extends the guarantees required for Java’s security model to native code. Our design supports safe direct access to buffers owned by the JVM, including hardware-enforced read-only access where appropriate. We also present Java language syntax to declaratively describe isolated compartments for native code. We show that it is possible to preserve the memory safety and isolation requirements of the Java security model in C code, allowing native code to run in the same process as Java code with the same impact on security as running equivalent Java code. Our approach has a negligible impact on performance, compared with the existing unsafe native code interface. We demonstrate a prototype implementation running on the CHERI microprocessor synthesized in FPGA.
dc.description.sponsorshipThis work is part of the CTSRD and MRC2 projects sponsored by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contracts FA8750-10-C- 0237 and FA8750-11-C-0249. The views, opinions, and/or findings contained in this paper are those of the authors and should not be interpreted as representing the official views or policies, either expressed or implied, of the Department of Defense or the U.S. Government. We also acknowledge the EPSRC REMS Programme Grant [EP/K008528/1], the EPSRC Impact Acceleration Account [EP/K503757/1], Isaac Newton Trust, UK Higher Education Innovation Fund (HEIF), Thales E-Security, and Google, Inc.
dc.language.isoenen
dc.publisherACM
dc.titleCHERI JNI: Sinking the Java security model into the Cen
dc.typeConference Object
prism.endingPage583
prism.publicationNameProceedings of the Twenty-Second International Conference on Architectural Support for Programming Languages and Operating Systemsen
prism.startingPage569
dc.identifier.doi10.17863/CAM.9783
dcterms.dateAccepted2016-11-10en
rioxxterms.versionAMen
rioxxterms.licenseref.urihttp://www.rioxx.net/licenses/all-rights-reserveden
rioxxterms.licenseref.startdate2016-11-10en
dc.contributor.orcidMoore, SW [0000-0002-2806-495X]
rioxxterms.typeConference Paper/Proceeding/Abstracten


Files in this item

Thumbnail

This item appears in the following Collection(s)

Show simple item record