Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

['David Chase' via golang-nuts]

I'm curious how much experience people have with hand-translation of one 
language into another.
What I find is that for not-too-different languages (e.g., C to Java, or C 
to Modula-3) I can process about 1000 lines per day.
K C to ANSI C goes a good deal more quickly.

C pointers translated into Java become a pair, the array that you are 
indexing into, and an index.
I used this strategy for gdtoa and it was good enough.
Unstructured and tricky-exit control flow translated into Java was a much 
more interesting change; for that I used a combination of break out of 
single iteration for loops, and sometimes booleans to indicate code that 
should be skipped (that was previously jumped over).

For Go you'd probably replace increment/decrement pointers with slices.

C++ would be harder because of templates, but it depends very much on how 
exciting the old code's use of templates is. The advantage of 
hand-translation is that you don't have to solve all the inputs that mighty 
theoretically arise, instead you need only consider the problem at hand, 
and if you can hack around the tricky bits in some ugly way, the rest tends 
to proceed rather smoothly.  And obviously (I hope this is obvious), if 
your goal is to increase security, you will not do it all with unsafe.

I did once also work on an automated source-to-source checker for C and 
C++, and it turns out that you can get a tremendous amount of mileage out 
of recognizing idioms and special-casing them.

The one problem with the approach I describe -- dealing with the code that 
you've got, selecting idiom-specific translations -- is that if it fails, 
what it means is that you have even more motivation to translate the input 
code out of C, because it is most likely tricksy, squirrelly, and all the 
more untrustworthy because of that.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[Eric S. Raymond]

Thomas Bushnell, BSG :
> On Fri, Jan 11, 2019 at 9:33 AM Eric S. Raymond  wrote:
> 
> > Thomas Bushnell, BSG :
> > > Suppose it has a way, however. Now you have Go code which will have a
> > > bounds fault instead of a data leak. That's better, I suppose - the
> > > resulting bug is now "the server crashes" instead of "the server maybe
> > > leaks a key". This is an improvement, but a packet-of-death across a
> > widely
> > > used library this puts the world in a not dissimilar position in terms of
> > > the level of panic and rapid response everybody needs.
> >
> > The difference is trhat an overt bug will elicit a fast fix.
> >
> 
> Was the Heartbleed fix particularly delayed? It seemed to be to be
> all-hands-on-deck.

No, but *noticing* it was delayed.  Always easier to notice a crash bug
than an exploit with subtler consequences.

> Also, this isn't part of your argument in the past; I would encourage you
> to make it explicitly, rather than treating it as a matter of "by
> transpiling we'll eliminate this category of security flaw". If the story
> is actually "we'll make the bugs more visible and people will panic sooner,
> resulting in a faster fix", that's a different argument, and I'd encourage
> making it explicitly instead of implicitly.

Fair enough.

My general claim is that graceful transpilation to Go, if it can be
achived, will both eliminate significant classes of bugs *and* flush
others into the open.  Both seem obvious consequences of (1) GC, (2)
improved type-chevking, and (3) runtime bounds-checking.

But maybe CCured is a better answer. I intend to investigate that.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

On Fri, Jan 11, 2019 at 9:33 AM Eric S. Raymond  wrote:

> Thomas Bushnell, BSG :
> > Suppose it has a way, however. Now you have Go code which will have a
> > bounds fault instead of a data leak. That's better, I suppose - the
> > resulting bug is now "the server crashes" instead of "the server maybe
> > leaks a key". This is an improvement, but a packet-of-death across a
> widely
> > used library this puts the world in a not dissimilar position in terms of
> > the level of panic and rapid response everybody needs.
>
> The difference is trhat an overt bug will elicit a fast fix.
>

Was the Heartbleed fix particularly delayed? It seemed to be to be
all-hands-on-deck.

Also, this isn't part of your argument in the past; I would encourage you
to make it explicitly, rather than treating it as a matter of "by
transpiling we'll eliminate this category of security flaw". If the story
is actually "we'll make the bugs more visible and people will panic sooner,
resulting in a faster fix", that's a different argument, and I'd encourage
making it explicitly instead of implicitly.

Thomas
-- 

memegen delenda est

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[Eric S. Raymond]

Jesper Louis Andersen :
> This must have been before I started reading this thread, but I know of the
> CCured project by George Necula et.al, which is a C-to-C translator:
> 
> https://web.eecs.umich.edu/~weimerw/p/p477-necula.pdf

That actually looks pretty interesting.

I may try testing on NTPsec.  If it lives up to its billing, the case
for mass transpilation to Go gets a lot weaker.

It doesn't go to zero - I think the maintainability gains from C to Go
lifts are likely to be significant - but it would remove a lot of
the security/reliability urgency.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[Eric S. Raymond]

Thomas Bushnell, BSG :
> Suppose it has a way, however. Now you have Go code which will have a
> bounds fault instead of a data leak. That's better, I suppose - the
> resulting bug is now "the server crashes" instead of "the server maybe
> leaks a key". This is an improvement, but a packet-of-death across a widely
> used library this puts the world in a not dissimilar position in terms of
> the level of panic and rapid response everybody needs.

The difference is trhat an overt bug will elicit a fast fix.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[Robert Engels]

Yes, but then you just got into those performance critical routines and hand 
code in the bounds checks and remove the automatic checking. Still a lot less 
work. 

> On Jan 11, 2019, at 2:50 AM, Nigel Tao  wrote:
> 
>> On Fri, Jan 11, 2019 at 5:46 PM Nigel Tao  wrote:
>>> On Fri, Jan 11, 2019 at 4:22 AM robert engels  wrote:
>>> Again, what is wrong with the bounds checking/memory protection 
>>> library/technique for C I referred you to? Even a decrease in performance 
>>> will probably still be on par or better than the equivalent Go program.
>> 
>> Quoting from https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html
>> 
>> "Matrix multiply (ikj, using array subscripting): Execution time:
>> slowdown of around 30 compared to unoptimised."
> 
> That page also links to a "recent re-implementation" MIRO, dated 2007,
> whose project report
> (https://www.doc.ic.ac.uk/~awl03/projects/miro/MIRO.pdf), section 6.2,
> says "gzip took considerably longer to compress when instrumented with
> MIRO than when using Mudflap or when uninstrumented: on average about
> 400 and 2,000 times slower respectively" and for the benchcpplinux
> suite, "our bounds-checker is much slower that Mudflap or unchecked
> code. This matches the results of the gzip benchmark".
> 
> They also say that some of that could theoretically be clawed back by
> (complicated) caching, but still, starting from 2000x slower is a long
> way back.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[Nigel Tao]

On Fri, Jan 11, 2019 at 5:46 PM Nigel Tao  wrote:
> On Fri, Jan 11, 2019 at 4:22 AM robert engels  wrote:
> > Again, what is wrong with the bounds checking/memory protection 
> > library/technique for C I referred you to? Even a decrease in performance 
> > will probably still be on par or better than the equivalent Go program.
>
> Quoting from https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html
>
> "Matrix multiply (ikj, using array subscripting): Execution time:
> slowdown of around 30 compared to unoptimised."

That page also links to a "recent re-implementation" MIRO, dated 2007,
whose project report
(https://www.doc.ic.ac.uk/~awl03/projects/miro/MIRO.pdf), section 6.2,
says "gzip took considerably longer to compress when instrumented with
MIRO than when using Mudflap or when uninstrumented: on average about
400 and 2,000 times slower respectively" and for the benchcpplinux
suite, "our bounds-checker is much slower that Mudflap or unchecked
code. This matches the results of the gzip benchmark".

They also say that some of that could theoretically be clawed back by
(complicated) caching, but still, starting from 2000x slower is a long
way back.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[Jesper Louis Andersen]

On Thu, Jan 10, 2019 at 9:00 PM Thomas Bushnell, BSG 
wrote:

>
> I think the paper you linked is exciting, and actually suggests that the
> hard work which needs to be done will solve the problem without a change of
> language. This fits my intuition: the things necessary to take advantage of
> type safety can only be automatically used with the same kind of proof work
> you need to do to establish the code was fine to begin with.
>
>
It is!

It is predated by another idea which is equally exciting but never ever
really tested in the large, namely proof carrying code.

in a PCC scheme, a program is accompanied with a proof of its behavior
according to some security policy. For instance that it is memory safe. The
proof is sent as an oracle stream: whenever the proof checker is in doubt
it consults the rule to apply from the oracle stream. This makes the proof
small. A program is checked before it is run. In particular, this avoids
the chain of trust by cryptographic signature. If the proof is correct, we
can run the program. The onus on constructing the proof is on the writer of
the program, or the code generator.

Whole classes of security bugs can be eliminated by updating the security
policy.

A simpler solution was one I somewhat haphazardly tried to suggest Russ Cox
on Twitter when he asked about solutions to the whole event-stream problem
we saw on NPM of node.js fame. Let software be able to drop certain
privileges after setup, in the style of OpenBSDs pledge(2) system call. If
a module pledges itself to only ever use limited functionality, and we
store this persistently, we solve many potential programming mistakes, and
we make life much harder for malicious injection. This is like a poor-mans
security policy, but it doesn't require the same attention to detail.

Another symbiosis solution I like is the idea that we should take old
software and run it, but next to a "contract checker", which is a piece of
software governing the potential unsafe software. Only if the checker
accepts the input, will it be passed to the potentially unsafe program.

-- 
J.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

On Thu, Jan 10, 2019 at 10:49 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Thu, Jan 10, 2019 at 7:39 PM Thomas Bushnell, BSG 
> wrote:
>
>>
>>> The server crashes - that's how we handle "any other exception", as a
>> rule.
>>
>>
> I write Erlang for a living. We don't crash a server, ever, on a failure.
> Unless the failure is persistent :)
>

Sorry, Eric was talking about Go, not just "something". There may be other
choices that would solve the problem where Go would not.

I think the paper you linked is exciting, and actually suggests that the
hard work which needs to be done will solve the problem without a change of
language. This fits my intuition: the things necessary to take advantage of
type safety can only be automatically used with the same kind of proof work
you need to do to establish the code was fine to begin with.

Thomas
-- 

memegen delenda est

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[Jesper Louis Andersen]

On Thu, Jan 10, 2019 at 7:39 PM Thomas Bushnell, BSG 
wrote:

>
>> The server crashes - that's how we handle "any other exception", as a
> rule.
>
>
I write Erlang for a living. We don't crash a server, ever, on a failure.
Unless the failure is persistent :)

>
> I don't know what you mean by "just fork the process". First, if you're
> transpiling into Go, that's not a good strategy. Second, are you suggesting
> the transpiler would automatically rewrite the request handling loop to
> avoid the harm of crashes?
>
>
I wasn't specifically thinking about Go here. In particular, Go doesn't
have the properties I sketched out, so I'm not sure a C-to-Go compiler
would solve the problem.

Personally, I think C-to-C translation in the style of CCured is the most
likely successful path. But I still like the idea of embedding a C program
into another language, thus forming a symbiotic relationship between the
two.

-- 
J.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[robert engels]

It was actually a different but related thread about converting C to Go…. the 
link I sent was https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html 


> On Jan 10, 2019, at 12:20 PM, Jesper Louis Andersen 
>  wrote:
> 
> This must have been before I started reading this thread, but I know of the 
> CCured project by George Necula et.al , which is a C-to-C 
> translator:
> 
> https://web.eecs.umich.edu/~weimerw/p/p477-necula.pdf 
> 
> 
> On Thu, Jan 10, 2019 at 6:22 PM robert engels  > wrote:
> Again, what is wrong with the bounds checking/memory protection 
> library/technique for C I referred you to? Even a decrease in performance 
> will probably still be on par or better than the equivalent Go program.
> 
> Much simpler and efficient.
> 
>> On Jan 10, 2019, at 10:49 AM, Jesper Louis Andersen 
>> mailto:jesper.louis.ander...@gmail.com>> 
>> wrote:
>> 
>> On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts 
>> mailto:golang-nuts@googlegroups.com>> wrote:
>> 
>> I'm curious about why transpilation would have significantly mitigated the 
>> Heartbleed bug.
>> 
>> 
>> Heartbleed is a bug which relies on two things:
>> 
>> - Failure to do proper bounds checking
>> - Allocation of a buffer which is not initialized to some zero-value, and 
>> which straddles memory it shouldn't.
>> 
>> Many programming languages are constructed such that they address both of 
>> the above problems at the semantics level, and thus they avoid the really 
>> dangerous part of the bug, which is the leak of information, downgrading the 
>> bug to a denial of service attack, or even also mitigating that part of the 
>> bug. Array access is checked against the arrays bounds, and buffer allocated 
>> memory is properly 0-initialized before use.
>> 
>> Compilation from one language to another might have the side-effect of 
>> changing the semantics of the program because of the above observations. 
>> Thus making a previously unsafe program safe. In principle we want to be 
>> clever: augment the program with new safety semantics, but without changing 
>> the meaning of the rest of the program in any way.
>> 
>> Given there is a very large body of C code out there, live, we want to take 
>> an approach like the above:
>> 
>> - A rewrite, into say Rust because it is currently popular, runs the risk of 
>> re-introducing faults in the programs which were removed through corrections 
>> over the years.
>> - We rewrite too much, where we should reuse.
>> - C is a remarkably stable programming language in that most older C code 
>> still runs in this day and age. More or less, there are some caveats, which 
>> the compilation idea ought to address. Many modern languages have a 
>> tremendous amount of bit-rot in the sense even 2-3 year old programs now 
>> utter fail to run.
>> 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> 
> -- 
> J.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

>
>
> * Even if we did this, the bug only turns into a packet of death. A packet
>> of death on this scale is of almost the same level of annoyance and chaos.
>> (Witness this week's firestorm about an email packet of death on some Cisco
>> something or other.)
>>
>>
> I did address this. If each request is bounds checked and memory isolated,
> then a failure is just an exception of some kind and we handle this as we
> would any other exception. You could also just fork the process for each
> incoming request and obtain the same semantics.
>

The server crashes - that's how we handle "any other exception", as a rule.

That's a lot of work to convert "leaking session keys" into "crashes the
server".

Especially since you turn "maybe leaks a session key on repeated tries"
into "crashes the server immediately with a single packet". Maybe the
result actually makes things worse. :)

I don't know what you mean by "just fork the process". First, if you're
transpiling into Go, that's not a good strategy. Second, are you suggesting
the transpiler would automatically rewrite the request handling loop to
avoid the harm of crashes?

Thomas
-- 

memegen delenda est

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[Jesper Louis Andersen]

On Thu, Jan 10, 2019 at 6:26 PM Thomas Bushnell, BSG 
wrote:

> I'm not sure the second one here is right. Heartbleed does not depend on
> unitialized memory as far as I can tell. It works to copy whatever lies
> after the incoming request buffer back to the attacker. It happens that in
> the actual openssl code the thing it's copying is a reused buffer that
> might have stuff in it (IIRC), but that's not essential to the operation of
> the bug. If it were an exactly sized buffer the same shape of problem would
> occur.
>
>
Well, if there is no way to reuse a buffer in the language, then things
will work out. More or less any functional language will do.

> You left unaddressed:
> * How would this magical translation going to occur, given the actual code
> of openssl? The obvious *human *translation is to allocate a request
> buffer, and then use the encoding/binary package to pull values. The
> attempt to read indexes greater than the size of the buffer would fault.
> But I don't see a way to take code like openssl and automatically make it
> use encoding/binary. The only clear way I can see to do it *automatically
> *is to use unsafe.Pointer, which simply turns off all the bounds checking
> you wanted.
>
>
I think the problem is a good research question. I don't think we have a
good solution at the moment. But there is a lot of value in pushing the
research forward in the area. So the answer to this question is: "I don't
know, but I do have ideas where I would start".



> * Even if we did this, the bug only turns into a packet of death. A packet
> of death on this scale is of almost the same level of annoyance and chaos.
> (Witness this week's firestorm about an email packet of death on some Cisco
> something or other.)
>
>
I did address this. If each request is bounds checked and memory isolated,
then a failure is just an exception of some kind and we handle this as we
would any other exception. You could also just fork the process for each
incoming request and obtain the same semantics.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[Jesper Louis Andersen]

This must have been before I started reading this thread, but I know of the
CCured project by George Necula et.al, which is a C-to-C translator:

https://web.eecs.umich.edu/~weimerw/p/p477-necula.pdf

On Thu, Jan 10, 2019 at 6:22 PM robert engels  wrote:

> Again, what is wrong with the bounds checking/memory protection
> library/technique for C I referred you to? Even a decrease in performance
> will probably still be on par or better than the equivalent Go program.
>
> Much simpler and efficient.
>
> On Jan 10, 2019, at 10:49 AM, Jesper Louis Andersen <
> jesper.louis.ander...@gmail.com> wrote:
>
> On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>>
>> I'm curious about why transpilation would have significantly mitigated
>> the Heartbleed bug.
>>
>>
> Heartbleed is a bug which relies on two things:
>
> - Failure to do proper bounds checking
> - Allocation of a buffer which is not initialized to some zero-value, and
> which straddles memory it shouldn't.
>
> Many programming languages are constructed such that they address both of
> the above problems at the semantics level, and thus they avoid the really
> dangerous part of the bug, which is the leak of information, downgrading
> the bug to a denial of service attack, or even also mitigating that part of
> the bug. Array access is checked against the arrays bounds, and buffer
> allocated memory is properly 0-initialized before use.
>
> Compilation from one language to another might have the side-effect of
> changing the semantics of the program because of the above observations.
> Thus making a previously unsafe program safe. In principle we want to be
> clever: augment the program with new safety semantics, but without changing
> the meaning of the rest of the program in any way.
>
> Given there is a very large body of C code out there, live, we want to
> take an approach like the above:
>
> - A rewrite, into say Rust because it is currently popular, runs the risk
> of re-introducing faults in the programs which were removed through
> corrections over the years.
> - We rewrite too much, where we should reuse.
> - C is a remarkably stable programming language in that most older C code
> still runs in this day and age. More or less, there are some caveats, which
> the compilation idea ought to address. Many modern languages have a
> tremendous amount of bit-rot in the sense even 2-3 year old programs now
> utter fail to run.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
J.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

On Thu, Jan 10, 2019 at 8:50 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>>
>> I'm curious about why transpilation would have significantly mitigated
>> the Heartbleed bug.
>>
>>
> Heartbleed is a bug which relies on two things:
>
> - Failure to do proper bounds checking
> - Allocation of a buffer which is not initialized to some zero-value, and
> which straddles memory it shouldn't.
>
> Many programming languages are constructed such that they address both of
> the above problems at the semantics level, and thus they avoid the really
> dangerous part of the bug, which is the leak of information, downgrading
> the bug to a denial of service attack, or even also mitigating that part of
> the bug. Array access is checked against the arrays bounds, and buffer
> allocated memory is properly 0-initialized before use.
>

I'm not sure the second one here is right. Heartbleed does not depend on
unitialized memory as far as I can tell. It works to copy whatever lies
after the incoming request buffer back to the attacker. It happens that in
the actual openssl code the thing it's copying is a reused buffer that
might have stuff in it (IIRC), but that's not essential to the operation of
the bug. If it were an exactly sized buffer the same shape of problem would
occur.

I don't think you responded to my email very successfully.

You left unaddressed:
* How would this magical translation going to occur, given the actual code
of openssl? The obvious *human *translation is to allocate a request
buffer, and then use the encoding/binary package to pull values. The
attempt to read indexes greater than the size of the buffer would fault.
But I don't see a way to take code like openssl and automatically make it
use encoding/binary. The only clear way I can see to do it *automatically *is
to use unsafe.Pointer, which simply turns off all the bounds checking you
wanted.

* Even if we did this, the bug only turns into a packet of death. A packet
of death on this scale is of almost the same level of annoyance and chaos.
(Witness this week's firestorm about an email packet of death on some Cisco
something or other.)

Thomas

-- 

memegen delenda est

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[robert engels]

Again, what is wrong with the bounds checking/memory protection 
library/technique for C I referred you to? Even a decrease in performance will 
probably still be on par or better than the equivalent Go program.

Much simpler and efficient.

> On Jan 10, 2019, at 10:49 AM, Jesper Louis Andersen 
>  wrote:
> 
> On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts 
> mailto:golang-nuts@googlegroups.com>> wrote:
> 
> I'm curious about why transpilation would have significantly mitigated the 
> Heartbleed bug.
> 
> 
> Heartbleed is a bug which relies on two things:
> 
> - Failure to do proper bounds checking
> - Allocation of a buffer which is not initialized to some zero-value, and 
> which straddles memory it shouldn't.
> 
> Many programming languages are constructed such that they address both of the 
> above problems at the semantics level, and thus they avoid the really 
> dangerous part of the bug, which is the leak of information, downgrading the 
> bug to a denial of service attack, or even also mitigating that part of the 
> bug. Array access is checked against the arrays bounds, and buffer allocated 
> memory is properly 0-initialized before use.
> 
> Compilation from one language to another might have the side-effect of 
> changing the semantics of the program because of the above observations. Thus 
> making a previously unsafe program safe. In principle we want to be clever: 
> augment the program with new safety semantics, but without changing the 
> meaning of the rest of the program in any way.
> 
> Given there is a very large body of C code out there, live, we want to take 
> an approach like the above:
> 
> - A rewrite, into say Rust because it is currently popular, runs the risk of 
> re-introducing faults in the programs which were removed through corrections 
> over the years.
> - We rewrite too much, where we should reuse.
> - C is a remarkably stable programming language in that most older C code 
> still runs in this day and age. More or less, there are some caveats, which 
> the compilation idea ought to address. Many modern languages have a 
> tremendous amount of bit-rot in the sense even 2-3 year old programs now 
> utter fail to run.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[Jesper Louis Andersen]

On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

>
> I'm curious about why transpilation would have significantly mitigated the
> Heartbleed bug.
>
>
Heartbleed is a bug which relies on two things:

- Failure to do proper bounds checking
- Allocation of a buffer which is not initialized to some zero-value, and
which straddles memory it shouldn't.

Many programming languages are constructed such that they address both of
the above problems at the semantics level, and thus they avoid the really
dangerous part of the bug, which is the leak of information, downgrading
the bug to a denial of service attack, or even also mitigating that part of
the bug. Array access is checked against the arrays bounds, and buffer
allocated memory is properly 0-initialized before use.

Compilation from one language to another might have the side-effect of
changing the semantics of the program because of the above observations.
Thus making a previously unsafe program safe. In principle we want to be
clever: augment the program with new safety semantics, but without changing
the meaning of the rest of the program in any way.

Given there is a very large body of C code out there, live, we want to take
an approach like the above:

- A rewrite, into say Rust because it is currently popular, runs the risk
of re-introducing faults in the programs which were removed through
corrections over the years.
- We rewrite too much, where we should reuse.
- C is a remarkably stable programming language in that most older C code
still runs in this day and age. More or less, there are some caveats, which
the compilation idea ought to address. Many modern languages have a
tremendous amount of bit-rot in the sense even 2-3 year old programs now
utter fail to run.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

[Jesper Louis Andersen]

On Wed, Jan 9, 2019 at 7:07 PM Eric S. Raymond  wrote:

>
> I agree.  The class of old C program I am interested in is, however,
> not generally limited by CPU but by network and (less commonly) disk
> stalls.  Again bear in mind that my type examples are NTP and DNS service.
> A lot of other legacy infrastructure code fits this pattern.
>
>
Can I get a -vv flag on this one?

That the PLL of NTP is network-latency sensitive, I understand. But a DNS
service, to me, should never ever touch the disk, or you are doing
something really wrong. I'm more inclined to guess that these services are
bound by memory bandwidth and latency more than CPU execution speed.

So I'm curious what insight you might have on this subject?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

On Wed, Jan 9, 2019 at 10:07 AM Eric S. Raymond  wrote:

> > Reasonable people can disagree, but I favor rewriting over
> > transpilation, for draining that swamp.
>
> The problem is that in general nobody *does* rewrite old
> infrastructure code.  It tends to work just well enough to fester in
> place for a long time, and then you get shocks like the Heartbleed
> bug.  It is my aim to head off that sort of thing in the future.
>

I'm curious about why transpilation would have significantly mitigated the
Heartbleed bug.

It sounds as though the idea is a mass transpilation of old libraries, but
that's going to require more than just a library. Suppose openssl had been
transpiled into Go well in advance of the attack. This isn't going to stop
old C code from linking against the old library, and it's all going to stay
there. So you'd need to transpile all the programs which use the library
too, it seems to me, and release them into all the distros, and have them
all agree. That seems a rather high hurdle. You could, of course, just
release a transpiled version of a bunch of libraries, but now my guess is
there's two things to maintain instead of one, and nothing ever makes the
old one go away.

But suppose that hurdle is fixed, and think about the specific Heartbleed
bug. The bug involved a mistake in unmarshalling a particular type of SSL
packet, trusting a length field from an inbound packet; the fix was to see
the length and discard the incoming packet if it was bogusly long.

The specific problem was that if the length field was bogusly big, the code
would do the echo reply with the next N bytes after the incoming packet in
memory, which could include whatever was in memory after the packet.

The transpiler is going to be amazing clever to even get this code right.
It's code which bounces around *char manually unmarshalling a piece of
structured data. Consider this: hbtype = *p++.

What's that going to be? Is it going to be turned into pointer arithmetic
using the unsafe package? Now you'll just get the same bug again. Obviously
new Go code would stick the packet in a []byte, and then use the facilities
of the binary package to read the bits, and the attempt to read past the
end of the slice will fail. But how is a transpiler going to automatically
take the C code of openssl and do that?

Suppose it has a way, however. Now you have Go code which will have a
bounds fault instead of a data leak. That's better, I suppose - the
resulting bug is now "the server crashes" instead of "the server maybe
leaks a key". This is an improvement, but a packet-of-death across a widely
used library this puts the world in a not dissimilar position in terms of
the level of panic and rapid response everybody needs.

So I'm not quite seeing it. It seems like a great idea from the outside
("hey, we could turn all these programs into memory-safe Go programs,
automatically, what a win!") but in practice, I'm not sure I see such a
transpiler actually working in a way that would achieve the result - and
the end is to preserve a profound denial of service attack anyway.

Thomas

-- 

memegen delenda est

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Wuffs: a new, memory-safe programming language

[Eric S. Raymond]

Nigel Tao :
> Spun out of the "C++ 11 to Golang convertor" thread...
> 
> 
> On Mon, Jan 7, 2019 at 12:27 AM Eric S. Raymond  wrote:
> > Perry and I have two different target languages in mind.  Perry's
> > target language is basically a repaired C - type-safe, almost
> > upward-compatible. He and I have the same strategic goal - draining
> > the swamp of old, leaky C code - we're just betting on slightly
> > different ways to do it. We intend to cooperate as much as possible.
> 
> This is drifting quite off-topic, but I would expect transpiling C to
> Go would result in something slower than the original, especially if
> it involves a lot of low-level, slice-of-bytes processing. Faster is
> obviously easier to sell than slower.

I agree.  The class of old C program I am interested in is, however,
not generally limited by CPU but by network and (less commonly) disk
stalls.  Again bear in mind that my type examples are NTP and DNS service.
A lot of other legacy infrastructure code fits this pattern.

> Go is memory-safe, but that entails e.g. runtime bounds checking. Any
> individual bounds check might be cheap, measured in nanos, but for
> e.g. image decoding, a per pixel bounds check multiplied by a
> megapixel image (a 'low-res' photo, by today's standards) means that
> nanos become millis.

Again agreed.  Transpilation to Go is only appropriate for cases where
nanos becoming millis doesn't matter. Typically, old infrastructure code
was designed for platforms now enough Dennard-scaling cycles in the past
that Go on current hardware will run faster than C did originally.

> Reasonable people can disagree, but I favor rewriting over
> transpilation, for draining that swamp.

The problem is that in general nobody *does* rewrite old
infrastructure code.  It tends to work just well enough to fester in
place for a long time, and then you get shocks like the Heartbleed
bug.  It is my aim to head off that sort of thing in the future.

> https://github.com/google/wuffs is a new, memory-safe programming
> language and a written-from-scratch library of various file formats.
> Runtime performance is a special concern: there are no implicit
> (runtime) bounds checks. Unlike Go, bounds checks have to be explicit,
> which means that programs can eliminate them from the object code by,
> well, eliminating them from the source code.

That is an interesting and clever approach.

I think all three approaches should be in the toolkit.  They fit different
use cases.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.