[cap-talk] SOSP History Day

[Mark Miller]

At <http://www.ssrc.ucsc.edu/sosp15/workshops/HistoryDay/>:


Welcome to the SOSP History Day Workshop Website

Fifty years ago the first SOSP launched operating systems as a domain of
fundamental principles at the core of computer science. With ten speakers
and a panel we will celebrate the history of ideas that emerged over that
half century and the rich inheritance of ideas, concerns, and practices we
have received. Most of our speakers were active during most of these years
and will give us first-hand accounts. We will review ideas that have been
solidly at the core of operating systems the whole time.

We will learn about ideas that were once big and then fell out of play. We
will discover that many researchers in earlier times took up the same
issues that concern us today and have left a treasure-trove of work that
can help us. We will examine why cyber security, something we have studied
since the beginning, has eluded us and has become such a source of
suffering for so many people; dare we hope we can make it better?

The workshop will be held on Sunday, October 4, 2015 in Monterey,
California from 8:30am to 5:00pm.


"SOSP" is "Symposium on Operating Systems Principles". This workshop
looks amazing. Check out the presenters -- many luminaries from our history
all gathered in one place -- Jack Dennis, Lampson, Liskov, and more. I am
honored to be included in the panel at the end of the workshop.

There should be plenty of time for audience questions and
discussion. Everything to be recorded and made public.


At <https://www.regonline.com/Register/Checkin.aspx?EventID=1238062> you
can register for all of SOSP including this workshop. For just History Day,
<http://www.ssrc.ucsc.edu/sosp15/registration.html> says "Workshop
registration is $250, and allows attendees to attend any workshop on
Sunday" though I do not see it on the form.

[Scott Moore]

This looks like it will be a great workshop. Do you know if there will be
recordings for those not able to attend?

Post by Mark Miller
At <http://www.ssrc.ucsc.edu/sosp15/workshops/HistoryDay/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ssrc.ucsc.edu_sosp15_workshops_HistoryDay_&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=a1ikzSHa30UpZ07pQ9OMUf1eJwqWrjlC_Wujn4yYgJ4&e=>
Welcome to the SOSP History Day Workshop Website
Fifty years ago the first SOSP launched operating systems as a domain of
fundamental principles at the core of computer science. With ten speakers
and a panel we will celebrate the history of ideas that emerged over that
half century and the rich inheritance of ideas, concerns, and practices we
have received. Most of our speakers were active during most of these years
and will give us first-hand accounts. We will review ideas that have been
solidly at the core of operating systems the whole time.
We will learn about ideas that were once big and then fell out of play. We
will discover that many researchers in earlier times took up the same
issues that concern us today and have left a treasure-trove of work that
can help us. We will examine why cyber security, something we have studied
since the beginning, has eluded us and has become such a source of
suffering for so many people; dare we hope we can make it better?
The workshop will be held on Sunday, October 4, 2015 in Monterey,
California from 8:30am to 5:00pm.
"SOSP" is "Symposium on Operating Systems Principles". This workshop
looks amazing. Check out the presenters -- many luminaries from our history
all gathered in one place -- Jack Dennis, Lampson, Liskov, and more. I am
honored to be included in the panel at the end of the workshop.
There should be plenty of time for audience questions and
discussion. Everything to be recorded and made public.
At <https://www.regonline.com/Register/Checkin.aspx?EventID=1238062
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.regonline.com_Register_Checkin.aspx-3FEventID-3D1238062&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=1EB8hKF52bOW8I6he0PFn2JyfGZQOt82UiAvNh-RxzY&e=>>
you can register for all of SOSP including this workshop. For just History
Day, <http://www.ssrc.ucsc.edu/sosp15/registration.html
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ssrc.ucsc.edu_sosp15_registration.html&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=8y-WXnaY-gMwiM8YIhmWOXK0aBjiodsk94lF-1NcreY&e=>>
says "Workshop registration is $250, and allows attendees to attend any
workshop on Sunday" though I do not see it on the form.
--
Cheers,
--MarkM
_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk

[Mark S. Miller]

Yes, the whole thing will be recorded.

Post by Scott Moore
This looks like it will be a great workshop. Do you know if there will be
recordings for those not able to attend?

Post by Mark Miller
At <http://www.ssrc.ucsc.edu/sosp15/workshops/HistoryDay/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ssrc.ucsc.edu_sosp15_workshops_HistoryDay_&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=a1ikzSHa30UpZ07pQ9OMUf1eJwqWrjlC_Wujn4yYgJ4&e=>
Welcome to the SOSP History Day Workshop Website
Fifty years ago the first SOSP launched operating systems as a domain of
fundamental principles at the core of computer science. With ten speakers
and a panel we will celebrate the history of ideas that emerged over that
half century and the rich inheritance of ideas, concerns, and practices we
have received. Most of our speakers were active during most of these years
and will give us first-hand accounts. We will review ideas that have been
solidly at the core of operating systems the whole time.
We will learn about ideas that were once big and then fell out of play.
We will discover that many researchers in earlier times took up the same
issues that concern us today and have left a treasure-trove of work that
can help us. We will examine why cyber security, something we have studied
since the beginning, has eluded us and has become such a source of
suffering for so many people; dare we hope we can make it better?
The workshop will be held on Sunday, October 4, 2015 in Monterey,
California from 8:30am to 5:00pm.
"SOSP" is "Symposium on Operating Systems Principles". This workshop
looks amazing. Check out the presenters -- many luminaries from our history
all gathered in one place -- Jack Dennis, Lampson, Liskov, and more. I am
honored to be included in the panel at the end of the workshop.
There should be plenty of time for audience questions and
discussion. Everything to be recorded and made public.
At <https://www.regonline.com/Register/Checkin.aspx?EventID=1238062
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.regonline.com_Register_Checkin.aspx-3FEventID-3D1238062&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=1EB8hKF52bOW8I6he0PFn2JyfGZQOt82UiAvNh-RxzY&e=>>
you can register for all of SOSP including this workshop. For just History
Day, <http://www.ssrc.ucsc.edu/sosp15/registration.html
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ssrc.ucsc.edu_sosp15_registration.html&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=8y-WXnaY-gMwiM8YIhmWOXK0aBjiodsk94lF-1NcreY&e=>>
says "Workshop registration is $250, and allows attendees to attend any
workshop on Sunday" though I do not see it on the form.
--
Cheers,
--MarkM
_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk

_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Tim Coote]

In the list of speakers, is that the Andrew Herbert involved with the CAP Computer? Or someone else?

Post by Mark S. Miller
Yes, the whole thing will be recorded.
This looks like it will be a great workshop. Do you know if there will be recordings for those not able to attend?
Welcome to the SOSP History Day Workshop Website
Fifty years ago the first SOSP launched operating systems as a domain of fundamental principles at the core of computer science. With ten speakers and a panel we will celebrate the history of ideas that emerged over that half century and the rich inheritance of ideas, concerns, and practices we have received. Most of our speakers were active during most of these years and will give us first-hand accounts. We will review ideas that have been solidly at the core of operating systems the whole time.
We will learn about ideas that were once big and then fell out of play. We will discover that many researchers in earlier times took up the same issues that concern us today and have left a treasure-trove of work that can help us. We will examine why cyber security, something we have studied since the beginning, has eluded us and has become such a source of suffering for so many people; dare we hope we can make it better?
The workshop will be held on Sunday, October 4, 2015 in Monterey, California from 8:30am to 5:00pm.
"SOSP" is "Symposium on Operating Systems Principles". This workshop looks amazing. Check out the presenters -- many luminaries from our history all gathered in one place -- Jack Dennis, Lampson, Liskov, and more. I am honored to be included in the panel at the end of the workshop.
There should be plenty of time for audience questions and discussion. Everything to be recorded and made public.
At <https://www.regonline.com/Register/Checkin.aspx?EventID=1238062 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.regonline.com_Register_Checkin.aspx-3FEventID-3D1238062&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=1EB8hKF52bOW8I6he0PFn2JyfGZQOt82UiAvNh-RxzY&e=>> you can register for all of SOSP including this workshop. For just History Day, <http://www.ssrc.ucsc.edu/sosp15/registration.html <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ssrc.ucsc.edu_sosp15_registration.html&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=8y-WXnaY-gMwiM8YIhmWOXK0aBjiodsk94lF-1NcreY&e=>> says "Workshop registration is $250, and allows attendees to attend any workshop on Sunday" though I do not see it on the form.
--
Cheers,
--MarkM
_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk <http://www.eros-os.org/mailman/listinfo/cap-talk>
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang <http://www.eros-os.org/mailman/listinfo/e-lang>
--
Cheers,
--MarkM
_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk

[Tristan Slominski]

Found on YouTube (haven't seen mention of it, sorry if I missed it
somewhere)

https://www.youtube.com/playlist?list=PLn0nrSd4xjjZn9QEooNBIcbF-SVmjv_97

Post by Mark S. Miller
Yes, the whole thing will be recorded.

Post by Scott Moore
This looks like it will be a great workshop. Do you know if there will be
recordings for those not able to attend?

Post by Mark Miller
At <http://www.ssrc.ucsc.edu/sosp15/workshops/HistoryDay/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ssrc.ucsc.edu_sosp15_workshops_HistoryDay_&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=a1ikzSHa30UpZ07pQ9OMUf1eJwqWrjlC_Wujn4yYgJ4&e=>
Welcome to the SOSP History Day Workshop Website
Fifty years ago the first SOSP launched operating systems as a domain of
fundamental principles at the core of computer science. With ten speakers
and a panel we will celebrate the history of ideas that emerged over that
half century and the rich inheritance of ideas, concerns, and practices we
have received. Most of our speakers were active during most of these years
and will give us first-hand accounts. We will review ideas that have been
solidly at the core of operating systems the whole time.
We will learn about ideas that were once big and then fell out of play.
We will discover that many researchers in earlier times took up the same
issues that concern us today and have left a treasure-trove of work that
can help us. We will examine why cyber security, something we have studied
since the beginning, has eluded us and has become such a source of
suffering for so many people; dare we hope we can make it better?
The workshop will be held on Sunday, October 4, 2015 in Monterey,
California from 8:30am to 5:00pm.
"SOSP" is "Symposium on Operating Systems Principles". This workshop
looks amazing. Check out the presenters -- many luminaries from our history
all gathered in one place -- Jack Dennis, Lampson, Liskov, and more. I am
honored to be included in the panel at the end of the workshop.
There should be plenty of time for audience questions and
discussion. Everything to be recorded and made public.
At <https://www.regonline.com/Register/Checkin.aspx?EventID=1238062
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.regonline.com_Register_Checkin.aspx-3FEventID-3D1238062&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=1EB8hKF52bOW8I6he0PFn2JyfGZQOt82UiAvNh-RxzY&e=>>
you can register for all of SOSP including this workshop. For just History
Day, <http://www.ssrc.ucsc.edu/sosp15/registration.html
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ssrc.ucsc.edu_sosp15_registration.html&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=8y-WXnaY-gMwiM8YIhmWOXK0aBjiodsk94lF-1NcreY&e=>>
says "Workshop registration is $250, and allows attendees to attend any
workshop on Sunday" though I do not see it on the form.
--
Cheers,
--MarkM
_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk

_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM

[Mark S. Miller]

[+andrewjamesherbert]

Post by Tim Coote
In the list of speakers, is that the Andrew Herbert involved with the CAP
Computer? Or someone else?
Yes indeed. But I'm cc'ing Andrew just to be sure.

Hi Andrew, if you reply to the list, your reply cannot be seen unless you
subscribe first at <http://www.eros-os.org/mailman/listinfo/cap-talk>.
Otherwise, please reply to me and I will forward, thanks.

Post by Tim Coote
Yes, the whole thing will be recorded.

Post by Scott Moore
This looks like it will be a great workshop. Do you know if there will be
recordings for those not able to attend?

Post by Mark Miller
At <http://www.ssrc.ucsc.edu/sosp15/workshops/HistoryDay/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ssrc.ucsc.edu_sosp15_workshops_HistoryDay_&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=a1ikzSHa30UpZ07pQ9OMUf1eJwqWrjlC_Wujn4yYgJ4&e=>
Welcome to the SOSP History Day Workshop Website
Fifty years ago the first SOSP launched operating systems as a domain of
fundamental principles at the core of computer science. With ten speakers
and a panel we will celebrate the history of ideas that emerged over that
half century and the rich inheritance of ideas, concerns, and practices we
have received. Most of our speakers were active during most of these years
and will give us first-hand accounts. We will review ideas that have been
solidly at the core of operating systems the whole time.
We will learn about ideas that were once big and then fell out of play.
We will discover that many researchers in earlier times took up the same
issues that concern us today and have left a treasure-trove of work that
can help us. We will examine why cyber security, something we have studied
since the beginning, has eluded us and has become such a source of
suffering for so many people; dare we hope we can make it better?
The workshop will be held on Sunday, October 4, 2015 in Monterey,
California from 8:30am to 5:00pm.
"SOSP" is "Symposium on Operating Systems Principles". This workshop
looks amazing. Check out the presenters -- many luminaries from our history
all gathered in one place -- Jack Dennis, Lampson, Liskov, and more. I am
honored to be included in the panel at the end of the workshop.
There should be plenty of time for audience questions and
discussion. Everything to be recorded and made public.
At <https://www.regonline.com/Register/Checkin.aspx?EventID=1238062
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.regonline.com_Register_Checkin.aspx-3FEventID-3D1238062&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=1EB8hKF52bOW8I6he0PFn2JyfGZQOt82UiAvNh-RxzY&e=>>
you can register for all of SOSP including this workshop. For just History
Day, <http://www.ssrc.ucsc.edu/sosp15/registration.html
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ssrc.ucsc.edu_sosp15_registration.html&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&s=8y-WXnaY-gMwiM8YIhmWOXK0aBjiodsk94lF-1NcreY&e=>>
says "Workshop registration is $250, and allows attendees to attend any
workshop on Sunday" though I do not see it on the form.

_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk

[k***@sipantic.net]

Mark
Given the increased interest in capabilities, omitting the first
industrial solution (PP250) would be a mistake. This is an important
workshop, much was learned at Plessey that should not be lost. It should
be included. What about Bob Fabry's work, he broke the ice for all?
Ken HH

Post by Mark S. Miller
[+andrewjamesherbert]

Post by Tim Coote
In the list of speakers, is that the Andrew Herbert involved with
the CAP Computer? Or someone else?

Yes indeed. But I'm cc'ing Andrew just to be sure.
Hi Andrew, if you reply to the list, your reply cannot be seen unless
you subscribe first at
<http://www.eros-os.org/mailman/listinfo/cap-talk [4]>. Otherwise,
please reply to me and I will forward, thanks.

Post by Tim Coote
Yes, the whole thing will be recorded.
On Wed, Aug 19, 2015 at 9:51 AM, Scott Moore
This looks like it will be a great workshop. Do you know if there
will be recordings for those not able to attend?
WELCOME TO THE SOSP HISTORY DAY WORKSHOP WEBSITE
Fifty years ago the first SOSP launched operating systems as a
domain of fundamental principles at the core of computer science.
With ten speakers and a panel we will celebrate the history of ideas
that emerged over that half century and the rich inheritance of
ideas, concerns, and practices we have received. Most of our
speakers were active during most of these years and will give us
first-hand accounts. We will review ideas that have been solidly at
the core of operating systems the whole time.
We will learn about ideas that were once big and then fell out of
play. We will discover that many researchers in earlier times took
up the same issues that concern us today and have left a
treasure-trove of work that can help us. We will examine why cyber
security, something we have studied since the beginning, has eluded
us and has become such a source of suffering for so many people;
dare we hope we can make it better?
The workshop will be held on Sunday, October 4, 2015 in Monterey,
California from 8:30am to 5:00pm.
"SOSP" is "Symposium on Operating Systems Principles". This
workshop looks amazing. Check out the presenters -- many luminaries
from our history all gathered in one place -- Jack Dennis, Lampson,
Liskov, and more. I am honored to be included in the panel at the
end of the workshop.
There should be plenty of time for audience questions and
discussion. Everything to be recorded and made public.
At <https://www.regonline.com/Register/Checkin.aspx?EventID=1238062
[2]> you can register for all of SOSP including this workshop. For
just History Day, <http://www.ssrc.ucsc.edu/sosp15/registration.html
[3]> says "Workshop registration is $250, and allows attendees to
attend any workshop on Sunday" though I do not see it on the form.

_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk [4]
--
Cheers,
--MarkM
------
[1]
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ssrc.ucsc.edu_sosp15_workshops_HistoryDay_&amp;d=BQMFaQ&amp;c=WO-RGvefibhHBZq3fL85hQ&amp;r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&amp;m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&amp;s=a1ikzSHa30UpZ07pQ9OMUf1eJwqWrjlC_Wujn4yYgJ4&amp;e=
[2]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.regonline.com_Register_Checkin.aspx-3FEventID-3D1238062&amp;d=BQMFaQ&amp;c=WO-RGvefibhHBZq3fL85hQ&amp;r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&amp;m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&amp;s=1EB8hKF52bOW8I6he0PFn2JyfGZQOt82UiAvNh-RxzY&amp;e=
[3]
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ssrc.ucsc.edu_sosp15_registration.html&amp;d=BQMFaQ&amp;c=WO-RGvefibhHBZq3fL85hQ&amp;r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&amp;m=rLugarY-hWyqbH02e-tyg4aJy6LKgISMgl4mC2HfNLY&amp;s=8y-WXnaY-gMwiM8YIhmWOXK0aBjiodsk94lF-1NcreY&amp;e=
[4] http://www.eros-os.org/mailman/listinfo/cap-talk
_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk

[Jed Donnelley]

All,

I'm interested in attending the SOSP History Day. I'm not deterred by
the registration fee or by the time commitment, but I am put off by the
possible drive down and back alone to and from Monterey.

Is anybody else driving down from the Bay Area who might like to share a
ride?

I'm sorry I haven't sent this email out sooner (job change, lots going
on), but I'm hoping somebody will see this message who is already
planning to attend - so we can share a ride.

I'm happy to drive with no cost sharing. I'm also willing to drive to
Monterey Saturday late and spend Saturday night there if that is
preferred by somebody sharing the ride (e.g. to avoid an early drive
Sunday morning). Either approach going works fine for me. I don't want
to spend Sunday night there as I have work Monday morning - though I
could be talked into taking Monday off work. My car is a well
maintained 1994 BMW 525 sedan that can seat four comfortably. Of course
I'm open to riding with somebody else driving also. I'm interested in
conversation and avoiding the long drive alone.

I realize that tomorrow (Thursday) is the final day for early
registration. I hope to decide if I'm going to attend by tomorrow.

--Jed

http://www.webstart.com/jed/

<the rest is historical>

Post by Mark Miller
Welcome to the SOSP History Day Workshop Website
Fifty years ago the first SOSP launched operating systems as a domain of
fundamental principles at the core of computer science. With ten speakers
and a panel we will celebrate the history of ideas that emerged over that
half century and the rich inheritance of ideas, concerns, and practices we
have received. Most of our speakers were active during most of these years
and will give us first-hand accounts. We will review ideas that have been
solidly at the core of operating systems the whole time.
We will learn about ideas that were once big and then fell out of play. We
will discover that many researchers in earlier times took up the same
issues that concern us today and have left a treasure-trove of work that
can help us. We will examine why cyber security, something we have studied
since the beginning, has eluded us and has become such a source of
suffering for so many people; dare we hope we can make it better?
The workshop will be held on Sunday, October 4, 2015 in Monterey,
California from 8:30am to 5:00pm.
"SOSP" is "Symposium on Operating Systems Principles". This workshop
looks amazing. Check out the presenters -- many luminaries from our history
all gathered in one place -- Jack Dennis, Lampson, Liskov, and more. I am
honored to be included in the panel at the end of the workshop.
There should be plenty of time for audience questions and
discussion. Everything to be recorded and made public.
At <https://www.regonline.com/Register/Checkin.aspx?EventID=1238062> you
can register for all of SOSP including this workshop. For just History Day,
<http://www.ssrc.ucsc.edu/sosp15/registration.html> says "Workshop
registration is $250, and allows attendees to attend any workshop on
Sunday" though I do not see it on the form.

[Mark S. Miller]

SOSP History Day <http://www.ssrc.ucsc.edu/sosp15/workshops/HistoryDay/>
was a superb event. It was all recorded and the recordings will be made
public. Capabilities were repeatedly mentioned in the presentations much
more often than I expected, and mostly positively.

I was on a panel at the end of the day whose topic was
"Is Security a Hopeless Quest?"
Each panelist opened with a 5 minute statement. I tried to boil down the
case for capabilities into the shortest clearest statement I could for an
informed audience. Here is what I said. Feel free to forward.



In the ‘70s, there were two main access control models:
the identity-centric model of access-control lists
and the authorization-centric model of capabilities.
For various reasons the world went down the identity-centric path,
resulting in the situation we are now in.
On the identity-centric path, why is security likely a hopeless quest?

When we build systems, we compose software written by different people.
These composed components may cooperate as we intend,
or they may destructively interfere.
We have gotten very good at avoiding accidental interference
by using abstraction mechanisms and designing good abstraction boundaries.
By composition, we have delivered astonishing functionality to the world.

Today, when we secure systems, we assign authority to identities.
When I run a program, it runs as me.
The square root function in my math library can delete my files.
Although it does not abuse this excess authority,
if it has a flaw enabling an attacker to subvert it,
then anything it may do, the attacker can do.
It is this excess authority that invites most of the attacks we see in the
world today.

By contrast, when we secure systems with capabilities,
we work with the grain of how we organize software for functionality.
At every level of composition,
from programming language to operating systems to distributed services,
we design abstraction boundaries so that a component’s interface
only requires arguments that are somehow relevant to its task.
If such argument passing were the only source of authority,
we would have already taken a huge step towards least authority.
If most programs only ran with the least authority they need to do their
jobs,
most abuses would be minor.

I do not imagine a world with fewer exploitable bugs.
I imagine a world in which much less is at risk to most bugs.

[Dan Connolly]

On Thu, Oct 8, 2015 at 9:22 AM, Mark S. Miller <***@google.com> wrote:
...

Post by Mark S. Miller
Today, when we secure systems, we assign authority to identities.
When I run a program, it runs as me.
The square root function in my math library can delete my files.
Although it does not abuse this excess authority,
if it has a flaw enabling an attacker to subvert it,
then anything it may do, the attacker can do.
It is this excess authority that invites most of the attacks we see in the
world today.

Borrowing from MLK, how's this for a bumper-sticker version of the
consequences of the conventional approach?

Insecurity anywhere is a threat to security everywhere.

[Mark S. Miller]

Too strong and simply untrue, to the point of inviting accusations of
"straw man".

Post by Dan Connolly
...

Post by Mark S. Miller
Today, when we secure systems, we assign authority to identities.
When I run a program, it runs as me.
The square root function in my math library can delete my files.
Although it does not abuse this excess authority,
if it has a flaw enabling an attacker to subvert it,
then anything it may do, the attacker can do.
It is this excess authority that invites most of the attacks we see in

the

Post by Mark S. Miller
world today.

Borrowing from MLK, how's this for a bumper-sticker version of the
consequences of the conventional approach?
Insecurity anywhere is a threat to security everywhere.
--
Dan Connolly
http://www.madmode.com/
_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk

[Mark S. Miller]

Perhaps you could help me understand a little better?
I'm having trouble seeing how "any vulnerability in any software
someone like myself may invoke, for example the sqrt function, is a
threat to delete all my files or contribute to a DDOS or spear
phishing attack" is any more or less true than "insecurity anywhere is
a threat to security everywhere."
I'm not cc'ing cap-talk, but feel free to do so on your reply.

If the sqrt function you're running is vulnerable, you are at risk. But if
only the sqrt function I am running is vulnerable, that does not put you at
risk.

Note that the vulnerability-thru-excess-authority I am focused on here is
quite distinct from DDOS, which is a resource exhaustion attack on
availability; or spear phishing, which is a social engineering attack
involving further human actions.

Post by Mark S. Miller
Too strong and simply untrue, to the point of inviting accusations of

"straw

Post by Mark S. Miller
man".

Post by Dan Connolly
...

Post by Mark S. Miller
Today, when we secure systems, we assign authority to identities.
When I run a program, it runs as me.
The square root function in my math library can delete my files.
Although it does not abuse this excess authority,
if it has a flaw enabling an attacker to subvert it,
then anything it may do, the attacker can do.
It is this excess authority that invites most of the attacks we see in the
world today.

Borrowing from MLK, how's this for a bumper-sticker version of the
consequences of the conventional approach?
Insecurity anywhere is a threat to security everywhere.

--
Dan Connolly
http://www.madmode.com/

[Dan Connolly]

Post by Mark S. Miller

Perhaps you could help me understand a little better?
I'm having trouble seeing how "any vulnerability in any software
someone like myself may invoke, for example the sqrt function, is a
threat to delete all my files or contribute to a DDOS or spear
phishing attack" is any more or less true than "insecurity anywhere is
a threat to security everywhere."

If the sqrt function you're running is vulnerable, you are at risk. But if
only the sqrt function I am running is vulnerable, that does not put you at
risk.

If there's an arbitrary code execution vulnerability in the sqrt
function you are running, then the attacker can forge network messages
from you or your machine. If that sqrt function is on enough machines,
the attacker can can reach out and put me at risk.

Post by Mark S. Miller
Note that the vulnerability-thru-excess-authority I am focused on here is
quite distinct from DDOS, which is a resource exhaustion attack on
availability; or spear phishing, which is a social engineering attack
involving further human actions.

I don't see the distinction in practice. DDOS attacks and spear
phishing are, in practice, deployed by exploiting
vulnerability-thru-excess-authority as a consequence of conventional
security choices.

It would seem to me that capability approaches don't have the same
explosive* consequences to faults and hence the economics of
propagation would be entirely different.

The other alternative I see is identity-based systems that are
sufficiently locked down to have similar economics. I don't think
botnets of iPads are very likely.

* in the sense of https://en.wikipedia.org/wiki/Principle_of_explosion

[Mark S. Miller]

Post by Dan Connolly

Post by Mark S. Miller

Perhaps you could help me understand a little better?
I'm having trouble seeing how "any vulnerability in any software
someone like myself may invoke, for example the sqrt function, is a
threat to delete all my files or contribute to a DDOS or spear
phishing attack" is any more or less true than "insecurity anywhere is
a threat to security everywhere."

If the sqrt function you're running is vulnerable, you are at risk. But

if

Post by Mark S. Miller
only the sqrt function I am running is vulnerable, that does not put you

at

Post by Mark S. Miller
risk.

If there's an arbitrary code execution vulnerability in the sqrt
function you are running, then the attacker can forge network messages
from you or your machine. If that sqrt function is on enough machines,
the attacker can can reach out and put me at risk.

Only if you are already vulnerable. The vulnerability in my sqrt function
does not itself make you vulnerable, even if it does exploit a
vulnerability you already have.

Post by Dan Connolly

Post by Mark S. Miller
Note that the vulnerability-thru-excess-authority I am focused on here is
quite distinct from DDOS, which is a resource exhaustion attack on
availability; or spear phishing, which is a social engineering attack
involving further human actions.

I don't see the distinction in practice. DDOS attacks and spear
phishing are, in practice, deployed by exploiting
vulnerability-thru-excess-authority as a consequence of conventional
security choices.

DDOS is an attack only on availability. Deleting files, which is indeed my
example, can be viewed at an attack on either availability or integrity,
depending on how we split hairs. However, my sqrt function can also modify
and thereby corrupt my files, which is clearly an attack on integrity.

Spear phishing depends on triggering new human actions. Humans must
participate for the attack to proceed. The vulnerability is my sqrt
function for not by itself make you vulnerable to spear phishing, even if
it does exploit a vulnerability you already have.

Post by Dan Connolly
It would seem to me that capability approaches don't have the same
explosive* consequences to faults and hence the economics of
propagation would be entirely different.
The other alternative I see is identity-based systems that are
sufficiently locked down to have similar economics. I don't think
botnets of iPads are very likely.
* in the sense of https://en.wikipedia.org/wiki/Principle_of_explosion

I had not heard that term before. I like it.

In any case, I agree that caps substantially limit these explosions, and
that is much of the point I was trying to make. But the acl approach is
still *much* less explosive than classic logic, where one flaw destroys the
universe.

Post by Dan Connolly
--
Dan Connolly
http://www.madmode.com/

[Raoul Duke]

Post by Mark S. Miller

Post by Dan Connolly

Post by Mark S. Miller

Perhaps you could help me understand a little better?
I'm having trouble seeing how "any vulnerability in any software
someone like myself may invoke, for example the sqrt function, is a
threat to delete all my files or contribute to a DDOS or spear
phishing attack" is any more or less true than "insecurity anywhere is
a threat to security everywhere."

If the sqrt function you're running is vulnerable, you are at risk. But if
only the sqrt function I am running is vulnerable, that does not put you at
risk.

If there's an arbitrary code execution vulnerability in the sqrt
function you are running, then the attacker can forge network messages
from you or your machine. If that sqrt function is on enough machines,
the attacker can can reach out and put me at risk.

Only if you are already vulnerable. The vulnerability in my sqrt function
does not itself make you vulnerable, even if it does exploit a vulnerability
you already have.

Post by Dan Connolly

Post by Mark S. Miller
Note that the vulnerability-thru-excess-authority I am focused on here is
quite distinct from DDOS, which is a resource exhaustion attack on
availability; or spear phishing, which is a social engineering attack
involving further human actions.

I don't see the distinction in practice. DDOS attacks and spear
phishing are, in practice, deployed by exploiting
vulnerability-thru-excess-authority as a consequence of conventional
security choices.

DDOS is an attack only on availability. Deleting files, which is indeed my
example, can be viewed at an attack on either availability or integrity,
depending on how we split hairs. However, my sqrt function can also modify
and thereby corrupt my files, which is clearly an attack on integrity.
Spear phishing depends on triggering new human actions. Humans must
participate for the attack to proceed. The vulnerability is my sqrt function
for not by itself make you vulnerable to spear phishing, even if it does
exploit a vulnerability you already have.

Post by Dan Connolly
It would seem to me that capability approaches don't have the same
explosive* consequences to faults and hence the economics of
propagation would be entirely different.
The other alternative I see is identity-based systems that are
sufficiently locked down to have similar economics. I don't think
botnets of iPads are very likely.
* in the sense of https://en.wikipedia.org/wiki/Principle_of_explosion

I had not heard that term before. I like it.
In any case, I agree that caps substantially limit these explosions, and
that is much of the point I was trying to make. But the acl approach is
still *much* less explosive than classic logic, where one flaw destroys the
universe.

Post by Dan Connolly
--
Dan Connolly
http://www.madmode.com/

--
Cheers,
--MarkM
_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk

[Raoul Duke]

Apologies for the immediately preceding fat fingered message send :-(

Post by Mark S. Miller
Only if you are already vulnerable. The vulnerability in my sqrt function
does not itself make you vulnerable, even if it does exploit a vulnerability
you already have.

That sounds more safe than I think things are in the real world? I
expect if there's a vulnerability, a lot of people will have it; we
don't all run /that/ many different OSs, I'd guess.

[Tim Coote]

You may be surprised at the configuration variation in the wild. A specific vulnerability may be the result of combinations of components.

As an example from the enterprise space. A measurement of the deployments of jvms on servers in a major bank showed a mean of 6 versions per server for those computers that had java installed (which was most of them, iirc). Since the variation is not normally measured, it’s not likely to be well controlled.

Post by Raoul Duke
Apologies for the immediately preceding fat fingered message send :-(

Post by Mark S. Miller
Only if you are already vulnerable. The vulnerability in my sqrt function
does not itself make you vulnerable, even if it does exploit a vulnerability
you already have.

That sounds more safe than I think things are in the real world? I
expect if there's a vulnerability, a lot of people will have it; we
don't all run /that/ many different OSs, I'd guess.
_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk

[Raoul Duke]

Post by Tim Coote
You may be surprised at the configuration variation in the wild. A specific vulnerability may be the result of combinations of components.
As an example from the enterprise space. A measurement of the deployments of jvms on servers in a major bank showed a mean of 6 versions per server for those computers that had java installed (which was most of them, iirc). Since the variation is not normally measured, it’s not likely to be well controlled.

Thanks, all interesting and salient points.

[David Nicol]

Square root having authority to delete files, were the library
compromised, is an excellent example.

It seems odd at first that Javascript keeps all its math methods in
the core math object
rather than allowing them to have global primitive status, but one of
the benefits of doing
it that way is that a capability-oriented (message passing,
distributed) Javascript could grant the math object only the authority
required to read arguments, calculate, and return results.

Post by Mark S. Miller
The square root function in my math library can delete my files.
Although it does not abuse this excess authority,
if it has a flaw enabling an attacker to subvert it,
then anything it may do, the attacker can do.
It is this excess authority that invites most of the attacks we see
in the world today.

[rmeijer]

Post by David Nicol
Square root having authority to delete files, were the library
compromised, is an excellent example.

It is a good example when you wish to narrow it down as far
as possible, but it is a little far-fetched when you wish to
explain capabilities to neophytes. In the case of sqrt, either
you have installed a malicious system library, or someone
untrustworthy is launching your authority-carrying (setuid...)
binary and linking it with his malicious library.
A more reasonable example would be something that is not
always installed with the system and often updated, such as a
third-party statistics package, or even better a video player
or a PDF reader. Those don't even have to be malicious, just
too complex and vulnerable to malicious input, and there are
multiple real-world examples of such problems.

Trojans and Trojan components are about 'how do I run untrusted code?'
while
bugs in the square root functions are about 'how do I reduce trusted
code?'.

Capabilities may answer both questions in the same way, but the
difference
between the questions is important. There is a widely spread
misconception that
avoiding bugs and patching speed are what matters. I think the square
root example
is an excellent example in that sense. In a large code base its likely
that a square root function will be skipped or missed when doing a
limited resources security oriented
code review. How does it handle negative numbers? Oops, that code wasn't
tested properly and instead of invoking ComplexNumber::Init() on an
instance of RegularNumber, it ends up calling
the global Init() function without parameters, resulting in the program
config file being overwritten with an empty default config. No arbitrary
code execution, no untrusted 3th party code, just a piece of rarely used
code-path that had a hidden accidental dependency.

Its basically all about reducing the trusted code-base. There should be
no reason why we should need to trust square root to not mess with our
config file unless we hand it a reference to our config file or
something that allows it to obtain such a reference explicitly. We
should only need to trust square root to give us a valid response
derived from the const reference to the operand we supplied it with. Any
possibility for non-explicitly injected dependencies of a piece of code
promotes that piece of code to our trusted code-base, turning any
security review into a black hole for limited time resources.

[Daira Hopwood]

Trying again after changing my subscription address -- sorry if this is a duplicate.

Post by Mark S. Miller
I do not imagine a world with fewer exploitable bugs.
I imagine a world in which much less is at risk to most bugs.

It isn't difficult to imagine a world with both fewer exploitable bugs, and
with less at risk to most remaining bugs. The former requires better
programming languages, tools, and analysis techniques -- which are
complementary to reducing the latter risk.

I'm certainly focussing on both problems in my language research, to the extent
that I do not view them as separate problems.

At the risk of oversimplifying a little:

"total exploitability" = sum over bugs { exploitability of each bug }

The reasons why this is an oversimplification are:

* the "exploitability" of a bug is not entirely well-defined, and is perhaps not
best modelled with a linear metric;
* the exploitability of a bug is not independent of the kind of bug, and any
particular technique for reducing bugs will not be effective on all kinds of
bug equally;
* an attack may need to exploit multiple bugs, so the "total exploitability"
is not exactly what we care about.

Nevertheless, it is at least a plausible hypothesis that, to a first order
approximation, we have a *multiplicative* contribution to overall security from
reducing the incidence of bugs and from reducing their (typical) exploitability.

Of course we do actually care about our programs being correct, not just secure.
Also, incorrectness can lead to insecurity via more subtle routes than the trivial
buffer overflows and injections that we've been used to patching so far.

For instance, here is a real bug in some versions of gcc that I consider to be
quite instructive:

<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307>

The following code sample exhibits a bug in a gcc -O2 optimization pass.
Namely, having defined two() and six() with the obvious return values, the
value of two() * 2 + six() * 5 gets an assembly of 1 shl 5 (i.e. 32, instead
of the correct 34).

Would you trust an implementation of a cryptographic algorithm compiled with
that gcc?

Or how about this bug, which could affect the correctness of a message passing
implementation built on top of an atomic exchange primitive:

<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60272>

(This is a problem even if applications don't use atomic exchange directly, as
they probably shouldn't. Furthermore, it's a race condition that might not show
up in testing.)

To me it's quite clear that we will not be able to trust computer systems unless
and until they are built on formally verified foundations -- and that this is
complementary to building them as capability systems (indeed, it may *only be
feasible* for capability systems). I am not suggesting that we throw up our hands
at the fact that such foundations are not available yet and consider everything
equally insecure; however, it is an issue we should be working on *now*.

[Daira Hopwood]

Trying again after changing my subscription address -- sorry if this is a duplicate.

SOSP History Day <http://www.ssrc.ucsc.edu/sosp15/workshops/HistoryDay/> was a superb
event. It was all recorded and the recordings will be made public.

Have they been made public yet?

[Mark Miller]

Not yet.

Post by Daira Hopwood
Trying again after changing my subscription address -- sorry if this is a duplicate.

Post by Mark S. Miller
SOSP History Day <http://www.ssrc.ucsc.edu/sosp15/workshops/HistoryDay/>

was a superb

Post by Mark S. Miller
event. It was all recorded and the recordings will be made public.

Have they been made public yet?
--
Daira Hopwood ⚧Ⓐ
_______________________________________________
cap-talk mailing list
http://www.eros-os.org/mailman/listinfo/cap-talk