Recording of today's talk
8 views
Skip to first unread message
Mike Stay
Jan 13, 2023, 3:26:45 PM1/13/23
to <friam@googlegroups.com>
Mark S. Miller
Jan 13, 2023, 11:03:40 PM1/13/23
to fr...@googlegroups.com
Got it. Uploading to YouTube now. Thanks!
Will post YouTube URL once available.
--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAKQgqTaagV7nxo%2BOQTB4EPMBeRmMj54zT%2BvSpwOA%3DUPeb5bg9A%40mail.gmail.com.
Cheers,
--MarkM
--MarkM
Mike Stay
Jan 16, 2023, 3:54:18 PM1/16/23
to fr...@googlegroups.com
Done yet?
> To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAK5yZYiEWN7XsgyMikE6HHR5O2pHHfYVneyo8uas_-yynU1gww%40mail.gmail.com.
Mark S. Miller
Jan 17, 2023, 4:52:10 PM1/17/23
to fr...@googlegroups.com
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAKQgqTYCSBaZzuFHNeUk7h7C7pvA2eaxqRUOAH9pe6FCGkX8PQ%40mail.gmail.com.
Cheers,
--MarkM
--MarkM
Matt Rice
Jan 17, 2023, 11:58:39 PM1/17/23
to fr...@googlegroups.com
Thanks for recording as I wasn't able to join live.
IIUC what is constraining this to a unidirectional channel is Carol's
call order into Bob and Alice,
and if Carol made an additional call to the first collaborating
attacker after the second bidirectional communication
could be established (is that correct?). Such as by calling Bob and
Alice in a loop, it might be interesting to look for
cases where the naive code not defending against this (real)
additional channel could be susceptible to such a further
(potential) pair of channels?
> To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAK5yZYhG7DZ9vVqYeGhQHtB_ZOFSv7GBKZ6FC4qMwL37%3D5Bx8w%40mail.gmail.com.
IIUC what is constraining this to a unidirectional channel is Carol's
call order into Bob and Alice,
and if Carol made an additional call to the first collaborating
attacker after the second bidirectional communication
could be established (is that correct?). Such as by calling Bob and
Alice in a loop, it might be interesting to look for
cases where the naive code not defending against this (real)
additional channel could be susceptible to such a further
(potential) pair of channels?
Jed Donnelley
Mar 24, 2023, 7:02:53 AM3/24/23
to fr...@googlegroups.com
Friam,
I thought I'd try probing on the Friam list to see what others might be
thinking about this paper:
https://www.usenix.org/system/files/atc19-hille.pdf
and some of the recent capability work that it refers to. When I read
things like:
_____________
Capabilities are unforgeable tokens of authority granting
rights to resources in the system. They can be selectively
delegated between constrained programs for implementing
the principle of least authority [48]. Due to their ability of
fine-grained resource management and protection, capabilities
appear to be a particularly good fit for future hardware
architectures, which envision byte granular memory access to
large memories (NVRAM) from a large numbers of cores (e.g.
The Machine [31], Enzian [18]). Thereby, capability-based
systems have received renewed attention recently to provide
an efficient and secure mechanism for resource management
in modern hardware architectures [5, 24, 30, 36, 44, 64, 67].
______________
and:
______________
2.1 Capability Systems
The term capability was first used by Dennis and van Horn [20]
to describe a pointer to a resource, which provides the owner
access to the resource. There are three basic types of capabilities:
(1) partitioned capabilities, which have been employed in
multiple OSes such as KeyKOS [27], EROS [56] and various
L4 M3 CHERI Scope Coherence Dom. Machine Address space
Enforcement MMU / Kernel DTU / Kernel CHERI co-proc.
Limitation Coherence Dom. Core count no revoke
Table 1: Classification of capability types.
L4 microkernels [30,36,40,62], (2) instruction set architecture
(ISA) capabilities, as implemented by the CAP computer [49]
and recently revived by CHERI [67] and (3) sparse capabilities
which are deployed in the password-capability system of the
Monash University [2] and in Amoeba [63].
________________
I feel myself suddenly transported back to the late 1960s and early 1970s.
I also feel myself internally screaming about the need to take care
to insure that any capability 'extension' mechanism (the ability of
an active computational element to create new and/or emulate existing
object/capabilities) can fully emulate all of the underlying kernel and/or
hardware supported object/capabilities. To do so then it seems to me
fundamental to insure that any mechanism for distributing capabilities
can be implemented across any data communication network (e.g. the
Internet) by a 'membrane' mechanism like the DCCS:
http://www.webstart.com/jed/papers/DCCS/
When in the above paper I see them write: "capability-based
systems have received renewed attention recently to provide
an efficient and secure mechanism for resource management
in modern hardware architectures", I wonder how they address
the objections of those who argue that capability-based systems
can't be "secure" because they can't provide an underlying audit
facility that can answer the fundamental question, "who did what"
(and when)? I.e. the issue that the Horton Protocol was designed
to address:
http://www.webstart.com/jed/papers/horton.pdf
I don't know how deeply I'm going to have to read through many
of the papers referred to in this SemperOS paper. I wonder if anybody
might have at least started down that path and might be able to
give me some suggestions on where to focus my attention to efficiently
dig out the essence of the design and function issues?
--Jed http://www.webstart.com/jed/
I thought I'd try probing on the Friam list to see what others might be
thinking about this paper:
https://www.usenix.org/system/files/atc19-hille.pdf
and some of the recent capability work that it refers to. When I read
things like:
_____________
Capabilities are unforgeable tokens of authority granting
rights to resources in the system. They can be selectively
delegated between constrained programs for implementing
the principle of least authority [48]. Due to their ability of
fine-grained resource management and protection, capabilities
appear to be a particularly good fit for future hardware
architectures, which envision byte granular memory access to
large memories (NVRAM) from a large numbers of cores (e.g.
The Machine [31], Enzian [18]). Thereby, capability-based
systems have received renewed attention recently to provide
an efficient and secure mechanism for resource management
in modern hardware architectures [5, 24, 30, 36, 44, 64, 67].
______________
and:
______________
2.1 Capability Systems
The term capability was first used by Dennis and van Horn [20]
to describe a pointer to a resource, which provides the owner
access to the resource. There are three basic types of capabilities:
(1) partitioned capabilities, which have been employed in
multiple OSes such as KeyKOS [27], EROS [56] and various
L4 M3 CHERI Scope Coherence Dom. Machine Address space
Enforcement MMU / Kernel DTU / Kernel CHERI co-proc.
Limitation Coherence Dom. Core count no revoke
Table 1: Classification of capability types.
L4 microkernels [30,36,40,62], (2) instruction set architecture
(ISA) capabilities, as implemented by the CAP computer [49]
and recently revived by CHERI [67] and (3) sparse capabilities
which are deployed in the password-capability system of the
Monash University [2] and in Amoeba [63].
________________
I feel myself suddenly transported back to the late 1960s and early 1970s.
I also feel myself internally screaming about the need to take care
to insure that any capability 'extension' mechanism (the ability of
an active computational element to create new and/or emulate existing
object/capabilities) can fully emulate all of the underlying kernel and/or
hardware supported object/capabilities. To do so then it seems to me
fundamental to insure that any mechanism for distributing capabilities
can be implemented across any data communication network (e.g. the
Internet) by a 'membrane' mechanism like the DCCS:
http://www.webstart.com/jed/papers/DCCS/
When in the above paper I see them write: "capability-based
systems have received renewed attention recently to provide
an efficient and secure mechanism for resource management
in modern hardware architectures", I wonder how they address
the objections of those who argue that capability-based systems
can't be "secure" because they can't provide an underlying audit
facility that can answer the fundamental question, "who did what"
(and when)? I.e. the issue that the Horton Protocol was designed
to address:
http://www.webstart.com/jed/papers/horton.pdf
I don't know how deeply I'm going to have to read through many
of the papers referred to in this SemperOS paper. I wonder if anybody
might have at least started down that path and might be able to
give me some suggestions on where to focus my attention to efficiently
dig out the essence of the design and function issues?
--Jed http://www.webstart.com/jed/
Reply all
Reply to author
Forward
0 new messages