Results 1  10
of
796
ProofCarrying Code
, 1997
"... This paper describes proofcarrying code (PCC), a mechanism by which a host system can determine with certainty that it is safe to execute a program supplied (possibly in binary form) by an untrusted source. For this to be possible, the untrusted code producer must supply with the code a safety proo ..."
Abstract

Cited by 1240 (27 self)
 Add to MetaCart
This paper describes proofcarrying code (PCC), a mechanism by which a host system can determine with certainty that it is safe to execute a program supplied (possibly in binary form) by an untrusted source. For this to be possible, the untrusted code producer must supply with the code a safety proof that attests to the code's adherence to a previously defined safety policy. The host can then easily and quickly validate the proof without using cryptography and without consulting any external agents. In order to gain preliminary experience with PCC, we have performed several case studies. We show in this paper how proofcarrying code might be used to develop safe assemblylanguage extensions of ML programs. In the context of this case study, we present and prove the adequacy of concrete representations for the safety policy, the safety proofs, and the proof validation. Finally, we briefly discuss how we use proofcarrying code to develop network packet filters that are faster than similar filters developed using other techniques and are formally guaranteed to be safe with respect to a given operating system safety policy.
HigherOrder Abstract Syntax
"... We describe motivation, design, use, and implementation of higherorder abstract syntax as a central representation for programs, formulas, rules, and other syntactic objects in program manipulation and other formal systems where matching and substitution or syntax incorporates name binding informat ..."
Abstract

Cited by 357 (17 self)
 Add to MetaCart
We describe motivation, design, use, and implementation of higherorder abstract syntax as a central representation for programs, formulas, rules, and other syntactic objects in program manipulation and other formal systems where matching and substitution or syntax incorporates name binding information in a uniform and language generic way. Thus it acts as a powerful link integrating diverse tools in such formal environments. We have implemented higherorder abstract syntax, a supporting matching and unification algorithm, and some clients in Common
System Description: Twelf  A MetaLogical Framework for Deductive Systems
 Proceedings of the 16th International Conference on Automated Deduction (CADE16
, 1999
"... . Twelf is a metalogical framework for the specification, implementation, and metatheory of deductive systems from the theory of programming languages and logics. It relies on the LF type theory and the judgmentsastypes methodology for specification [HHP93], a constraint logic programming interp ..."
Abstract

Cited by 357 (54 self)
 Add to MetaCart
(Show Context)
. Twelf is a metalogical framework for the specification, implementation, and metatheory of deductive systems from the theory of programming languages and logics. It relies on the LF type theory and the judgmentsastypes methodology for specification [HHP93], a constraint logic programming interpreter for implementation [Pfe91], and the metalogic M2 for reasoning about object languages encoded in LF [SP98]. It is a significant extension and complete reimplementation of the Elf system [Pfe94]. Twelf is written in Standard ML and runs under SML of New Jersey and MLWorks on Unix and Window platforms. The current version (1.2) is distributed with a complete manual, example suites, a tutorial in the form of online lecture notes [Pfe], and an Emacs interface. Source and binary distributions are accessible via the Twelf home page http://www.cs.cmu.edu/~twelf. 1 The Twelf System The Twelf system is a tool for experimentation in the theory of programming languages and logics. It supports...
Logic Programming in a Fragment of Intuitionistic Linear Logic
, 1994
"... When logic programming is based on the proof theory of intuitionistic logic, it is natural to allow implications in goals and in the bodies of clauses. Attempting to prove a goal of the form D ⊃ G from the context (set of formulas) Γ leads to an attempt to prove the goal G in the extended context Γ ..."
Abstract

Cited by 340 (44 self)
 Add to MetaCart
(Show Context)
When logic programming is based on the proof theory of intuitionistic logic, it is natural to allow implications in goals and in the bodies of clauses. Attempting to prove a goal of the form D ⊃ G from the context (set of formulas) Γ leads to an attempt to prove the goal G in the extended context Γ ∪{D}. Thus during the bottomup search for a cutfree proof contexts, represented as the lefthand side of intuitionistic sequents, grow as stacks. While such an intuitionistic notion of context provides for elegant specifications of many computations, contexts can be made more expressive and flexible if they are based on linear logic. After presenting two equivalent formulations of a fragment of linear logic, we show that the fragment has a goaldirected interpretation, thereby partially justifying calling it a logic programming language. Logic programs based on the intuitionistic theory of hereditary Harrop formulas can be modularly embedded into this linear logic setting. Programming examples taken from theorem proving, natural language parsing, and data base programming are presented: each example requires a linear, rather than intuitionistic, notion of context to be modeled adequately. An interpreter for this logic programming language must address the problem of splitting contexts; that is, when attempting to prove a multiplicative conjunction (tensor), say G1 ⊗ G2, fromthe context ∆, the latter must be split into disjoint contexts ∆1 and ∆2 for which G1 follows from ∆1 and G2 follows from ∆2. Since there is an exponential number of such splits, it is important to delay the choice of a split as much as possible. A mechanism for the lazy splitting of contexts is presented based on viewing proof search as a process that takes a context, consumes part of it, and returns the rest (to be consumed elsewhere). In addition, we use collections of Kripke interpretations indexed by a commutative monoid to provide models for this logic programming language and show that logic programs admit a canonical model.
A logic programming language with lambdaabstraction, function variables, and simple unification
 Extensions of Logic Programming. Springer Lecture Notes in Artificial Intelligence
, 1990
"... A meta programming language must be able to represent and manipulate such syntactic structures as programs, formulas, types, and proofs. A common characteristic of all these structures is that they involve notions of abstractions, scope, bound and free variables, substitution instances, and equality ..."
Abstract

Cited by 314 (27 self)
 Add to MetaCart
A meta programming language must be able to represent and manipulate such syntactic structures as programs, formulas, types, and proofs. A common characteristic of all these structures is that they involve notions of abstractions, scope, bound and free variables, substitution instances, and equality up to alphabetic changes of bound variables.
Foundational ProofCarrying Code
, 2001
"... Proofcarrying code is a framework for the mechanical verification of safety properties of machine language programs, but the problem arises of quis custodiat ipsos custodeswho will verify the verifier itself? Foundational proofcarrying code is verification from the smallest possible set of axio ..."
Abstract

Cited by 252 (9 self)
 Add to MetaCart
Proofcarrying code is a framework for the mechanical verification of safety properties of machine language programs, but the problem arises of quis custodiat ipsos custodeswho will verify the verifier itself? Foundational proofcarrying code is verification from the smallest possible set of axioms, using the simplest possible verifier and the smallest possible runtime system. I will describe many of the mathematical and engineering problems to be solved in the construction of a foundational proofcarrying code system.
A Linear Logical Framework
, 1996
"... We present the linear type theory LLF as the forAppeared in the proceedings of the Eleventh Annual IEEE Symposium on Logic in Computer Science  LICS'96 (E. Clarke editor), pp. 264275, New Brunswick, NJ, July 2730 1996. mal basis for a conservative extension of the LF logical framework. ..."
Abstract

Cited by 234 (48 self)
 Add to MetaCart
We present the linear type theory LLF as the forAppeared in the proceedings of the Eleventh Annual IEEE Symposium on Logic in Computer Science  LICS'96 (E. Clarke editor), pp. 264275, New Brunswick, NJ, July 2730 1996. mal basis for a conservative extension of the LF logical framework. LLF combines the expressive power of dependent types with linear logic to permit the natural and concise representation of a whole new class of deductive systems, namely those dealing with state. As an example we encode a version of MiniML with references including its type system, its operational semantics, and a proof of type preservation. Another example is the encoding of a sequent calculus for classical linear logic and its cut elimination theorem. LLF can also be given an operational interpretation as a logic programming language under which the representations above can be used for type inference, evaluation and cutelimination. 1 Introduction A logical framework is a formal system desig...
ProofCarrying Authentication
 In Proceedings of the 6th ACM Conference on Computer and Communications Security
, 1999
"... We have designed and implemented a general and powerful distributed authentication framework based on higherorder logic. Authentication frameworks  including Taos, SPKI, SDSI, and X.509  have been explained using logic. We show that by starting with the logic, we can implement these framework ..."
Abstract

Cited by 202 (6 self)
 Add to MetaCart
(Show Context)
We have designed and implemented a general and powerful distributed authentication framework based on higherorder logic. Authentication frameworks  including Taos, SPKI, SDSI, and X.509  have been explained using logic. We show that by starting with the logic, we can implement these frameworks, all in the same concise and efficient system. Because our logic has no decision procedure  although proof checking is simple  users of the framework must submit proofs with their requests.
Logic Programming in the LF Logical Framework
, 1991
"... this paper we describe Elf, a metalanguage intended for environments dealing with deductive systems represented in LF. While this paper is intended to include a full description of the Elf core language, we only state, but do not prove here the most important theorems regarding the basic building b ..."
Abstract

Cited by 188 (53 self)
 Add to MetaCart
(Show Context)
this paper we describe Elf, a metalanguage intended for environments dealing with deductive systems represented in LF. While this paper is intended to include a full description of the Elf core language, we only state, but do not prove here the most important theorems regarding the basic building blocks of Elf. These proofs are left to a future paper. A preliminary account of Elf can be found in [26]. The range of applications of Elf includes theorem proving and proof transformation in various logics, definition and execution of structured operational and natural semantics for programming languages, type checking and type inference, etc. The basic idea behind Elf is to unify logic definition (in the style of LF) with logic programming (in the style of Prolog, see [22, 24]). It achieves this unification by giving types an operational interpretation, much the same way that Prolog gives certain formulas (Hornclauses) an operational interpretation. An alternative approach to logic programming in LF has been developed independently by Pym [28]. Here are some of the salient characteristics of our unified approach to logic definition and metaprogramming. First of all, the Elf search process automatically constructs terms that can represent objectlogic proofs, and thus a program need not construct them explicitly. This is in contrast to logic programming languages where executing a logic program corresponds to theorem proving in a metalogic, but a metaproof is never constructed or used and it is solely the programmer's responsibility to construct objectlogic proofs where they are needed. Secondly, the partial correctness of many metaprograms with respect to a given logic can be expressed and proved by Elf itself (see the example in Section 5). This creates the possibilit...