Spectre?

[John Lee]

What can be said about how much Spectre affects object capability security relative to ACL security? I'm mostly thinking of capabilities at the language level, but interested to hear about other systems too. Has there been much/any research trying to evaluate the effect on capability systems?

In general, presumably the ability to read memory makes it easier to exploit other vulnerabilities, but fundamentally as far as capability languages go -- because language-level caps are not bit patterns -- the direct effect is similar for both caps and ACLs? If so, does that mean that the overall outcome is not to change the relative merits of the two approaches, or are there more subtle effects?

[Alan Karp]

Spectre/Meltdown are good for stealing secrets.  Ocap systems are safe from these attacks to the extent that they do not rely on secrets.  Those ocap systems that do rely on secrets, such as waterken, are vulnerable.   Other ocap systems are vulnerable at the margins where secrets are used, e.g., sturdy refs.  The same analysis applies to ACL systems.  The access control mechanism itself is not vulnerable, but the authentication step is.  All bets are off if the attack is combined with Rowhammer. 

--------------
Alan Karp

On Sun, May 2, 2021 at 3:30 AM John Lee <j...@pobox.com> wrote:

What can be said about how much Spectre affects object capability security relative to ACL security?  I'm mostly thinking of capabilities at the language level, but interested to hear about other systems too.  Has there been much/any research trying to evaluate the effect on capability systems?

In general, presumably the ability to read memory makes it easier to exploit other vulnerabilities, but fundamentally as far as capability languages go -- because language-level caps are not bit patterns -- the direct effect is similar for both caps and ACLs?  If so, does that mean that the overall outcome is not to change the relative merits of the two approaches, or are there more subtle effects?

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/77c81118-9982-46ef-88d9-274563bf123b%40www.fastmail.com.

[Ian Denhardt]

Another important point: in order to exploit timing side-channels, you
need a clock. OCap languages can deny this, simply by not providing one.

-Ian

Quoting Alan Karp (2021-05-02 13:25:24)

> Spectre/Meltdown are good for stealing secrets.� Ocap systems are safe
> from these attacks to the extent that they do not rely on secrets.�
> Those ocap systems that do rely on secrets, such as waterken, are
> vulnerable.� � Other ocap systems are vulnerable at the margins where
> secrets are used, e.g., sturdy refs.� The same analysis applies to ACL
> systems.� The access control mechanism itself is not vulnerable, but
> the authentication step is.� All bets are off if the attack is
> combined with Rowhammer.�
> --------------
> Alan Karp
>

> On Sun, May 2, 2021 at 3:30 AM John Lee <[1]j...@pobox.com> wrote:
>
> What can be said about how much Spectre affects object capability
> security relative to ACL security?� I'm mostly thinking of
> capabilities at the language level, but interested to hear about
> other systems too.� Has there been much/any research trying to
> evaluate the effect on capability systems?
> In general, presumably the ability to read memory makes it easier to
> exploit other vulnerabilities, but fundamentally as far as
> capability languages go -- because language-level caps are not bit
> patterns -- the direct effect is similar for both caps and ACLs?�
> If so, does that mean that the overall outcome is not to change the
> relative merits of the two approaches, or are there more subtle
> effects?
> --
> You received this message because you are subscribed to the Google
> Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to [2]cap-talk+u...@googlegroups.com.

> To view this discussion on the web visit

> [3]https://groups.google.com/d/msgid/cap-talk/77c81118-9982-46ef-88d
> 9-274563bf123b%40www.fastmail.com.

>
> --
> You received this message because you are subscribed to the Google
> Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to [4]cap-talk+u...@googlegroups.com.

> To view this discussion on the web visit

> [5]https://groups.google.com/d/msgid/cap-talk/CANpA1Z2Tq9wx6r3Stc18G6Rb
> Q_iL0oVqmHjQ2VbYVAoQt2ig%3DA%40mail.gmail.com.
>
> Verweise
>
> 1. mailto:j...@pobox.com
> 2. mailto:cap-talk%2Bunsu...@googlegroups.com
> 3. https://groups.google.com/d/msgid/cap-talk/77c81118-9982-46ef-88d9-274563bf123b%40www.fastmail.com
> 4. mailto:cap-talk+u...@googlegroups.com
> 5. https://groups.google.com/d/msgid/cap-talk/CANpA1Z2Tq9wx6r3Stc18G6RbQ_iL0oVqmHjQ2VbYVAoQt2ig%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer

[Mark S. Miller]

A lot: https://agoric.com/blog/all/taxonomy-of-security-issues/

https://ses-demo.netlify.app/demos/challenge/

Enjoy. Comments appreciated!

On Sun, May 2, 2021 at 3:30 AM John Lee <j...@pobox.com> wrote:

What can be said about how much Spectre affects object capability security relative to ACL security?  I'm mostly thinking of capabilities at the language level, but interested to hear about other systems too.  Has there been much/any research trying to evaluate the effect on capability systems?

In general, presumably the ability to read memory makes it easier to exploit other vulnerabilities, but fundamentally as far as capability languages go -- because language-level caps are not bit patterns -- the direct effect is similar for both caps and ACLs?  If so, does that mean that the overall outcome is not to change the relative merits of the two approaches, or are there more subtle effects?

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/77c81118-9982-46ef-88d9-274563bf123b%40www.fastmail.com.

[Mark S. Miller]

On Sun, May 2, 2021 at 11:19 AM Ian Denhardt <i...@zenhack.net> wrote:

Another important point: in order to exploit timing side-channels, you
need a clock. OCap languages can deny this, simply by not providing one.

Exactly.

 

To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/161997951639.109556.13367004627856545994%40localhost.localdomain.

[Neil Madden]

Is that simple? https://xsleaks.com/docs/attacks/timing-attacks/clocks/ suggests otherwise (at least in a browser). Also, I wouldn’t want to bet that timings are the only side-channels to worry about. That said, ocaps can also help in confining the ability of attacker code to exfiltrate any data it manages to access via Spectre.

The Chrome team have moved to assuming that OS processes are the only reasonable security boundary [1] and their primary approach to Spectre is "Your data must not unexpectedly enter an attacker’s process.” [2]. They are adding more process-level isolation and yet more headers to say which other sites can embed your resources.

I’ve been reading this material recently, and it’s easy to feel deeply pessimistic about this, so it’s good to hear something positive.

PS - On the topic of language-level security mechanisms, I notice that there’s now a proposal to remove Java’s notorious Security Manager sandbox [3].

[1]: https://chromium.googlesource.com/chromium/src/+/master/docs/security/side-channel-threat-model.md 

[2]: https://w3c.github.io/webappsec-post-spectre-webdev/ 

[3]: https://openjdk.java.net/jeps/411 

— Neil

To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/161997951639.109556.13367004627856545994%40localhost.localdomain.

ForgeRock values your Privacy

[Mark S. Miller]

On Sun, May 2, 2021 at 12:33 PM Neil Madden <neil....@forgerock.com> wrote:

Is that simple? https://xsleaks.com/docs/attacks/timing-attacks/clocks/ suggests otherwise (at least in a browser). Also, I wouldn’t want to bet that timings are the only side-channels to worry about. That said, ocaps can also help in confining the ability of attacker code to exfiltrate any data it manages to access via Spectre.

The Chrome team have moved to assuming that OS processes are the only reasonable security boundary [1] and their primary approach to Spectre is "Your data must not unexpectedly enter an attacker’s process.” [2]. They are adding more process-level isolation and yet more headers to say which other sites can embed your resources.

I’ve been reading this material recently, and it’s easy to feel deeply pessimistic about this, so it’s good to hear something positive.

Yeah. I wrote that essay largely to clear up confusion caused by Google's Chrome team. They are aware of it ;)

 

PS - On the topic of language-level security mechanisms, I notice that there’s now a proposal to remove Java’s notorious Security Manager sandbox [3].

What lessons did they learn from the SecurityManager debacle? Really, I'm curious. They've had 25 or so years to stew on it, as well as plentiful counter-examples to learn from.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/2DB6ED99-5110-403D-B7EB-66844A700D92%40forgerock.com.

--

  Cheers,
  --MarkM

[Ian Denhardt]

Quoting Neil Madden (2021-05-02 15:33:48)

> Is that simple?
> https://xsleaks.com/docs/attacks/timing-attacks/clocks/ suggests
> otherwise (at least in a browser).

It's much easier if you don't have the burden of compatibility with an
API that already provides these things.

For browser APIs, separating pages at the language level is probably a
lost cause, and process isolation does seem like the best available
solution.

> Also, I wouldn't want to bet that timings are the only side-channels
> to worry about.

The language approach, where applicable, works for *most* kinds of
side-channel I know of, but rowhammer is a notable exception -- hard to
do much about faulty hardware.

> That said, ocaps can also help in confining the ability of attacker
> code to exfiltrate any data it manages to access via Spectre.

Indeed.

-Ian

[Mark S. Miller]

On Sun, May 2, 2021 at 1:25 PM Mark S. Miller <eri...@gmail.com> wrote:

On Sun, May 2, 2021 at 12:33 PM Neil Madden <neil....@forgerock.com> wrote:

Is that simple? https://xsleaks.com/docs/attacks/timing-attacks/clocks/ suggests otherwise (at least in a browser). Also, I wouldn’t want to bet that timings are the only side-channels to worry about.

Timing is certainly not the only side channel to worry about. WeakRefs introduce a huge non-time side channel through the garbage collector. That's why Dean and I designed the JS WeakRefs to be deniable. And why, early on, we separated WeakMaps from WeakRefs, where WeakMaps provide many of the benefits of weakness without exposing observable GC. It's also one of the reasons SES denies `Math.random`. When not cryptographically strong, (as it normally is not) it is a side channel by shared mutable state (the hidden PRNG state).

In de facto JS, `error.stack` reveals the call stack, which is a non-timing side channel. The error-stacks proposal to make it de jure ensures that this side channel can be plugged.

--

  Cheers,
  --MarkM

[Mark S. Miller]

On Sun, May 2, 2021 at 1:31 PM Ian Denhardt <i...@zenhack.net> wrote:

Quoting Neil Madden (2021-05-02 15:33:48)
> Is that simple?
> https://xsleaks.com/docs/attacks/timing-attacks/clocks/ suggests
> otherwise (at least in a browser).

It's much easier if you don't have the burden of compatibility with an
API that already provides these things.

I have struggled since 2007 to keep new side channels out of the shared primordials --- now with many collaborators joining the fight! And we have also worked to quarantine and tame those non-timing side channels that were already present, like error.stack, Math.random, etc.

 

For browser APIs, separating pages at the language level is probably a
lost cause, and process isolation does seem like the best available
solution.

JS is much easier than the browser, yes. 

 

> Also, I wouldn't want to bet that timings are the only side-channels
> to worry about.

The language approach, where applicable, works for *most* kinds of
side-channel I know of, but rowhammer is a notable exception -- hard to
do much about faulty hardware.

Rowhammer is much much worse than a side channel. It is an integrity break, not just a confidentiality break. However, interestingly, the best defense against rowhammer, ECC, opens a side channel because reading a corrected word from memory takes observably longer than reading a non-corrected word. That side channel, though, is only timing based.

 

> That said, ocaps can also help in confining the ability of attacker
> code to exfiltrate any data it manages to access via Spectre.

Yes.

 

Indeed.

-Ian

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/161998743706.114661.4119947395067671387%40localhost.localdomain.

--

  Cheers,
  --MarkM

[John Lee]

First reaction: Of course! I hadn't thought of that, that's lovely

Second reaction: I still think it's lovely, but as Neil Madden points out, it does seem that a "clock" in computer security is usefully defined the same sort of way as in physics: it doesn't need to have been intended to function as a clock in order to be one.

But from what's been said it still seems that capability languages come out with a clear advantage: If further clocks are discovered they can, at least in principle, *also* be limited in scope to fit the application -- at least if potential clocks like SharedArrayBuffer are not "intrinsics" in a given cap language system (i.e. as long as they are not undeniable authority). I think most of the proposed clocks in the link that Neil posted [1] are deniable in SES for example, but I can't easily tell from the SES documentation if SharedArrayBuffer in particular is -- sounds like it doesn't go that far at present?

[1] https://xsleaks.com/docs/attacks/timing-attacks/clocks/

> > > send an email to [2]cap-talk+u...@googlegroups.com <mailto:cap-talk%2Bunsu...@googlegroups.com>.

> > > To view this discussion on the web visit
> > > [3]https://groups.google.com/d/msgid/cap-talk/77c81118-9982-46ef-88d
> > > 9-274563bf123b%40www.fastmail.com.
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "cap-talk" group.
> > > To unsubscribe from this group and stop receiving emails from it, send

> > > an email to [4]cap-talk+u...@googlegroups.com <mailto:cap-talk%2Bunsu...@googlegroups.com>.

> > > To view this discussion on the web visit
> > > [5]https://groups.google.com/d/msgid/cap-talk/CANpA1Z2Tq9wx6r3Stc18G6Rb
> > > Q_iL0oVqmHjQ2VbYVAoQt2ig%3DA%40mail.gmail.com.
> > >
> > > Verweise
> > >
> > > 1. mailto:j...@pobox.com

> > > 2. mailto:cap-talk%2Bunsu...@googlegroups.com <mailto:cap-talk%252Buns...@googlegroups.com>
> > > 3. https://groups.google.com/d/msgid/cap-talk/77c81118-9982-46ef-88d9-274563bf123b%40www.fastmail.com
> > > 4. mailto:cap-talk+u...@googlegroups.com <mailto:cap-talk%2Bunsu...@googlegroups.com>

> > > 5. https://groups.google.com/d/msgid/cap-talk/CANpA1Z2Tq9wx6r3Stc18G6RbQ_iL0oVqmHjQ2VbYVAoQt2ig%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer
> >
> > --
> > You received this message because you are subscribed to the Google Groups "cap-talk" group.

> > To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com <mailto:cap-talk%2Bunsu...@googlegroups.com>.

> > To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/161997951639.109556.13367004627856545994%40localhost.localdomain.
>
> --
> You received this message because you are subscribed to the Google
> Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to cap-talk+u...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/cap-talk/CAK-_AD6r6%3Dk97Wpw_qJ4s%2BZB_nHfZDuwBrn4T0Vn%3DDD-TOLwig%40mail.gmail.com <https://groups.google.com/d/msgid/cap-talk/CAK-_AD6r6%3Dk97Wpw_qJ4s%2BZB_nHfZDuwBrn4T0Vn%3DDD-TOLwig%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[John Lee]

On Sun, 2 May 2021, at 21:38, Mark S. Miller wrote:

> I have struggled since 2007 to keep new side channels out of the shared
> primordials --- now with many collaborators joining the fight!

I'm so glad to hear this! As an occasional observer, it has in the past seemed a difficult, high-effort, potentially open-ended, and rather thankless task to do the standards work you've been doing for so long. Wider recognition of its importance is obviously important to keep it going.

> And we
> have also worked to quarantine and tame those non-timing side channels
> that were already present, like error.stack, Math.random, etc.

Applause

[Mark S. Miller]

If you find any that SES does not deny, please let us know! We tried to get all of them and I think we have.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/0e0c572d-fd47-4127-aa8c-c7f0542655df%40www.fastmail.com.

--

  Cheers,
  --MarkM

[Mark S. Miller]

Thanks! I really appreciate that.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/84f59908-70e4-4d0d-a4bb-cf0d54064a5b%40www.fastmail.com.

--

  Cheers,
  --MarkM

[Mark S. Miller]

One of the more public fights was over enumeration order of hash tables. Most languages don't specify, leaving the order to the convenience of the implementation. Implementations will often enumerate according to where things land in internal hash tables, where object identity is hashed by memory address. This would have been another non-timing side channel. 

We fought hard to get all JS collections to enumerate in a deterministic order based on the history of operations. No one believed that this could be as fast. I pointed everyone at Tyler's Waterken hash tables which were as fast. Still no one believed it until someone (sorry I forgot who again :( ) tried it, comparing it against their existing well tuned conventional hash tables. Tyler's representation actually performed *better* though no one really knows why. Probably cache effects. In any case, with this Mozilla result in hand, everyone finally agreed. 

We won. All JS collections enumerate in a deterministic order. No side channel there.

--

  Cheers,
  --MarkM

[Ken Kahn]

Reading this thread I've been wondering about GPUs which are becoming critical for high-performance neural networks. And neural nets are becoming parts of more and more apps, including web apps. I assume that WebGPU introduces many side channels.

[William ML Leslie]

On Mon, 3 May 2021, 7:48 pm Ken Kahn, <toon...@gmail.com> wrote:

Reading this thread I've been wondering about GPUs which are becoming critical for high-performance neural networks. And neural nets are becoming parts of more and more apps, including web apps. I assume that WebGPU introduces many side channels.

It's unfortunate that the Coyotos Window System research never got funded (or never got the required grad students) while Shap was at Hhon Jopkins, as Marcus and Shap had been looking into information leakage in GPU scheduling.

[Jonathan S. Shapiro]

Responding belatedly to the “you can just deny access to a clock” statement.

There are many, many things that behave like clocks that are not de jure clocks, and especially so in multicore scenarios. Differences in comparative instruction timings are straightforward to detect, and this can’t be effectively prevented without imposing deterministic execution. Deterministic execution isn’t something people are going to impose in practice, because this entails rolling the processor architecture world back about 70 years. Caches, as an example, are not at all your friend when trying to defeat timing attacks. Out of order execution even more so, and that sits at the foundation of modern processor performance. 

On the whole, reinventing US manufacturing is a much easier problem to tackle in my dotage. :-)

[William ML Leslie]

Anything besides thread scheduling / message order and external
communication you have in mind?

--
William Leslie

Q: What is your boss's password?
A: "Authentication", clearly

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law. You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.

[Mark S. Miller]

On Tue, May 25, 2021 at 5:35 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Responding belatedly to the “you can just deny access to a clock” statement.

There are many, many things that behave like clocks that are not de jure clocks, and especially so in multicore scenarios. Differences in comparative instruction timings are straightforward to detect, and this can’t be effectively prevented without imposing deterministic execution. Deterministic execution isn’t something people are going to impose in practice,

I am. https://agoric.com/blog/all/taxonomy-of-security-issues/

 

because this entails rolling the processor architecture world back about 70 years.

No. It requires giving up ambient access to shared memory multithreading and other sneaky ways of measuring duration.

 

Caches, as an example, are not at all your friend when trying to defeat timing attacks.

In the absence of any ways of measuring duration, caches are great. Deterministic computation + caches is still deterministic.

 

Out of order execution even more so, and that sits at the foundation of modern processor performance. 

Again, only if you can somehow measure duration.

On the whole, reinventing US manufacturing is a much easier problem to tackle in my dotage. :-)

Solved: https://ses-demo.netlify.app/demos/challenge/ . 

This was much easier than reinventing US manufacturing. At least I assume so. I must admit I haven't tried that.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNRLHjiy5LOhnAXd0F9F20PZ-wwtF-JvfTp%3DoM6%2BzMJuw%40mail.gmail.com.

[Ian Denhardt]

Mark beat me too it the punch on many points, but I will just add: how
hard of a sell determinism is is going to depend a lot on the
application, but I actually think for most domains the answer is "not
very."

Non-determinism is a serious headache from a software engineering
standpoint as is, to the point where I think this is actually a pretty
easy sell without even talking about spectre in the pitch -- nothing
worse than a bug that's non-deterministic.

I suspect that, like memory safety, the problem is going to be much
harder for systems programming than it is elsewhere.

The real challenge, as always, is "what do we do about legacy systems?"

Quoting Jonathan S. Shapiro (2021-05-25 20:34:53)

> --
> You received this message because you are subscribed to the Google
> Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to [1]cap-talk+u...@googlegroups.com.

> To view this discussion on the web visit

> [2]https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNRLHjiy5LOhnAXd0
> F9F20PZ-wwtF-JvfTp%3DoM6%2BzMJuw%40mail.gmail.com.
>
> Verweise
>
> 1. mailto:cap-talk+u...@googlegroups.com
> 2. https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNRLHjiy5LOhnAXd0F9F20PZ-wwtF-JvfTp%3DoM6%2BzMJuw%40mail.gmail.com?utm_medium=email&utm_source=footer

[Mark S. Miller]

The talks I linked to also talk about putting legacy in a box, and how such boxed legacy affects overall risk. Both bad news and good. Legacy remains one of the main irreducible sources of risk after all other reasonable measures are taken. But that irreducible risk from boxed legacy can still be much smaller than most would expect.

The other main source of remaining risk is hardware supply chain risk. AFAICT, impossible to solve at reasonable cost. Blockchains solve it at unreasonable cost, but still a cost worth paying for the applications that run on blockchains.

To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/162199883108.842.5451933486510866459%40localhost.localdomain.

[Alan Karp]

Most modern applications are distributed, so I don't think confining the individual pieces is enough.

--------------
Alan Karp

To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/162199883108.842.5451933486510866459%40localhost.localdomain.

[Mark S. Miller]

Enough for what? ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1BsydGWU6q%3DcRs_h1dFu_9VEgX96U0u_2%2BHM%2BiTUZvxA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Alan Karp]

One service can be iterating in a loop and provide the count to other services on request.

--------------
Alan Karp

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYhWSb%3DSKK%3DBE0CXhXQrM6fuh19%3D74JMZASp4DqO%3D%3Dhm6Q%40mail.gmail.com.

[Mark S. Miller]

Yes, that exposes timing adequate to read non-overt (side and covert) channels. I got nothing for this one. Do you? Anyone?

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2KLUfeMRifV1UXEHDUc_3ZR%3DnTccRVeDYobs-Xe89wDQ%40mail.gmail.com.

[Ian Denhardt]

On Tue, May 25, 2021 at 9:16 PM Alan Karp <[1]alan...@gmail.com>

wrote:

> One service can be iterating in a loop and provide the count to other
> services on request.

Quoting Mark S. Miller (2021-05-26 00:45:34)

> Yes, that exposes timing adequate to read non-overt (side and covert)
> channels. I got nothing for this one. Do you? Anyone?

(Not really, but) Something related that's been on my mind: is there any
research out there trying to quantify what a "safe" resolution for a
clock would be, based on other details of the system?

It occurs to me that in the above scenario, depending on the resolution
of clock needed to observe a side-channel, and on the needs of the
application, it *may* be feasible to have the event loop be too low
resolution for this trick to work; if the variance of event response is
too high, or suitably quantized, in principle it could mask the timing
side-channel.

I've seen systems do somewhat ad-hoc things like wait 200ms before
returning 4xx HTTP responses, to mask the difference between permissions
errors and missing documents. I'd be curious to see what a more
mathematically rigorous attempt to describe the parameters of this
approach would yield.

I look at what dropping the requirement from no-information-leaks to
computationally-intractable-to-find-information-leaks has bought us in
cryptography, and wonder if there's a lesson there.

-Ian

[Carl Hewitt Twitter: ProfCarlHewitt]

Indeterminacy is the future of most systems especially including Intelligent Systems

In practice, indeterminate implementations can be hundreds of times faster than determinate ones.

See the following: https://papers.ssrn.com/abstract=3603021

Going forward, indeterminate implementations will become increasingly important.

Regards,

Carl

https://professorhewitt.blogspot.com/

[Jonathan S. Shapiro]

On Tue, May 25, 2021 at 5:46 PM William ML Leslie <william.l...@gmail.com> wrote:

Anything besides thread scheduling / message order and external
communication you have in mind?

I must be out of context here. I was talking about clocks. A combination of caching, multicore, and out of order execution makes an astonishingly fine grain clock.

[Jonathan S. Shapiro]

On Tue, May 25, 2021 at 6:01 PM Mark S. Miller <ma...@agoric.com> wrote:

Caches, as an example, are not at all your friend when trying to defeat timing attacks.

In the absence of any ways of measuring duration, caches are great. Deterministic computation + caches is still deterministic.

 

Out of order execution even more so, and that sits at the foundation of modern processor performance. 

Again, only if you can somehow measure duration.

Unfortunately, you *can* measure duration.

Most of the instruction speculation methods are subject to small forms of side-detect that weren’t considered architecturally significant. Cache contention rules and policies are known, which means you can manually control eviction. Having done so, you can use the side detection to observe the latency difference between an in-cache load and an out-of-cache load.

Voila.  Instant fine grain timer.

[William ML Leslie]

That's not a timer, that's a thing you want to time.

But perhaps your timer is another doing an operation that takes a consistent amount of time to do something, and knowledge of how it is scheduled?

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QOgpbw3z9z8Xq0Y3L-cPvDb7j_XKv_-DUS-vij8TUXdUw%40mail.gmail.com.

[William ML Leslie]

On Thu, 27 May 2021, 11:37 pm William ML Leslie, <william.l...@gmail.com> wrote:

On Thu, 27 May 2021, 11:33 pm Jonathan S. Shapiro, <jonathan....@gmail.com> wrote:

On Tue, May 25, 2021 at 6:01 PM Mark S. Miller <ma...@agoric.com> wrote:

Caches, as an example, are not at all your friend when trying to defeat timing attacks.

In the absence of any ways of measuring duration, caches are great. Deterministic computation + caches is still deterministic.

 

Out of order execution even more so, and that sits at the foundation of modern processor performance. 

Again, only if you can somehow measure duration.

Unfortunately, you *can* measure duration.

Most of the instruction speculation methods are subject to small forms of side-detect that weren’t considered architecturally significant. Cache contention rules and policies are known, which means you can manually control eviction. Having done so, you can use the side detection to observe the latency difference between an in-cache load and an out-of-cache load.

Voila.  Instant fine grain timer.

That's not a timer, that's a thing you want to time.

But perhaps your timer is another doing an operation that takes a consistent amount of time to do something, and knowledge of how it is scheduled?

Another *thread*. Brain is words missing evening this.

[Mark S. Miller]

Yes. Jonathan, you point out only operations that have a different duration, and so reveal side channels if you can measure that duration. But you would still need a means of measuring duration to read that side channel. That can be denied. In fact, https://ses-demo.netlify.app/demos/challenge/ denies it. The slide channel here is purposely loud. But you cannot read it.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAHgd1hGOe732cs1F8ZXtPLTDDMyREiB%3DG9LKz6EFE3_2weR76g%40mail.gmail.com.

[Jonathan S. Shapiro]

On Thu, May 27, 2021 at 6:37 AM William ML Leslie <william.l...@gmail.com> wrote:

.That's not a timer, that's a thing you want to time.

But perhaps your timer is another doing an operation that takes a consistent amount of time to do something, and knowledge of how it is scheduled?

It doesn’t have to be all that consistent. Many timing-based attacks have variants in which detecting *differences* in latency on a basis whose statistical reliability is known is sufficient to observe things. Or even to reconstruct second party data in the presence of non-architecturally shared memory that has shared latency observability. There was some interesting work a while back on the feasibility of computation in the presence of memory that had low statistical reliability of re-read. The methods are somewhat related. 

The cache timing and side detection attacks are real bad. Not because we turned out to be bare-asses naked on them, but because they strike at things that are so architecturally essential to the way we currently design programs. If we have to change the programmatic design approach, that will take a long time. 

[Jonathan S. Shapiro]

As I said, many hardware-level speculation mechanisms are imperfectly isolated.

[Mark S. Miller]

I don't get it. Please give an example of how you'd use any to measure duration in a single threaded supposedly deterministic computation in which all ways of escaping determinism were supposedly denied.

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QMP-gaU7Cqwn9G%3DAXHe3H%3DAYxHHTJPZNakFQ0GeVO9sdA%40mail.gmail.com.

[Jonathan S. Shapiro]

Mark:

I’m not talking about single threaded deterministic computation, which may be one source of our disconnect. There are still hardware-level side detection concerns here in some cases. Though I would think that use of byte code and JIT makes those a lot harder to access. Starting from a valid byte code program. 

The assertion that all ways of escaping determinism are denied is, of course, a problem area where we seem regularly discover new challenges. Part of what I’m saying is that escaping determinism is a lot easier than it first seems (as you know). Perhaps also that it is not sufficient to eliminate architectural multithreading; we probably need to consider multithreading that may be introduced by the underlying implementation (intentionally or otherwise). Node comes to mind here. 

In the course of your work in this area, have you had occasion to try to quantify the performance impact of determinism? I’m not preparing an objection. I’m thinking others will, and it would be nice to have some sense of the current state of the art in this regard. 

Jonathan 

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD6iKktvWyAFng9wJ1oBq9WMYzM29T%2B-NPvJheOCE6bfEA%40mail.gmail.com.

[Ian Denhardt]

Quoting Jonathan S. Shapiro (2021-05-27 12:03:25)

> In the course of your work in this area, have you had occasion to
> try to quantify the performance impact of determinism? I�m not
> preparing an objection. I'm thinking others will, and it would be
> nice to have some sense of the current state of the art in this
> regard.

I can't speak for Mark, but: I suspect part of the disconnect is that
the high-level language based approaches we're talking about here, while
actually fairly straightforward in principle, *do* require taking a
hard-line ban against concurrency entirely. It gets much much harder if
you're unwilling or unable to do that.

That's obviously a non-starter for some application domains, and for
most systems programming.

That said, in my experience people always expect getting by without
non-determinism to be harder than it really is.

My prediction for the future: we will have this problem "solved" for a
large swath of application domains much much sooner than we will for
some smaller subset of domains with specific requirements -- much in the
same way that memory safety has been a solved problem via GC for most
applications for a while, but we're only recently making real systematic
progress in systems programming. I don't know what the Rust of
side-channels looks like.

-Ian

[Carl Hewitt Twitter: ProfCarlHewitt]

For performance reasons, many-core scalable Intelligent Systems will not be deterministic.

How can they be defended against Spectre?

Regards,

Carl

https://professorhewitt.blogspot.com/

On Thu, May 27, 2021 at 7:25 AM Mark S. Miller <ma...@agoric.com> wrote:

I don't get it. Please give an example of how you'd use any to measure duration in a single threaded supposedly deterministic computation in which all ways of escaping determinism were supposedly denied.

On Thu, May 27, 2021 at 7:18 AM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

As I said, many hardware-level speculation mechanisms are imperfectly isolated.

view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD6iKktvWyAFng9wJ1oBq9WMYzM29T%2B-NPvJheOCE6bfEA%40mail.gmail.com.

[Ian Denhardt]

Note that there are models of parallel computation that don't require
non-determinism, so you don't *necessarily* need non-determinism to
exploit massively parallel hardware -- indeed, environments which
exploit the most parallelism do things like map/reduce, use GPUs etc.
which do not use multi-threading as their model.

That said, as I mentioned in another message, I do believe the problem
is harder for some classes of applications & and for systems programming
than it is for others.

-Ian

Quoting Carl Hewitt Twitter: ProfCarlHewitt (2021-05-27 15:01:16)

> For performance reasons, many-core scalable Intelligent Systems will
> not be deterministic.
> How can they be defended against Spectre?
> Regards,
> Carl

> [1]https://professorhewitt.blogspot.com/
> On Thu, May 27, 2021 at 7:25 AM Mark S. Miller <[2]ma...@agoric.com>

> wrote:
>
> I don't get it. Please give an example of how you'd use any to measure
> duration in a single threaded supposedly deterministic computation in
> which all ways of escaping determinism were supposedly denied.
>
> On Thu, May 27, 2021 at 7:18 AM Jonathan S. Shapiro
> <[3]jonathan....@gmail.com> wrote:
>
> As I said, many hardware-level speculation mechanisms are imperfectly
> isolated.
>
> view this discussion on the web visit

> [4]https://groups.google.com/d/msgid/cap-talk/CAK-_AD6iKktvWyAFng9wJ1oB
> q9WMYzM29T%2B-NPvJheOCE6bfEA%40mail.gmail.com.

>
> --
> You received this message because you are subscribed to the Google
> Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to [5]cap-talk+u...@googlegroups.com.
> To view this discussion on the web visit
> [6]https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2%2BP8_wPSMuCLej
> xwQdeosUTnHW%3DkurnW74rNYAy%2BcZFg%40mail.gmail.com.
>
> Verweise
>
> 1. https://professorhewitt.blogspot.com/
> 2. mailto:ma...@agoric.com
> 3. mailto:jonathan....@gmail.com
> 4. https://groups.google.com/d/msgid/cap-talk/CAK-_AD6iKktvWyAFng9wJ1oBq9WMYzM29T%2B-NPvJheOCE6bfEA%40mail.gmail.com?utm_medium=email&utm_source=footer
> 5. mailto:cap-talk+u...@googlegroups.com
> 6. https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2%2BP8_wPSMuCLejxwQdeosUTnHW%3DkurnW74rNYAy%2BcZFg%40mail.gmail.com?utm_medium=email&utm_source=footer

[Mark S. Miller]

Also important to note that there are large numbers of confluent computation strategies, where the pieces can run concurrently but the out *cannot* depend on the order in which the individual pieces proceeded. This is most obviously true for large classes of data parallelism.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/162213662471.958.16070419000202432470%40localhost.localdomain.

[Ben Laurie]

On Thu, 27 May 2021 at 17:03, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Mark:

I’m not talking about single threaded deterministic computation, which may be one source of our disconnect. There are still hardware-level side detection concerns here in some cases. Though I would think that use of byte code and JIT makes those a lot harder to access. Starting from a valid byte code program. 

Nope. There are Spectre attacks that work in JS using V8.

 

The assertion that all ways of escaping determinism are denied is, of course, a problem area where we seem regularly discover new challenges. Part of what I’m saying is that escaping determinism is a lot easier than it first seems (as you know). Perhaps also that it is not sufficient to eliminate architectural multithreading; we probably need to consider multithreading that may be introduced by the underlying implementation (intentionally or otherwise). Node comes to mind here. 

In the course of your work in this area, have you had occasion to try to quantify the performance impact of determinism? I’m not preparing an objection. I’m thinking others will, and it would be nice to have some sense of the current state of the art in this regard. 

The cost of mitigating Spectre in current CPUs is around 50%, and it probably is not a complete mitigation - i.e. your stuff runs at half the speed as a result of mitigation.

 

Jonathan 

On Thu, May 27, 2021 at 7:25 AM Mark S. Miller <ma...@agoric.com> wrote:

I don't get it. Please give an example of how you'd use any to measure duration in a single threaded supposedly deterministic computation in which all ways of escaping determinism were supposedly denied.

On Thu, May 27, 2021 at 7:18 AM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

As I said, many hardware-level speculation mechanisms are imperfectly isolated.

On Thu, May 27, 2021 at 7:01 AM Mark S. Miller <ma...@agoric.com> wrote:

Yes. Jonathan, you point out only operations that have a different duration, and so reveal side channels if you can measure that duration. But you would still need a means of measuring duration to read that side channel. That can be denied. In fact, https://ses-demo.netlify.app/demos/challenge/ denies it. The slide channel here is purposely loud. But you cannot read it.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QMP-gaU7Cqwn9G%3DAXHe3H%3DAYxHHTJPZNakFQ0GeVO9sdA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD6iKktvWyAFng9wJ1oBq9WMYzM29T%2B-NPvJheOCE6bfEA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QPbRJ%3D_Z4Xap10G2k9RFf5fr_qGp60OGvWJ7Yk4VjSpuw%40mail.gmail.com.

[Mark S. Miller]

On Thu, May 27, 2021 at 12:36 PM 'Ben Laurie' via cap-talk <cap-...@googlegroups.com> wrote:

On Thu, 27 May 2021 at 17:03, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Mark:

I’m not talking about single threaded deterministic computation, which may be one source of our disconnect. There are still hardware-level side detection concerns here in some cases. Though I would think that use of byte code and JIT makes those a lot harder to access. Starting from a valid byte code program. 

Nope. There are Spectre attacks that work in JS using V8.

Please try them against https://ses-demo.netlify.app/demos/challenge/

 

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CABrd9STrb9vzi3tpe5cADffZEgxOtbepDW50DFpPdTqOe%3Du-Kg%40mail.gmail.com.

[Mark S. Miller]

On Thu, May 27, 2021 at 12:36 PM 'Ben Laurie' via cap-talk <cap-...@googlegroups.com> wrote:

On Thu, 27 May 2021 at 17:03, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Mark:

I’m not talking about single threaded deterministic computation, which may be one source of our disconnect. There are still hardware-level side detection concerns here in some cases. Though I would think that use of byte code and JIT makes those a lot harder to access. Starting from a valid byte code program. 

Nope. There are Spectre attacks that work in JS using V8.

 

The assertion that all ways of escaping determinism are denied is, of course, a problem area where we seem regularly discover new challenges. Part of what I’m saying is that escaping determinism is a lot easier than it first seems (as you know). Perhaps also that it is not sufficient to eliminate architectural multithreading; we probably need to consider multithreading that may be introduced by the underlying implementation (intentionally or otherwise). Node comes to mind here. 

In the course of your work in this area, have you had occasion to try to quantify the performance impact of determinism? I’m not preparing an objection. I’m thinking others will, and it would be nice to have some sense of the current state of the art in this regard. 

The cost of mitigating Spectre in current CPUs is around 50%, and it probably is not a complete mitigation - i.e. your stuff runs at half the speed as a result of mitigation.

It depends what direction you're trying to mitigate. https://ses-demo.netlify.app/demos/challenge/ does not pay such a cost.

 

 

Jonathan 

On Thu, May 27, 2021 at 7:25 AM Mark S. Miller <ma...@agoric.com> wrote:

I don't get it. Please give an example of how you'd use any to measure duration in a single threaded supposedly deterministic computation in which all ways of escaping determinism were supposedly denied.

On Thu, May 27, 2021 at 7:18 AM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

As I said, many hardware-level speculation mechanisms are imperfectly isolated.

On Thu, May 27, 2021 at 7:01 AM Mark S. Miller <ma...@agoric.com> wrote:

Yes. Jonathan, you point out only operations that have a different duration, and so reveal side channels if you can measure that duration. But you would still need a means of measuring duration to read that side channel. That can be denied. In fact, https://ses-demo.netlify.app/demos/challenge/ denies it. The slide channel here is purposely loud. But you cannot read it.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QMP-gaU7Cqwn9G%3DAXHe3H%3DAYxHHTJPZNakFQ0GeVO9sdA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD6iKktvWyAFng9wJ1oBq9WMYzM29T%2B-NPvJheOCE6bfEA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QPbRJ%3D_Z4Xap10G2k9RFf5fr_qGp60OGvWJ7Yk4VjSpuw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CABrd9STrb9vzi3tpe5cADffZEgxOtbepDW50DFpPdTqOe%3Du-Kg%40mail.gmail.com.

[Carl Hewitt Twitter: ProfCarlHewitt]

In scalable many-core Intelligent Systems, expression parallelism

(map/reduce, GPUs, parallel lambda calculus, etc.)

can be hundreds of times slower than Actor implementations with indeterminacy.

The reason for the discrepancy is the deterministic system

in an episode gathers results from parallel expressions into a state and

then disperses results for the next episode.

Episodic deterministic execution can be hundreds of times slower than Actor execution with indeterminacy.

Regards,

Carl

https://professorhewitt.blogspot.com/

[Ian Denhardt]

I'd be interested in some concrete examples of systems you have in mind
that exploit non-determinism in an essential way; it's a bit hard to
follow just given the abstract claims.

Quoting Carl Hewitt Twitter: ProfCarlHewitt (2021-05-27 16:07:46)

> In scalable many-core Intelligent Systems, expression parallelism
> (map/reduce, GPUs, parallel lambda calculus, etc.)
> can be hundreds of times slower than Actor implementations with
> indeterminacy.
> The reason for the discrepancy is the deterministic system
> in an episode gathers results from parallel expressions into a state
> and
> then disperses results for the next episode.
> Episodic deterministic execution can be hundreds of times slower than
> Actor execution with indeterminacy.
> Regards,
> Carl

> [1]https://professorhewitt.blogspot.com/
> On Thu, May 27, 2021 at 12:10 PM Ian Denhardt <[2]i...@zenhack.net>

> wrote:
>
> Note that there are models of parallel computation that don't
> require
> non-determinism, so you don't *necessarily* need non-determinism to
> exploit massively parallel hardware -- indeed, environments which
> exploit the most parallelism do things like map/reduce, use GPUs
> etc.
> which do not use multi-threading as their model.
> That said, as I mentioned in another message, I do believe the
> problem
> is harder for some classes of applications & and for systems
> programming
> than it is for others.
> -Ian
> Quoting Carl Hewitt Twitter: ProfCarlHewitt (2021-05-27 15:01:16)
> >� � For performance reasons, many-core scalable Intelligent
> Systems will
> >� � not be deterministic.
> >� � How can they be defended against Spectre?
> >� � Regards,
> >� � Carl

> >� � [1][3]https://professorhewitt.blogspot.com/

> >� � On Thu, May 27, 2021 at 7:25 AM Mark S. Miller

> <[2][4]ma...@agoric.com>

> >� � wrote:
> >
> >� � I don't get it. Please give an example of how you'd use any
> to measure
> >� � duration in a single threaded supposedly deterministic
> computation in
> >� � which all ways of escaping determinism were supposedly
> denied.
> >
> >� � On Thu, May 27, 2021 at 7:18 AM Jonathan S. Shapiro

> >� � <[3][5]jonathan....@gmail.com> wrote:
> >
> >� � As I said, many hardware-level speculation mechanisms are
> imperfectly
> >� � isolated.
> >
> >� � view this discussion on the web visit
> >� �

> [4][6]https://groups.google.com/d/msgid/cap-talk/CAK-_AD6iKktvWyAFng
> 9wJ1oB
> >� � q9WMYzM29T%2B-NPvJheOCE6bfEA%[7]40mail.gmail.com.
> >
> >� � --

> >� � You received this message because you are subscribed to the
> Google
> >� � Groups "cap-talk" group.
> >� � To unsubscribe from this group and stop receiving emails from
> it, send

> >� � an email to [5][8]cap-talk+u...@googlegroups.com.

> >� � To view this discussion on the web visit
> >� �

> [6][9]https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2%2BP8_wPS
> MuCLej
> >� � xwQdeosUTnHW%3DkurnW74rNYAy%2BcZFg%[10]40mail.gmail.com.
> >
> > Verweise
> >
> >� � 1. [11]https://professorhewitt.blogspot.com/
> >� � 2. mailto:[12]ma...@agoric.com
> >� � 3. mailto:[13]jonathan....@gmail.com
> >� � 4.
> [14]https://groups.google.com/d/msgid/cap-talk/CAK-_AD6iKktvWyAFng9w
> J1oBq9WMYzM29T%2B-NPvJheOCE6bfEA%40mail.gmail.com?utm_medium=email&u
> tm_source=footer
> >� � 5. mailto:[15]cap-talk+u...@googlegroups.com
> >� � 6.
> [16]https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2%2BP8_wPSMu
> CLejxwQdeosUTnHW%3DkurnW74rNYAy%2BcZFg%40mail.gmail.com?utm_medium=e
> mail&utm_source=footer
>
> Verweise
>
> 1. https://professorhewitt.blogspot.com/
> 2. mailto:i...@zenhack.net
> 3. https://professorhewitt.blogspot.com/
> 4. mailto:ma...@agoric.com
> 5. mailto:jonathan....@gmail.com
> 6. https://groups.google.com/d/msgid/cap-talk/CAK-_AD6iKktvWyAFng9wJ1oB
> 7. http://40mail.gmail.com/
> 8. mailto:cap-talk%2Bunsu...@googlegroups.com
> 9. https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2%2BP8_wPSMuCLej
> 10. http://40mail.gmail.com/
> 11. https://professorhewitt.blogspot.com/
> 12. mailto:ma...@agoric.com
> 13. mailto:jonathan....@gmail.com
> 14. https://groups.google.com/d/msgid/cap-talk/CAK-_AD6iKktvWyAFng9wJ1oBq9WMYzM29T%2B-NPvJheOCE6bfEA%40mail.gmail.com?utm_medium=email&utm_source=footer
> 15. mailto:cap-talk%2Bunsu...@googlegroups.com
> 16. https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2%2BP8_wPSMuCLejxwQdeosUTnHW%3DkurnW74rNYAy%2BcZFg%40mail.gmail.com?utm_medium=email&utm_source=footer

[Carl Hewitt Twitter: ProfCarlHewitt]

See the following:

      

        Project Liftoff: Universal Intelligent Systems (UIS) by 2030

             https://papers.ssrn.com/abstract=3428114

      
       Video
             https://www.youtube.com/watch?v=PJ4X0l2298k

Regards,

Carl

https://professorhewitt.blogspot.com/

[Carl Hewitt Twitter: ProfCarlHewitt]

As distributed Intelligent Systems become increasingly omnipresent,

purely deterministic execution will become a niche technology

used only in special cases.

Regards,

Carl

https://professorhewitt.blogspot.com/

[Carl Hewitt Twitter: ProfCarlHewitt]

How difficult is it to re-architect processors so that they don't leak?

Cheers,

Carl

https://professorhewitt.blogspot.com/

[Alan Karp]

I just saw an article that said such changes can be done at the cost of 50% in performance.  

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc29J-JG6DydD8GBtodYUcSzA_uxD7bS8JaUUJo%2BEHiRMg%40mail.gmail.com.

[Mark S. Miller]

Link?

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3W-19vvyRqUJkCy%3DiEPg%3Dd5OR3arDpJcfiVKY_4-xKbQ%40mail.gmail.com.

[Alan Karp]

On Fri, May 28, 2021 at 1:24 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

Link?

You always ask the hardest questions!  

It wasn't an article at all; it was an email that Ben Laurie sent to cap-talk yesterday.  You can ask him where he got that figure, but it's consistent with what I remember about processor architecture.

--------------
Alan Karp

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD4g%3D9qu2URUfwx9Jg80zVm07D%2BsXzf6tcwHKo89obsdbg%40mail.gmail.com.

[Mark S. Miller]

Ok.

Ben, is there a public source for this result? Link?

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0O8vP34CcYQxG-uBfZpUsN68euR%2B4EWqLadpdy4cQKPQ%40mail.gmail.com.

[Ian Denhardt]

Quoting Carl Hewitt Twitter: ProfCarlHewitt (2021-05-28 10:31:44)

> purely deterministic execution will become a niche technology
> used only in special cases.

I don't buy this for a second. Even today, we see widespread practices
of developers sacrificing an order of magnitude or more of performance
for the sake of maintainability & productivity. Current hardware is
already way way faster than what most applications need, and the
software engineering benefits of determinism are too great for the
majority of applications to trade for a performance boost. There are
domains where it's worth the trouble, but they are the exception, not
the rule.

-Ian

[Alan Karp]

There are also smart contracts running on blockchains that are many orders of magnitude slower than they would be on a computer.  Some people seem to think it's worthwhile.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/162223406482.5791.6990143780434739790%40localhost.localdomain.

[Carl Hewitt Twitter: ProfCarlHewitt]

Intelligent Applications will become the norm almost everywhere with indeterminate execution.

Performance of an Intelligent Application will depend crucially on

the number of processors in its implementation.

Functionality and performance are crucial to competitiveness.

Of course, systems must be robust and maintainable.

Applications that are not intelligent will not be competitive.

Regards,

Carl

https://professorhewitt.blogspot.com/

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/162223406482.5791.6990143780434739790%40localhost.localdomain.

[Carl Hewitt Twitter: ProfCarlHewitt]

Will be interesting to see how this develops.

Slow contracts running on ledgers will be less competitive than fast contracts running on ledgers.

Also, in many cases implementations using ledgers will not be competitive with alternative implementations.

Regards,

Carl

https://professorhewitt.blogspot.com/

[Tony Arcieri]

On Fri, May 28, 2021 at 12:47 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:

How difficult is it to re-architect processors so that they don't leak?

If the question is specifically about Spectre-like attacks, this RISC-V research shows that in greenfield CPUs it's possible to design speculative execution in such a way that eliminates such sidechannels, by performing a continuous taint analysis relating to loads and stores and ensuring that at a "visibility point" where an attacker could attempt to leverage speculation as a covert channel, that no information is revealed:

https://dl.acm.org/doi/10.1145/3352460.3358274

Unfortunately, I don't think this method will be particularly helpful to existing mainstream chip designs, or at the very least it seems like it would be very hard to retrofit. It seems like something that needs to be foundational to how speculative execution is designed, i.e. hard rules that must be followed at all times or they don't work.

-- 

Tony Arcieri

[Bakul Shah]

Several thoughts occur to me.

1. What if the window of vulnerability is reduced considerably by intentionally flipping the bits (and invert the output) every time a row is recharged? Probably too long. So...

2. What if when a threshold number of acesses are done to a row, its adjacent rows are flipped intentionally?

3. I think what we also need to come up with higher level architectural/design principles that finesses problems like spectre and rowhammer (rather than just "mitigate" them). That means modeling such behavior so that we can properly characterize them.

4. What if even the hardware resources (TLB, cache etc.) are also treated as valuable resources to be protected to be handed out judiciously?

5. What if we design processors so that *no* supervisor mode kernel is needed? Though I suspect rowhammer can still be an issue in that the data structures the h/w would rely on can be corrupted....

-- Bakul

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc29J-JG6DydD8GBtodYUcSzA_uxD7bS8JaUUJo%2BEHiRMg%40mail.gmail.com.

[Tony Arcieri]

On Thu, May 27, 2021 at 12:10 PM Ian Denhardt <i...@zenhack.net> wrote:

Note that there are models of parallel computation that don't require
non-determinism, so you don't *necessarily* need non-determinism to
exploit massively parallel hardware -- indeed, environments which
exploit the most parallelism do things like map/reduce, use GPUs etc.
which do not use multi-threading as their model.

Indeed. When looking at the slow execution speed of e.g. Ethereum, the problem is primarily the execution model, which is not amenable to parallelization. That's over anything else, including the network layer and consensus, which is a result several different attempts at putting the EVM on a faster, cutting edge consensus/network layer have replicated independently.

There are several chains experimenting with much more performant and parallelizable execution models, like Avalanche and Solana. Designed correctly, execution models can be broken down into steps where one or more are "embarrassingly parallel" and thus amenable to execution on e.g. GPUs.

Perhaps the best original contribution (AFAIK) of the Bitcoin paper was the UTXO model, which permits this sort of property by design, at the cost of expressiveness, and I say that as someone who otherwise sees Bitcoin as technologically surpassed in every regard. The merits of the Ethereum account model are kind of like CISC versus RISC: they provided an easier programming API for an early generation of developers, but as time goes on it's clear that a different execution model will be required for performance, and perhaps a simpler foundation was what we needed all along.

Like RISC vs CISC, perhaps we can win back the "expressiveness" of the more complicated model by breaking it down into something like a set of standardized UTXO representations/transformations, the same way a modern Intel/AMD CPU's instruction decoder would break those CISC operations down into micro-ops. What something like that would actually look like concretely remains an area of ongoing research.

--

Tony Arcieri

[Carl Hewitt Twitter: ProfCarlHewitt]

As a practical matter, are there any leaks that Arm cannot prevent?

Thanks!

Carl

https://professorhewitt.blogspot.com/

[William ML Leslie]

On Sun, 30 May 2021 at 02:17, Carl Hewitt Twitter: ProfCarlHewitt
<carl.e...@gmail.com> wrote:
>
> As a practical matter, are there any leaks that Arm cannot prevent?
>

I am not aware of any.

Even the matter of shared caches have been worked around by the seL4 team.

What I would like to see is more CPU designers with training in
capability theory and related security disciplines; and otherwise, we
need to engage with them regularly to ensure shared resources are
partitioned and accounted for accurately.

--
William Leslie

Q: What is your boss's password?
A: "Authentication", clearly

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law. You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.

[Ben Laurie]

On Thu, 27 May 2021 at 21:02, Mark S. Miller <ma...@agoric.com> wrote:

On Thu, May 27, 2021 at 12:36 PM 'Ben Laurie' via cap-talk <cap-...@googlegroups.com> wrote:

On Thu, 27 May 2021 at 17:03, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Mark:

I’m not talking about single threaded deterministic computation, which may be one source of our disconnect. There are still hardware-level side detection concerns here in some cases. Though I would think that use of byte code and JIT makes those a lot harder to access. Starting from a valid byte code program. 

Nope. There are Spectre attacks that work in JS using V8.

Please try them against https://ses-demo.netlify.app/demos/challenge/

I don't see how they could apply - as far as I can see while the target is running, the attacker is blocked. That's a very artificial setup that, of course, defends well against this kind of attack.

[Ian Denhardt]

Quoting 'Ben Laurie' via cap-talk (2021-06-03 15:48:49)

> I don't see how they could apply - as far as I can see while the
> target is running, the attacker is blocked. That's a very artificial
> setup that, of course, defends well against this kind of attack.

I think you could relax this such that guess() returns a promise, which
resolves when the work (done by another thread) is complete, and this
would still hold, provided that:

- The other thread services these requests in FIFO order.
- There is otherwise no way for the program to set up a race between the
resolution of two different events, such that this could be used as a
timer.

That said,

> I'm not talking about single threaded deterministic computation, which
> may be one source of our disconnect.

I think this is correct; I don't think anyone on this thread has
disputed that if you have access to:

- non-deterministic multithreading
- some shared resource that can be manipulated and observed at a
sufficiently high frequency (memory being the obvious one, but
conceivably also something higher level like an event queue)

...then you can exploit timing side channels.

This feels like we're arguing as much about what is the topic of our
conversation as we are anything substantive. But the substantive
questions I think may be here are:

1. How applicable is deterministic programming?
2. For problem domains that do not admit deterministic programming
(which I think we all agree exist), are we screwed?

The sense I'm getting is that you and Johnathan believe some version of:

1. Not very.
2. Yes.

...whereas both Mark and I believe some version of:

1. Much more than you might think.
2. Good question.

...though if I've mischaracterized anyone's views please correct me.

I think if you'd asked me a decade and change ago when I was a grad
student doing operating systems stuff, I would have agreed with Ben &
Johnathan. Since then I've spent a lot more time doing high-level
programming, and it's made me realize that a lot of the assumptions I
had from systems programming about how programming has to work just
don't apply elsewhere. As I said, I don't know what the Rust of timing
side channels could look like.

-Ian

[Carl Hewitt Twitter: ProfCarlHewitt]

For future Intelligent Systems, my take is as follows:

1. Small sub-computations will be deterministic in larger indeterminate computations
2. Much can be done to mitigate side-channel attacks on current hardware.
   Future hardware can largely prevent significant damage from side-channel attacks.
   

Regards,

Carl

https://professorhewitt.blogspot.com/

[Mark S. Miller]

On Thu, Jun 3, 2021 at 2:39 PM Ian Denhardt <i...@zenhack.net> wrote:

Quoting 'Ben Laurie' via cap-talk (2021-06-03 15:48:49)

> I don't see how they could apply - as far as I can see while the
> target is running, the attacker is blocked. That's a very artificial
> setup that, of course, defends well against this kind of attack.

I think you could relax this such that guess() returns a promise, which
resolves when the work (done by another thread) is complete, and this
would still hold, provided that:

- The other thread services these requests in FIFO order.
- There is otherwise no way for the program to set up a race between the
  resolution of two different events, such that this could be used as a
  timer.

This modified challenge would be easy to arrange, with genuine concurrency, by using a worker. How would you attack it?

 

That said,

> I'm not talking about single threaded deterministic computation, which
> may be one source of our disconnect.

I think this is correct; I don't think anyone on this thread has
disputed that if you have access to:

- non-deterministic multithreading
- some shared resource that can be manipulated and observed at a
  sufficiently high frequency (memory being the obvious one, but
  conceivably also something higher level like an event queue)

...then you can exploit timing side channels.

This feels like we're arguing as much about what is the topic of our
conversation as we are anything substantive. But the substantive
questions I think may be here are:

1. How applicable is deterministic programming?
2. For problem domains that do not admit deterministic programming
   (which I think we all agree exist), are we screwed?

The sense I'm getting is that you and Johnathan believe some version of:

1. Not very.
2. Yes.

...whereas both Mark and I believe some version of:

1. Much more than you might think.
2. Good question.

...though if I've mischaracterized anyone's views please correct me.

Yes, your whole message accurately represents my position as well. Thanks!

 

I think if you'd asked me a decade and change ago when I was a grad
student doing operating systems stuff, I would have agreed with Ben &
Johnathan.  Since then I've spent a lot more time doing high-level
programming, and it's made me realize that a lot of the assumptions I
had from systems programming about how programming has to work just
don't apply elsewhere. As I said, I don't know what the Rust of timing
side channels could look like.

-Ian

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/162275629304.17970.349295975846634346%40localhost.localdomain.

[Mark S. Miller]

On Thu, Jun 3, 2021 at 4:29 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:

For future Intelligent Systems, my take is as follows:

1. Small sub-computations will be deterministic in larger indeterminate computations

Hi Carl, I'm glad we agree on that. From earlier correspondence I thought we disagreed. Encouraging!

 

1. Much can be done to mitigate side-channel attacks on current hardware.
   

"Much can be done" --- also agreed!

 

1. Future hardware can largely prevent significant damage from side-channel attacks.
   

I expect that there are large categories of side channel damage that future hardware can largely prevent, including Meltdown and Spectre -like attacks. But there are many kinds of side channels that cannot be addressed by hardware.

Of the remainder, I expect that there are large categories of side channel damage that privacy protecting cryptography (Zero Knowledge Proofs, Multiparty Secure Computation) can largely prevent. But much that it cannot.

Technologies like Onion Routers (e.g. TOR) mitigate other side channels.  I would not classify these as either hardware or crypto, though it is of course built out of both. I don't know how to bound this as a general category, but we need much more of this.

I expect that many kinds of side channel damage are simply unfixable by technology. We need to learn to live with these, or mitigate them by non-technological means. 

https://www.stripes.com/blogs-archive/the-rumor-doctor/the-rumor-doctor-1.104348/does-pizza-signal-a-crisis-at-the-white-house-1.112446

 

Regards,

Carl

https://professorhewitt.blogspot.com/

1. How applicable is deterministic programming?
2. For problem domains that do not admit deterministic programming
   (which I think we all agree exist), are we screwed?

The sense I'm getting is that you and Johnathan believe some version of:

1. Not very.
2. Yes.

...whereas both Mark and I believe some version of:

1. Much more than you might think.
2. Good question.

...though if I've mischaracterized anyone's views please correct me.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2Ge7z97TRvMaJDiw89JwkAmaoJqS-%3DV9tQwx-ipqescA%40mail.gmail.com.

[Ian Denhardt]

Quoting 'Mark S. Miller' via cap-talk (2021-06-03 19:30:20)

> This modified challenge would be easy to arrange, with genuine
> concurrency, by using a worker. How would you attack it?

I believe it is still secure -- I was trying to illustrate that making
guess() non-blocking wasn't enough to introduce a vulnerability on its
own.

[Mark S. Miller]

Hi Ian, sorry, I am not surprised that we agree here as well. I meant this as a challenge to Ben.

Ben, how would you attack the variant with the genuinely concurrent worker?

 

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/162276856310.21409.1895796218313066621%40localhost.localdomain.