profile
viewpoint

kristapsdz/rpki-client 20

RPKI client implementation

4ad/go 14

Go development tree for the sparc64 port

jenkinsci/jenkins-charm 14

Juju charm to deploy and scale Jenkins

4a6f656c/boulder 0

An ACME-based CA, written in Go.

4a6f656c/dns 0

DNS library in Go

4a6f656c/go 0

The Go programming language

4a6f656c/go-sys 0

[mirror] Go packages for low-level interaction with the operating system

4a6f656c/hockeypuck 0

OpenPGP Key Server

4a6f656c/inspircd 0

A modular C++ IRC server (ircd).

pull request commentgoogle/oss-fuzz

[libressl] Add standalone Cryptofuzz instance

LGTM (and on behalf of the LibreSSL team)

guidovranken

comment created time in 7 days

PR opened libressl-portable/portable

Reviewers
Make pthread_mutex static initialisation work on Windows.

This takes the dynamic initialisation code added to CRYPTO_lock() in e5081719 and applies it to the Window's pthread_mutex implementation. This allows for PTHREAD_MUTEX_INITIALIZER to be used on Windows.

bcook has agreed to place this code in the public domain (as per the rest of the code in pthread.h).

+23 -5

0 comment

1 changed file

pr created time in 9 days

create barnch4a6f656c/portable

branch : windows-pthread-init

created branch time in 9 days

fork 4a6f656c/portable

LibreSSL Portable itself. This includes the build scaffold and compatibility layer that builds portable LibreSSL from the OpenBSD source code. Pull requests or patches sent to tech@openbsd.org are welcome.

fork in 9 days

issue commentgolang/go

proposal: all: add openbsd/mips64 port

@dmitshur what kind of time frame should I expect on this?

4a6f656c

comment created time in 17 days

issue commentgolang/go

all: add cgo support to the riscv port

Hi @4a6f656c , any news on upstreaming CGO/PIE support for the next Go release? I believe the 1.16 freeze starts in november.

The first step is to get external linking support - a review for that is currently pending:

https://go-review.googlesource.com/c/go/+/243517

4a6f656c

comment created time in a month

issue commentgolang/go

cmd/link/internal/arm: missing relocations for SDYNIMPORT with trampolines

You are right, it seems the trampoline doesn't have the dynamic relocations in internal linking mode. We could add that.

Any pointers on what would be involved here?

In general, cgo_import_dynamic is not user-facing, so it is not surprising that it only works on platforms that the toolchain or runtime actually uses it.

Indeed, as I've been discovering :)

4a6f656c

comment created time in a month

pull request commenttomato42/tlsfuzzer

Add a TLSv1.3 test that ensures a zero content type is handled correctly

do you want to file bugs against gnutls and NSS that they handle those records incorrectly, or should I do it?

Please go ahead - if you would not mind providing links to the reports, that would be great.

4a6f656c

comment created time in a month

issue openedgolang/go

cmd/link/internal/arm: missing relocations for SDYNIMPORT with trampolines

Compiling the following code on openbsd/arm with Go -tip:

$ cat x.go
package main

import (
        _ "unsafe"
)

//go:cgo_import_dynamic libc_getpid getpid "libc.so"

//go:cgo_import_dynamic _ _ "libc.so"

func getpid_trampoline()

func main() {
        getpid_trampoline()
}
$ cat x.s
TEXT ·getpid_trampoline(SB),0,$0
        CALL    libc_getpid(SB)
        RET

On openbsd/arm results in a working binary:

$ go build -o b                               
$ ./b && echo $?
0
$ ldd ./b
./b:
        Start    End      Type  Open Ref GrpRef Name
        00010000 000e5000 exe   1    0   0      ./b
        6af65000 6b02f000 rlib  0    1   0      /usr/lib/libc.so.96.0
        78a24000 78a24000 ld.so 0    1   0      /usr/libexec/ld.so

$ objdump -R ./b    

./b:     file format elf32-littlearm

DYNAMIC RELOCATION RECORDS
OFFSET   TYPE              VALUE 
000d002c R_ARM_JUMP_SLOT   getpid

However, compiling with -ldflags=debugtramp=2 results in a non-working binary without relocations:

$ go build -ldflags=-debugtramp=2 -o b        
$ ./b && echo $?
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]

goroutine 1 [running]:
main.getpid_trampoline(0x6505c, 0x418080, 0x0, 0x418080, 0x0, 0x0, 0x0, 0x0, 0x4000e0, 0x4247cc, ...)
        x.s:7 +0x14
main.main()
        x.go:18 +0x14
$ go build -ldflags=-debugtramp=2 -o b  
$ ldd ./b                                            
./b:
        Start    End      Type  Open Ref GrpRef Name
        00010000 000e5000 exe   1    0   0      ./b
        640a1000 6416b000 rlib  0    1   0      /usr/lib/libc.so.96.0
        6ad37000 6ad37000 ld.so 0    1   0      /usr/libexec/ld.so
$ objdump -R ./b 

./b:     file format elf32-littlearm

DYNAMIC RELOCATION RECORDS (none)

Given this is compiler specific, I would imagine this would be reproducable on linux/arm and freebsd/arm. I believe the issue is caused by the relocations being lost as part of the trampoline generation.

The same issue exists with Go 1.13.9, so it does not appear to be a recent linker regression.

created time in a month

pull request commenttomato42/tlsfuzzer

Add a TLSv1.3 test that ensures a zero content type is handled correctly

Sorry, I hoped that I won't need to force you to do that, but please squash the changes and rebase, not merge master to this branch: the the last merge of master to this branch caused tests in Travis to fail.

Nothing to force, only need to ask :)

This is because we have Travis set up in a way it runs tests on each commit in turn, so if there are 3 commits it runs the test suite 3 times (to make sure that the test suite is always runnable, in case it is needed in a future bisect), but if there are merge commits it will rerun test suite on all commits until the first common commit of master an this branch, irrespective of merges.

No problem - different projects have different preferences. Have squashed and rebased.

Reviewed 1 of 1 files at r8. Reviewable status: :shipit: complete! all files reviewed, all discussions resolved

4a6f656c

comment created time in a month

push event4a6f656c/tlsfuzzer

Joel Sing

commit sha 7201dadde7c5264f6a5ba2f96f533b91bb0add81

Add a TLSv1.3 test that ensures a zero content type is handled correctly. In TLSv1.3, once record protection has been engaged, all records are sent as application data records on the wire, with the real content type being added to the end of the plaintext record, followed by optional zero-byte padding. If the content type is zero (the plaintext consists only of bytes with value zero) then an unexpected message alert must be sent. Updates #355

view details

push time in a month

issue commentgolang/go

all: add openbsd/mips64 port

Thanks for making this tracking issue @4a6f656c.

The first entry under https://golang.org/wiki/PortingPolicy#requirements-for-a-new-port is:

Before any code relating to a port can be added to the main Go repository, the following must all be done:

  • A proposal must be filed and accepted in which the Go team accepts overall responsibility for having the new port in the core Go tree. In general, each new port carries an upkeep cost separate from the direct maintenance. That cost varies by port, depending on how similar a new port is to existing ones. The cost must be balanced by an overall benefit in the form of potential new users or use cases for Go.

I'm asking because I can't find an answer in this issue, but has a proposal been already filed, or is that a future task? Or was the intention to use this issue as a proposal?

@dmitshur

I was not aware that a proposal was a requirement (obviously this is a relatively new addition to that page and not something I've done for the other eight Go ports that I've authored and/or upstreamed :). As an aside, it would be good if these requirements are going to be enforced then it be done consistently (for example, code exists in the Go 1.15 release for an incomplete port), not to mention that it can take multiple months just to get a builder key...

That said, we might as well use this issue as the proposal (unless you prefer/require a separate one):

  • OpenBSD runs on octeon hardware, which is mips64 based - being able to use Go and run Go based software on this platform would be beneficial.

  • The Go toolchain already supports mips64 and are there existing OpenBSD ports (386, amd64, arm, arm64) - as such, the code requirement for this port is minimal (effectively openbsd/mips64 specific runtime, syscall glue).

  • This platform is big endian, strict alignment and has large physical pages - various aspects of this find bugs in code and have already identified bugs in the Go codebase (fixes for which I'll upstream if/when the port lands).

  • Code for this port exists and passes all tests on Go 1.15.

Please let me know if further details are required.

4a6f656c

comment created time in a month

push event4a6f656c/tlsfuzzer

Alexander Sosedkin

commit sha c2fe42e08b683ef64fd203825ae2fb9dd9ec2bbe

fixup ordered_dict for Python 3.9

view details

Alexander Sosedkin

commit sha cbc6384ebaf72562a94555bb2be53862c3e6b03a

travis: add 3.9-dev and nightly python

view details

Hubert Kario

commit sha cd8190d2e821828cc6f015cd5b053cb395182542

Merge pull request #678 from t184256/ordered-dict-fix fixup ordered_dict for Python 3.9

view details

Hubert Kario

commit sha b2e888846d7aeaab81fd2e35a38de5be2a5f3d5f

analysis: load input data as memory mapped file To decrease the amount of memory necessary to process files, use a memory mapped file to store the individual measurements. Also make sure that conversion from csv file to a binary file happens in memory-efficient way

view details

Hubert Kario

commit sha b8380680cc0f8726725bebc0d47ddf219a502d90

analysis: reduce memory usage for the box_plot use memory mapped file for calculating the quantiles for the box plot

view details

Hubert Kario

commit sha 92cb1c4ffce3d592d1be46a59551aed66704156e

Merge pull request #693 from tomato42/low-mem-usage Lower mem usage

view details

Joel Sing

commit sha 3ff0fe7ea0d50baa187e7e8617a090051ae5df10

Merge branch 'master' into master

view details

push time in a month

pull request commenttomato42/tlsfuzzer

Add a TLSv1.3 test that ensures a zero content type is handled correctly

Reviewed 1 of 1 files at r7. Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @4a6f656c)

scripts/test-tls13-zero-content-type.py, line 259 at r6 (raw file):

Previously, 4a6f656c (Joel Sing) wrote… can send, not must send, so ExpectAlert needs to be a sibling, like in other tests

Ugh, thanks.

scripts/test-tls13-zero-content-type.py, line 296 at r6 (raw file):

Previously, 4a6f656c (Joel Sing) wrote… same here

Done.

4a6f656c

comment created time in a month

push event4a6f656c/tlsfuzzer

Joel Sing

commit sha 5862f4f48cc6bcc910eb1af9178a2c6061eb5592

NewSessionTicket is optional, alert needs to be sibling.

view details

push time in a month

pull request commenttomato42/tlsfuzzer

Add a TLSv1.3 test that ensures a zero content type is handled correctly

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @4a6f656c)

scripts/test-tls13-zero-content-type.py, line 259 at r6 (raw file):

    node = node.add_child(RawMessageGenerator(content_type=0, data=bytearray(0)))

    node = node.add_child(ExpectAlert(AlertLevel.fatal,

I've run the test against GnuTLS and noticed that actually the server can send a NewSessionTicket here, before an Alert: if the connection doesn't use client certificate based authentication the server can send the NewSessionTicket without waiting for Finished from client

Good catch, thanks - fixed.

scripts/test-tls13-zero-content-type.py, line 296 at r6 (raw file):

    node = node.add_child(RawMessageGenerator(content_type=0, data=bytearray(42)))

    node = node.add_child(ExpectAlert(AlertLevel.fatal,

same here

Fixed.

4a6f656c

comment created time in a month

push event4a6f656c/tlsfuzzer

Joel Sing

commit sha 0b6a00b1b9540f87c1f487ab33029b26184b6e6b

Fix NewSessionTicket ticket handling.

view details

push time in a month

push event4a6f656c/tlsfuzzer

Alexander Sosedkin

commit sha c2fe42e08b683ef64fd203825ae2fb9dd9ec2bbe

fixup ordered_dict for Python 3.9

view details

Alexander Sosedkin

commit sha cbc6384ebaf72562a94555bb2be53862c3e6b03a

travis: add 3.9-dev and nightly python

view details

Hubert Kario

commit sha cd8190d2e821828cc6f015cd5b053cb395182542

Merge pull request #678 from t184256/ordered-dict-fix fixup ordered_dict for Python 3.9

view details

Hubert Kario

commit sha b2e888846d7aeaab81fd2e35a38de5be2a5f3d5f

analysis: load input data as memory mapped file To decrease the amount of memory necessary to process files, use a memory mapped file to store the individual measurements. Also make sure that conversion from csv file to a binary file happens in memory-efficient way

view details

Hubert Kario

commit sha b8380680cc0f8726725bebc0d47ddf219a502d90

analysis: reduce memory usage for the box_plot use memory mapped file for calculating the quantiles for the box plot

view details

Hubert Kario

commit sha 92cb1c4ffce3d592d1be46a59551aed66704156e

Merge pull request #693 from tomato42/low-mem-usage Lower mem usage

view details

Joel Sing

commit sha d7b45cfa26193f55002da8f42a53a15e82cfda06

Merge branch 'master' into master

view details

push time in a month

pull request commenttomato42/tlsfuzzer

Add a TLSv1.3 test that ensures a zero content type is handled correctly

PTAL.

I'll remove the fixes - do you want an "updates" or similar for this issue?

updates #xx is fine

Done.

scripts/test-tls13-zero-content-type.py, line 34 at r1 (raw file):

version = 3

you were developing it privately before?

This was derived from test-tls13-zero-length-data.py and retained - would you prefer this be reset to 1?

yes, since it's a new script it should start with 1

Done.

scripts/test-tls13-zero-content-type.py, line 111 at r1 (raw file):

        .create(groups)
    sig_algs = [SignatureScheme.rsa_pss_rsae_sha256,
                SignatureScheme.rsa_pss_pss_sha256]

why no support for ECDSA certificates?

This is what is used in test-tls13-zero-length-data.py - can change if preferred.

please do, in general it's the test-tls13-conversation.py and test-conversation.py that are the templates for new scripts

Fixed.

scripts/test-tls13-zero-content-type.py, line 115 at r1 (raw file):

        .create(sig_algs)
    ext[ExtensionType.signature_algorithms_cert] = SignatureAlgorithmsCertExtension()\
        .create(RSA_SIG_ALL)

why limit to just RSA signatures?

This is what is done in test-tls13-zero-length-data.py - can change if preferred.

please do

Fixed.

4a6f656c

comment created time in a month

push event4a6f656c/tlsfuzzer

Joel Sing

commit sha 698187c781e758ffb60da0616500403a1319d4af

Add a TLSv1.3 test that ensures a zero content type is handled correctly. In TLSv1.3, once record protection has been engaged, all records are sent as application data records on the wire, with the real content type being added to the end of the plaintext record, followed by optional zero-byte padding. If the content type is zero (the plaintext consists only of bytes with value zero) then an unexpected message alert must be sent. Updates #355

view details

Joel Sing

commit sha d1f601f9deef78631264501e8b35ec38f4282b4f

Address review comments for test-tls13-zero-content-type.py.

view details

Joel Sing

commit sha fe4f785eed950dab7c9bcc49dc55797d714ce10a

Address additional review comments for test-tls13-zero-content-type.py.

view details

push time in a month

pull request commenttomato42/tlsfuzzer

Add a TLSv1.3 test that ensures a zero content type is handled correctly

FWIW I tried to do this on reviewable, however it requires permissions that I cannot grant it.

sorry for the delay, I was on holidays

No problem, thanks for the review.

Thanks for the PR! Looks good overall, but I have few nits for it.

Reviewed 3 of 3 files at r1. Reviewable status: all files reviewed, 6 unresolved discussions (waiting on @4a6f656c)

a discussion (no related file): Technically speaking, this script does not fix #355:

  1. it does not send empty (zero-length plaintext) messages (if only content_type is sent then the payload is 1 byte long)
  2. it does not send messages with content_type of 0 using early data (0-RTT) keys

The latter is blocked by #205, so we may split it to a new issue, but former should be doable. If you don't want to fix them, you can just remove the "fixes #355" from the PR description and commit message.

Ack. I could not see an easy way to do (1) as the RawMessageGenerator() requires a content_type and passes this through to tlslite.messages.Message - sendRecord then implicitly appends the contentType byte for TLSv1.3, hence this appears to require changes to tlslite to be able to implement. If there is something I'm missing please let me know.

I'll remove the fixes - do you want an "updates" or similar for this issue?

scripts/test-tls13-zero-content-type.py, line 34 at r1 (raw file):

version = 3

you were developing it privately before?

This was derived from test-tls13-zero-length-data.py and retained - would you prefer this be reset to 1?

scripts/test-tls13-zero-content-type.py, line 111 at r1 (raw file):

        .create(groups)
    sig_algs = [SignatureScheme.rsa_pss_rsae_sha256,
                SignatureScheme.rsa_pss_pss_sha256]

why no support for ECDSA certificates?

This is what is used in test-tls13-zero-length-data.py - can change if preferred.

scripts/test-tls13-zero-content-type.py, line 115 at r1 (raw file):

        .create(sig_algs)
    ext[ExtensionType.signature_algorithms_cert] = SignatureAlgorithmsCertExtension()\
        .create(RSA_SIG_ALL)

why limit to just RSA signatures?

This is what is done in test-tls13-zero-length-data.py - can change if preferred.

scripts/test-tls13-zero-content-type.py, line 137 at r1 (raw file):

    node = node.add_child(ExpectAlert())
    node.next_sibling = ExpectClose()

node.add_child(ExpectClose()) missing, see https://tlsfuzzer.readthedocs.io/en/latest/writing-tests.html#closing-the-connection-alternatives-in-decision-graphs

Fixed (also missing from test-tls13-zero-length-data.py - can send a follow up)

scripts/test-tls13-zero-content-type.py, line 442 at r1 (raw file):

    print("Check if handling of records with an internal content type of zero is ")
    print("correct.\n")
    print("version: {0}\n".format(version))

nit: in test-tls13-conversation.py the version is printed after "Test end"

Fixed (fwiw test-tls13-zero-length-data.py does it differently :)

4a6f656c

comment created time in a month

push event4a6f656c/tlsfuzzer

Joel Sing

commit sha cc35cf11e882f880b0eb8d08e9be686d8bcedf4e

Address review comments for test-tls13-zero-content-type.py.

view details

push time in a month

issue openedgolang/go

runtime: difficulty handling system page aligned stacks

The current runtime stack allocation is based on mheap, which uses its own fixed page size (4096 bytes). On some systems there is a requirement to have stacks be system page aligned (for example, 16KB alignment for OpenBSD/octeon). In this case, if mheap provides memory that is not 16KB aligned various things fail.

There are a couple of options to address this:

  1. Make it possible to system allocate the stacks (i.e. malloc) - this is the simplest option.

  2. Over allocate via allocManual() and round to system page alignment during stack allocation - this should not require changes to mheap, however would require changes to type stack, which would need to track the actual allocation (address and size), in addition to the lo/hi pointers (this is needed in order for stackfree() to correctly return the allocation). Two additional pointers in this struct are probably acceptable, however various assembly knows about its size and offset.

  3. Change mheap to provide system page size aligned allocations - this would be doable, but seems to require a fair amount of effort, however avoids the need to change type stack (and various assembly).

For the time being I plan on using (1) for the openbsd/mips64 port, however we may want to consider alternatives at a later date.

created time in a month

issue openedgolang/go

all: add openbsd/mips64 port

This is a tracking bug for getting an openbsd/mips64 port upstreamed - code exists for this at:

https://github.com/4a6f656c/go/tree/openbsd-mips64

created time in a month

issue commentgolang/go

x/build: add openbsd/arm builder

@andybons @dmitshur - I presume this can now be closed?

FiloSottile

comment created time in a month

issue commentgolang/go

x/build: openbsd-arm misconfigured to run x/mobile tests

@dmitshur @bcmills - I presume this can now be closed?

bcmills

comment created time in a month

issue commentgolang/go

cmd/link: SDYNIMPORT on arm results in incorrect assembly

I think CL https://go-review.googlesource.com/c/go/+/248399 fixes it.

It does indeed, thanks (I was looking at the correct line of code, but failed to spot the obvious fix!)

The disassembly now gives:

000aa2bc <main.trampoline>:
   aa2bc:       e59a1008        ldr     r1, [sl, #8]
   aa2c0:       e15d0001        cmp     sp, r1
   aa2c4:       9a000002        bls     aa2d4 <main.trampoline+0x18>
   aa2c8:       e52de004        str     lr, [sp, #-4]!
   aa2cc:       eb000008        bl      aa2f4 <runtime.etext+0x14>
   aa2d0:       e49df004        ldr     pc, [sp], #4
   aa2d4:       e1a0300e        mov     r3, lr
   aa2d8:       ebff1025        bl      6e374 <runtime.morestack_noctxt>
   aa2dc:       eafffff6        b       aa2bc <main.trampoline>

And executes correctly.

It is related to issue #19811, which I really hate...

Indeed, that is quite ugly and error prone.

4a6f656c

comment created time in a month

issue commentgolang/go

cmd/link: SDYNIMPORT on arm results in incorrect assembly

Is this new on tip (with the merge of the new linker), or it was wrong before as well?

I should have mentioned that this is the same with 1.13.9, so I do not believe it is a regression.

As cgo_import_dynamic is not user-facing, if it is not currently used by the runtime it is not surprising that it doesn't work.

Is it for ARM (32-bit) or ARM64? I saw both mentioned in the original post. (The disassembly looks like ARM32.)

Apologies - that should have been ARM32 (GOARCH=arm) (fixed).

4a6f656c

comment created time in a month

issue openedgolang/go

cmd/link: SDYNIMPORT on arm results in incorrect assembly

What version of Go are you using (go version)?

<pre> $ go version go version devel +7d7bd5abc7 Thu Aug 13 15:22:41 2020 +0000 openbsd/amd64 </pre>

What did you do?

Building the following code for openbsd/arm (and presumably any ELF GOARCH=arm):

<pre> $ cat x.go package main

import ( _ "unsafe" )

//go:cgo_import_dynamic libc_getpid getpid "libc.so"

//go:linkname libc_getpid libc_getpid

func trampoline()

func main() { trampoline() } $ cat x.s TEXT ·trampoline(SB),0,$0 CALL libc_getpid(SB) RET

$ GOARCH=arm64 GOOS=openbsd go build </pre>

Results in a binary that decompiles to the following assembly:

<pre> ... 0006a790 <main.main>: 6a790: e59a1008 ldr r1, [sl, #8] 6a794: e15d0001 cmp sp, r1 6a798: 9a000002 bls 6a7a8 <main.main+0x18> 6a79c: e52de004 str lr, [sp, #-4]! 6a7a0: eb000003 bl 6a7b4 <main.trampoline> 6a7a4: e49df004 ldr pc, [sp], #4 6a7a8: e1a0300e mov r3, lr 6a7ac: ebfff097 bl 66a10 <runtime.morestack_noctxt> 6a7b0: eafffff6 b 6a790 <main.main>

0006a7b4 <main.trampoline>: 6a7b4: e59a1008 ldr r1, [sl, #8] 6a7b8: e15d0001 cmp sp, r1 6a7bc: 9a000002 bls 6a7cc <main.trampoline+0x18> 6a7c0: e52de004 str lr, [sp, #-4]! 6a7c4: 00000019 andeq r0, r0, r9, lsl r0 6a7c8: e49df004 ldr pc, [sp], #4 6a7cc: e1a0300e mov r3, lr 6a7d0: ebfff08e bl 66a10 <runtime.morestack_noctxt> 6a7d4: eafffff6 b 6a7b4 <main.trampoline> Disassembly of section .plt:

0006a7d8 <.plt>: 6a7d8: e52de004 str lr, [sp, #-4]! 6a7dc: e59fe004 ldr lr, [pc, #4] ; 6a7e8 <runtime.etext+0x10> 6a7e0: e08fe00e add lr, pc, lr 6a7e4: e5bef008 ldr pc, [lr, #8]! 6a7e8: 00065838 andeq r5, r6, r8, lsr r8 6a7ec: e28fc600 add ip, pc, #0 ; 0x0 6a7f0: e28cca65 add ip, ip, #413696 ; 0x65000 6a7f4: e5bcf838 ldr pc, [ip, #2104]! </pre>

In particular, note that the main.trampoline function contains an andeq instruction where a bl instruction would be expected. What I believe is happening is that the CALL is being replaced with a PLT and my current guess is that the actual instruction opcode is either not being included or is being being wiped in the process.

created time in a month

PR opened tomato42/tlsfuzzer

Add a TLSv1.3 test that ensures a zero content type is handled correctly

Description

<!-- Describe your changes in detail below -->

In TLSv1.3, once record protection has been engaged, all records are sent as application data records on the wire, with the real content type being added to the end of the plaintext record, followed by optional zero-byte padding. If the content type is zero (the plaintext consists only of bytes with value zero) then an unexpected message alert must be sent.

Motivation and Context

<!-- Describe why the change is introduced, if it solves an issue add "fixes #1" with a correct number -->

Fixes #355

Checklist

<!-- go over following points. check them with an x if they do apply, (they turn into clickable checkboxes once the PR is submitted, so no need to do everything at once)

if you're unsure about any of those items, just ask in comment to PR

if the PR resolves an issue, please add further checkboxes that describe the action items or test scenarios from it -->

  • [x] I have read the CONTRIBUTING.md document and my PR follows change requirements therein
  • [ ] the changes are also reflected in documentation and code comments
  • [ ] all new and existing tests pass (see Travis CI results)
  • [ ] test script checklist was followed for new scripts
  • [x] new test script added to tlslite-ng.json and tlslite-ng-random-subset.json
  • [ ] new and modified scripts were ran against popular TLS implementations:
    • [x] OpenSSL
    • [ ] NSS
    • [ ] GnuTLS
  • [ ] required version of tlslite-ng updated in requirements.txt and README.md
+466 -0

0 comment

3 changed files

pr created time in a month

push event4a6f656c/tlsfuzzer

Joel Sing

commit sha a69342d22c3ea49294c8d3bdfede9a8849ebf6a2

Add a TLSv1.3 test that ensures a zero content type is handled correctly. In TLSv1.3, once record protection has been engaged, all records are sent as application data records on the wire, with the real content type being added to the end of the plaintext record, followed by optional zero-byte padding. If the content type is zero (the plaintext consists only of bytes with value zero) then an unexpected message alert must be sent. Fixes #355

view details

push time in a month

push event4a6f656c/tlsfuzzer

Joel Sing

commit sha 3b33c89a396d8284a91d762d12916f7afa7d64d4

Add a TLSv1.3 test that ensures a zero content type is handled correctly. In TLSv1.3, once record protection has been engaged, all records are sent as application data records on the wire, with the real content type being added to the end of the plaintext record, followed by optional zero-byte padding. If the content type is zero (the plaintext consists only of bytes with value zero) then an unexpected message alert must be sent. Fixes #355

view details

push time in a month

fork 4a6f656c/tlsfuzzer

SSL and TLS protocol test suite and fuzzer

fork in a month

issue commentlibressl-portable/portable

v3.1.0 breaks OpenSSH

@leonklingele - any update here?

Seems potentially related to https://github.com/libressl-portable/portable/issues/603.

leonklingele

comment created time in 2 months

issue commentlibressl-portable/portable

Libressl 3.1.3 force TLS1.3 and doesn't fallback to TLS1.2

We finally tracked down the issue when talking to ProtonVPN - it would appear that they require TLSv1.3 clients to use P-521 for key exchange - this group is not enabled by default in LibreSSL (but is in OpenSSL). While I understand their reasons in making P-521 their preferred group, not providing any other lower preference options makes interoperability difficult (they seem to do the same by only allowing a single TLSv1.3 cipher suite). Unfortunately OpenVPN releases do not provide anyway for the TLS groups to be configured (a tls-groups configuration option was added to their repo a few days ago).

There are currently a few workarounds:

  • Use tls-version-max: 1.2 to force TLSv1.2 instead of TLSv1.3.
  • Use a version of OpenVPN that supports tls-groups and configure it with tls-groups: P-521.

We're also discussing options from the LibreSSL side.

With the logs provided above, there seems to be a separate issue which is likely related to the use of ECDSA client certificates - we'll likely have this addressed in an upcoming LibreSSL 3.1.4 release.

jkoderu-git

comment created time in 2 months

issue commentProtonVPN/linux-cli

Suddenly can't connect to servers after system update. (Problem with LibreSSL vs OpenSSL)

@tegan-lamoureux - I believe the issue is due to the fact that ProtonVPN is requiring P-521 for TLSv1.3 key exchange (they could allow P-384 as a lower preference, which would allow TLSv1.3 to succeed). This is not a group that is enabled by default in LibreSSL and OpenVPN releases do not provide a way to configure supported groups (there is a tls-groups option that was added to OpenVPN a few days ago). In the interim, a workaround is to use tls-version-max 1.2 which will force TLSv1.2 instead of attempting TLSv1.3 negotiation (and failing).

@Rafficer - AEAD-AES256-GCM-SHA384 (aka TLS_AES_256_GCM_SHA384) is present but OpenVPN does not currently know about it (openssl ciphers -v does however).

tegan-lamoureux

comment created time in 2 months

issue commentgoogle/seesaw

UDP Round Robin Only going to single server

Any ideas why?

By default IPVS will track flows and persist each flow (source IP, destination IP, protocol, source port, destination port) to a single backend - often spreading a flow across multiple backends will result in unwanted behaviour/problems (in the case of UDP think video streaming, VoIP calls, etc). As noted, it is likely that your application is using the same source port for all traffic, resulting in what appears to be a single flow (hence being sent to a single backend).

In cases where it is known that the UDP traffic is per packet and that you can safely send each UDP datagram to a different backend (think DNS requests), you can enable "one packet scheduling" (or OPS). This can be enabled on a Seesaw vserver_entry by adding one_packet: true to the configuration.

DefenceLogic

comment created time in 2 months

issue commentgolang/go

all: stop using direct syscalls on OpenBSD

Does that mean Go will always use dynamic linking or raw syscalls will still be used when linking statically?

Go will always use dynamic linking (and possibly always external linking) - it would be a significant amount of effort to maintain both libc based syscalls and raw syscalls and switch between to two. Any Go binary on OpenBSD that pulls in the net package is already going to result in a dynamic cgo-based binary (unless cgo is explicitly disabled - see #36435 (comment)).

Actually, there is another thing that I need to investigate - in many cases we should be able to statically link against libc.a, which would actually allow us to produce static Go binaries in more cases then we currently do on OpenBSD.

4a6f656c

comment created time in 2 months

push event4a6f656c/go

fanzha02

commit sha 71d477469c5529b56779cdb3bc235d0a87fe9877

cmd/asm: align an instruction or a function's address Recently, the gVisor project needs an instruction's address with 128 bytes alignment and a function's start address with 2K bytes alignment to fit the architecture requirement for interrupt table. This patch allows aligning the address of an instruction to be aligned to a specific value (2^n and not higher than 2048) and the address of a function to be 2048 bytes. The main changes include: 1. Adds ALIGN2048 flag to align a function's address with 2048 bytes. e.g. "TEXT ·Add(SB),NOSPLIT|ALIGN2048" indicates that the address of Add function should be aligned to 2048 bytes. 2. Adds a new element in the FuncInfo structure defined in cmd/internal/obj/link.go file to record the alignment information. 3. Adds a new element in the Func structure defined in cmd/internal/goobj/read.go file to read the alignment information. 4. Because go introduces a new object file format, also add a new element in the FuncInfo structure defined in cmd/internal/goobj2/funcinfo.go to record the alignment information. 5. Adds the assembler support to align an intruction's offset with a specific value (2^n and not higher than 2048). e.g. "PCALIGN $256" indicates that the next instruction should be aligned to 256 bytes. This CL also adds a test. Change-Id: I31cfa6fb5bc35dee2c44bf65913e90cddfcb492a Reviewed-on: https://go-review.googlesource.com/c/go/+/212767 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Ian Lance Taylor

commit sha d98023ebb5c2db9a445699b690f2cf6fd77f4b7e

runtime, internal/poll: name error codes Use explicit names for the error code returned by pollReset and pollWait, rather than just 0, 1, 2, 3. Change-Id: I0ab12cae57693deab7cca9cdd2fadd597e23a956 Reviewed-on: https://go-review.googlesource.com/c/go/+/226537 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

view details

Joel Sing

commit sha a3d8c210ad7d6dea9996200fc1596c310b9775b5

cmd/asm,cmd/internal/obj/riscv: provide branch pseudo-instructions Implement various branch pseudo-instructions for riscv64. These make it easier to read/write assembly and will also make it easier for the compiler to generate optimised code. Change-Id: Ic31a7748c0e1495522ebecf34b440842b8d12c04 Reviewed-on: https://go-review.googlesource.com/c/go/+/226397 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Cherry Zhang

commit sha 721716ca1cfac23787aa3c722a8eecd9a0d5b296

[dev.link] cmd/link: set attributes atomically Now concurrent relocsym may access symbols attributes concurrently, causing data race when using the race detector. I think it is still safe as we read/write on different bits, and not write the same symbol's attributes from multiple goroutines, so it will always reads the right value regardless whether the write happens before or after, as long as the memory model is not so insane. Use atomic accesses to appease the race detector. It doesn't seem to cost much, at least on x86. Change-Id: I2bfc3755ee59c87ed237d508f29d6172fa976392 Reviewed-on: https://go-review.googlesource.com/c/go/+/226368 Reviewed-by: Austin Clements <austin@google.com>

view details

Bryan C. Mills

commit sha 5970480c68fc7ecb6eaf3a5f90f49ae4504fa060

Revert "cmd/asm: align an instruction or a function's address" This reverts CL 212767. Reason for revert: new test is persistently failing on freebsd-arm64-dmgk builder. Change-Id: Ifd1227628e0e747688ddb4dc580170b2a103a89e Reviewed-on: https://go-review.googlesource.com/c/go/+/226597 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Roland Shoemaker

commit sha 5db079d2e5f97952be288c28a3a0690a523efdce

crypto/rsa: reject invalid length PKCS#1v1.5 signatures Per RFC 8017, reject signatures which are not the same length as the RSA modulus. This matches the behavior of SignPKCS1v15 which properly left pads the signatures it generates to the size of the modulus. Fixes #21896 Change-Id: I2c42a0b24cf7fff158ece604b6f0c521a856d932 GitHub-Last-Rev: 6040f7990633630a0ad157cb17e016bb7db98a27 GitHub-Pull-Request: golang/go#38140 Reviewed-on: https://go-review.googlesource.com/c/go/+/226203 Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Bryan C. Mills

commit sha 5d2ddcd3f51c1ff7aa0a84604b1d8610a17a7933

context: fix a flaky timeout in TestLayersTimeout In CL 223019, I reduced the short timeout in the testLayers helper to be even shorter than it was. That exposed a racy (time-dependent) select later in the function, which failed in one of the slower builders (android-386-emu). Also streamline the test to make it easier to test with a very high -count flag: - Run tests that sleep for shortDuration in parallel to reduce latency. - Use shorter durations in examples to reduce test running time. - Avoid mutating global state (in package math/rand) in testLayers. After this change (but not before it), 'go test -run=TestLayersTimeout -count=100000 context' passes on my workstation. Fixes #38161 Change-Id: Iaf4abe7ac308b2100d8828267cda9f4f8ae4be82 Reviewed-on: https://go-review.googlesource.com/c/go/+/226457 Reviewed-by: Ian Lance Taylor <iant@golang.org>

view details

Bryan C. Mills

commit sha 2d77d3330537e11a0d9a233ba5f4facf262e9d8c

net/http: treat a nil Body from a custom RoundTripper as an empty one Fixes #38095 Change-Id: I4f65ce01e7aed22240eee979c41535d0b8b9a8dc Reviewed-on: https://go-review.googlesource.com/c/go/+/225717 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>

view details

Richard Miller

commit sha 2cb80bdee0dcb4ff55f46ab7025a37546aef6b7a

runtime: skip gdb tests on Plan 9 There's no gdb on Plan 9. Change-Id: Ibeb0fbd3c096a69181c19b1fb2bc6291612b6da3 Reviewed-on: https://go-review.googlesource.com/c/go/+/226657 Reviewed-by: David du Colombier <0intro@gmail.com>

view details

Bryan C. Mills

commit sha 3ff9c4f2a6670edaee3962571ef6241c1bfcc2fc

os/signal: make TestStop resilient to initially-blocked signals For reasons unknown, SIGUSR1 appears to be blocked at process start for tests on the android-arm-corellium and android-arm64-corellium builders. (This has been observed before, too: see CL 203957.) Make the test resilient to blocked signals by always calling Notify and waiting for potential signal delivery after sending any signal that is not known to be unblocked. Also remove the initial SIGWINCH signal from testCancel. The behavior of an unhandled SIGWINCH is already tested in TestStop, so we don't need to re-test that same case: waiting for an unhandled signal takes a comparatively long time (because we necessarily don't know when it has been delivered), so this redundancy makes the overall test binary needlessly slow, especially since it is called from both TestReset and TestIgnore. Since each signal is always unblocked while we have a notification channel registered for it, we don't need to modify any other tests: TestStop and testCancel are the only functions that send signals without a registered channel. Fixes #38165 Updates #33174 Updates #15661 Change-Id: I215880894e954b62166024085050d34323431b63 Reviewed-on: https://go-review.googlesource.com/c/go/+/226461 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Jay Conrod

commit sha faa53e17d1c91d97aa2b780ac41190d151aa6b0e

cmd/go: add support for GOPROXY fallback on unexpected errors URLs in GOPROXY may now be separated with commas (,) or pipes (|). If a request to a proxy fails with any error (including connection errors and timeouts) and the proxy URL is followed by a pipe, the go command will try the request with the next proxy in the list. If the proxy is followed by a comma, the go command will only try the next proxy if the error a 404 or 410 HTTP response. The go command will determine how to connect to the checksum database using the same logic. Before accessing the checksum database, the go command sends a request to <proxyURL>/sumdb/<sumdb-name>/supported. If a proxy responds with 404 or 410, or if any other error occurs and the proxy URL in GOPROXY is followed by a pipe, the go command will try the request with the next proxy. If all proxies respond with 404 or 410 or are configured to fall back on errors, the go command will connect to the checksum database directly. This CL does not change the default value or meaning of GOPROXY. Fixes #37367 Change-Id: I35dd218823fe8cb9383e9ac7bbfec2cc8a358748 Reviewed-on: https://go-review.googlesource.com/c/go/+/226460 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>

view details

Cherry Zhang

commit sha aef23f5be9c76c608562e4607dc707a07360526a

[dev.link] cmd/link: fix end-of-block padding Make sure we write the entire address range we are asked to write, with no holes between the blocks or at the end. Should fix NetBSD build. Change-Id: I13b1f551377cbc4bcde3650417ac95cba62ff807 Reviewed-on: https://go-review.googlesource.com/c/go/+/226617 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org>

view details

Matthew Dempsky

commit sha 34314280e46da1558bc7f9cd7e8a9ed610cf417b

cmd/compile: fix constant conversion involving complex types In CL 187657, I refactored constant conversion logic without realizing that conversions between int/float and complex types are allowed for constants (assuming the constant values are representable by the destination type), but are never allowed for non-constant expressions. This CL expands convertop to take an extra srcConstant parameter to indicate whether the source expression is a constant; and if so, to allow any numeric-to-numeric conversion. (Conversions of values that cannot be represented in the destination type are rejected by evconst.) Fixes #38117. Change-Id: Id7077d749a14c8fd910be38da170fa5254819f2b Reviewed-on: https://go-review.googlesource.com/c/go/+/226197 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>

view details

Josh Bleecher Snyder

commit sha 8114242359a32dbbfe44cf6cc83c48cca7d6c126

cmd/compile, runtime: use more registers for amd64 write barrier calls The compiler-inserted write barrier calls use a special ABI for speed and to minimize the binary size impact. runtime.gcWriteBarrier takes its args in DI and AX. This change adds gcWriteBarrier wrapper functions, varying only in the register used for the second argument. (Allowing variation in the first argument doesn't offer improvements, which is convenient, as it avoids quadratic API growth.) This reduces the number of register copies. The goals are reduced binary size via reduced register pressure/copies. One downside to this change is that when the write barrier is on, we may bounce through several different write barrier wrappers, which is bad for the instruction cache. Package runtime write barrier benchmarks for this change: name old time/op new time/op delta WriteBarrier-8 16.6ns ± 6% 15.6ns ± 6% -5.73% (p=0.000 n=97+99) BulkWriteBarrier-8 4.37ns ± 7% 4.22ns ± 8% -3.45% (p=0.000 n=96+99) However, I don't particularly trust these numbers. I ran runtime.BenchmarkWriteBarrier multiple times as I rebased this change, and noticed that the results have high variance depending on the parent change, perhaps due to aligment. This change was stress tested with GOGC=1 GODEBUG=gccheckmark=1 go test std. This change reduces binary sizes: file before after Δ % addr2line 4308720 4296688 -12032 -0.279% api 5965592 5945368 -20224 -0.339% asm 5148088 5025464 -122624 -2.382% buildid 2848760 2844904 -3856 -0.135% cgo 4828968 4812840 -16128 -0.334% compile 19754720 19529744 -224976 -1.139% cover 5256840 5236600 -20240 -0.385% dist 3670312 3658264 -12048 -0.328% doc 4669608 4657576 -12032 -0.258% fix 3377976 3365944 -12032 -0.356% link 6614888 6586472 -28416 -0.430% nm 4258368 4254528 -3840 -0.090% objdump 4656336 4644304 -12032 -0.258% pack 2295176 2295432 +256 +0.011% pprof 14762356 14709364 -52992 -0.359% test2json 2824456 2820600 -3856 -0.137% trace 11684404 11643700 -40704 -0.348% vet 8284760 8252248 -32512 -0.392% total 115210328 114580040 -630288 -0.547% This change improves compiler performance: name old time/op new time/op delta Template 208ms ± 3% 207ms ± 3% -0.40% (p=0.030 n=43+44) Unicode 80.2ms ± 3% 81.3ms ± 3% +1.25% (p=0.000 n=41+44) GoTypes 699ms ± 3% 694ms ± 2% -0.71% (p=0.016 n=42+37) Compiler 3.26s ± 2% 3.23s ± 2% -0.86% (p=0.000 n=43+45) SSA 6.97s ± 1% 6.93s ± 1% -0.63% (p=0.000 n=43+45) Flate 134ms ± 3% 133ms ± 2% ~ (p=0.139 n=45+42) GoParser 165ms ± 2% 164ms ± 1% -0.79% (p=0.000 n=45+40) Reflect 434ms ± 4% 435ms ± 4% ~ (p=0.937 n=44+44) Tar 181ms ± 2% 181ms ± 2% ~ (p=0.702 n=43+45) XML 244ms ± 2% 244ms ± 2% ~ (p=0.237 n=45+44) [Geo mean] 403ms 402ms -0.29% name old user-time/op new user-time/op delta Template 271ms ± 2% 268ms ± 1% -1.40% (p=0.000 n=42+42) Unicode 117ms ± 3% 116ms ± 5% ~ (p=0.066 n=45+45) GoTypes 948ms ± 2% 936ms ± 2% -1.30% (p=0.000 n=41+40) Compiler 4.26s ± 1% 4.21s ± 2% -1.25% (p=0.000 n=37+45) SSA 9.52s ± 2% 9.41s ± 1% -1.18% (p=0.000 n=44+45) Flate 167ms ± 2% 165ms ± 2% -1.15% (p=0.000 n=44+41) GoParser 201ms ± 2% 198ms ± 1% -1.40% (p=0.000 n=43+43) Reflect 563ms ± 8% 560ms ± 7% ~ (p=0.206 n=45+44) Tar 224ms ± 2% 222ms ± 2% -0.81% (p=0.000 n=45+45) XML 308ms ± 2% 304ms ± 1% -1.17% (p=0.000 n=42+43) [Geo mean] 525ms 519ms -1.08% name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.3MB ± 0% ~ (p=0.421 n=5+5) Unicode 28.4MB ± 0% 28.3MB ± 0% ~ (p=0.056 n=5+5) GoTypes 121MB ± 0% 121MB ± 0% -0.14% (p=0.008 n=5+5) Compiler 567MB ± 0% 567MB ± 0% -0.06% (p=0.016 n=4+5) SSA 1.26GB ± 0% 1.26GB ± 0% -0.07% (p=0.008 n=5+5) Flate 22.9MB ± 0% 22.8MB ± 0% ~ (p=0.310 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.09% (p=0.008 n=5+5) Reflect 78.4MB ± 0% 78.4MB ± 0% -0.03% (p=0.008 n=5+5) Tar 34.2MB ± 0% 34.2MB ± 0% -0.05% (p=0.008 n=5+5) XML 44.4MB ± 0% 44.4MB ± 0% -0.04% (p=0.016 n=5+5) [Geo mean] 76.4MB 76.3MB -0.05% name old allocs/op new allocs/op delta Template 356k ± 0% 356k ± 0% -0.13% (p=0.008 n=5+5) Unicode 326k ± 0% 326k ± 0% -0.07% (p=0.008 n=5+5) GoTypes 1.24M ± 0% 1.24M ± 0% -0.24% (p=0.008 n=5+5) Compiler 5.30M ± 0% 5.28M ± 0% -0.34% (p=0.008 n=5+5) SSA 11.9M ± 0% 11.9M ± 0% -0.16% (p=0.008 n=5+5) Flate 226k ± 0% 225k ± 0% -0.12% (p=0.008 n=5+5) GoParser 287k ± 0% 286k ± 0% -0.29% (p=0.008 n=5+5) Reflect 930k ± 0% 929k ± 0% -0.05% (p=0.008 n=5+5) Tar 332k ± 0% 331k ± 0% -0.12% (p=0.008 n=5+5) XML 411k ± 0% 411k ± 0% -0.12% (p=0.008 n=5+5) [Geo mean] 771k 770k -0.16% For some packages, this change significantly reduces the size of executable text. Examples: file before after Δ % cmd/internal/obj/arm.s 68658 66855 -1803 -2.626% cmd/internal/obj/mips.s 57486 56272 -1214 -2.112% cmd/internal/obj/arm64.s 152107 147163 -4944 -3.250% cmd/internal/obj/ppc64.s 125544 120456 -5088 -4.053% cmd/vendor/golang.org/x/tools/go/cfg.s 31699 30742 -957 -3.019% Full listing: file before after Δ % container/ring.s 1890 1870 -20 -1.058% container/list.s 5366 5390 +24 +0.447% internal/cpu.s 3298 3295 -3 -0.091% internal/testlog.s 1507 1501 -6 -0.398% image/color.s 8281 8248 -33 -0.399% runtime.s 480970 480075 -895 -0.186% sync.s 16497 16408 -89 -0.539% internal/singleflight.s 2591 2577 -14 -0.540% math/rand.s 10456 10438 -18 -0.172% cmd/go/internal/par.s 2801 2790 -11 -0.393% internal/reflectlite.s 28477 28417 -60 -0.211% errors.s 2750 2736 -14 -0.509% internal/oserror.s 446 434 -12 -2.691% sort.s 17061 17046 -15 -0.088% io.s 17063 16999 -64 -0.375% vendor/golang.org/x/crypto/hkdf.s 1962 1936 -26 -1.325% text/tabwriter.s 9617 9574 -43 -0.447% hash/crc64.s 3414 3408 -6 -0.176% hash/crc32.s 6657 6651 -6 -0.090% bytes.s 31932 31863 -69 -0.216% strconv.s 53158 52799 -359 -0.675% strings.s 42829 42665 -164 -0.383% encoding/ascii85.s 4833 4791 -42 -0.869% vendor/golang.org/x/text/transform.s 16810 16724 -86 -0.512% path.s 6848 6845 -3 -0.044% encoding/base32.s 9658 9592 -66 -0.683% bufio.s 23051 22908 -143 -0.620% compress/bzip2.s 11773 11764 -9 -0.076% image.s 37565 37502 -63 -0.168% syscall.s 82359 82279 -80 -0.097% regexp/syntax.s 83573 82930 -643 -0.769% image/jpeg.s 36535 36490 -45 -0.123% regexp.s 64396 64214 -182 -0.283% time.s 82724 82622 -102 -0.123% plugin.s 6539 6536 -3 -0.046% context.s 10959 10865 -94 -0.858% internal/poll.s 24286 24270 -16 -0.066% reflect.s 168304 167927 -377 -0.224% internal/fmtsort.s 7416 7376 -40 -0.539% os.s 52465 51787 -678 -1.292% cmd/go/internal/lockedfile/internal/filelock.s 2326 2317 -9 -0.387% os/signal.s 4657 4648 -9 -0.193% runtime/debug.s 6040 5998 -42 -0.695% encoding/binary.s 30838 30801 -37 -0.120% vendor/golang.org/x/net/route.s 23694 23491 -203 -0.857% path/filepath.s 17895 17889 -6 -0.034% cmd/vendor/golang.org/x/sys/unix.s 78125 78109 -16 -0.020% io/ioutil.s 6999 6996 -3 -0.043% encoding/base64.s 12094 12007 -87 -0.719% crypto/cipher.s 20466 20372 -94 -0.459% cmd/go/internal/robustio.s 2672 2669 -3 -0.112% encoding/pem.s 9302 9286 -16 -0.172% internal/obscuretestdata.s 1719 1695 -24 -1.396% crypto/aes.s 11014 11002 -12 -0.109% os/exec.s 29388 29231 -157 -0.534% cmd/internal/browser.s 2266 2260 -6 -0.265% internal/goroot.s 4601 4592 -9 -0.196% vendor/golang.org/x/crypto/chacha20poly1305.s 8945 8942 -3 -0.034% cmd/vendor/golang.org/x/crypto/ssh/terminal.s 27226 27195 -31 -0.114% index/suffixarray.s 36431 36411 -20 -0.055% fmt.s 77017 76709 -308 -0.400% encoding/hex.s 6241 6154 -87 -1.394% compress/lzw.s 7133 7069 -64 -0.897% database/sql/driver.s 18888 18877 -11 -0.058% net/url.s 29838 29739 -99 -0.332% debug/plan9obj.s 8329 8279 -50 -0.600% encoding/csv.s 12986 12902 -84 -0.647% debug/gosym.s 25403 25330 -73 -0.287% compress/flate.s 51192 50970 -222 -0.434% vendor/golang.org/x/net/dns/dnsmessage.s 86769 86208 -561 -0.647% compress/gzip.s 9791 9758 -33 -0.337% compress/zlib.s 7310 7277 -33 -0.451% archive/zip.s 42356 42166 -190 -0.449% debug/dwarf.s 108259 107730 -529 -0.489% encoding/json.s 106378 105910 -468 -0.440% os/user.s 14751 14724 -27 -0.183% database/sql.s 99011 98404 -607 -0.613% log.s 9466 9423 -43 -0.454% debug/pe.s 31272 31182 -90 -0.288% debug/macho.s 32764 32608 -156 -0.476% encoding/gob.s 136976 136517 -459 -0.335% vendor/golang.org/x/text/unicode/bidi.s 27318 27276 -42 -0.154% archive/tar.s 71416 70975 -441 -0.618% vendor/golang.org/x/net/http2/hpack.s 23892 23848 -44 -0.184% vendor/golang.org/x/text/secure/bidirule.s 3354 3351 -3 -0.089% mime/quotedprintable.s 5960 5925 -35 -0.587% net/http/internal.s 5874 5853 -21 -0.358% math/big.s 184147 183692 -455 -0.247% debug/elf.s 63775 63567 -208 -0.326% mime.s 39802 39709 -93 -0.234% encoding/xml.s 111038 110713 -325 -0.293% crypto/dsa.s 6044 6029 -15 -0.248% go/token.s 12139 12077 -62 -0.511% crypto/rand.s 6889 6866 -23 -0.334% go/scanner.s 19030 19008 -22 -0.116% flag.s 22320 22236 -84 -0.376% vendor/golang.org/x/text/unicode/norm.s 66652 66391 -261 -0.392% crypto/rsa.s 31671 31650 -21 -0.066% crypto/elliptic.s 51553 51403 -150 -0.291% internal/xcoff.s 22950 22822 -128 -0.558% go/constant.s 43750 43689 -61 -0.139% encoding/asn1.s 57086 57035 -51 -0.089% runtime/trace.s 2609 2603 -6 -0.230% crypto/x509/pkix.s 10458 10471 +13 +0.124% image/gif.s 27544 27385 -159 -0.577% vendor/golang.org/x/net/idna.s 24558 24502 -56 -0.228% image/png.s 42775 42685 -90 -0.210% vendor/golang.org/x/crypto/cryptobyte.s 33616 33493 -123 -0.366% go/ast.s 80684 80449 -235 -0.291% net/internal/socktest.s 16571 16535 -36 -0.217% crypto/ecdsa.s 11948 11936 -12 -0.100% text/template/parse.s 95138 94002 -1136 -1.194% runtime/pprof.s 59702 59639 -63 -0.106% testing.s 68427 68088 -339 -0.495% internal/testenv.s 5620 5596 -24 -0.427% testing/internal/testdeps.s 3312 3294 -18 -0.543% internal/trace.s 78473 78239 -234 -0.298% testing/iotest.s 4968 4908 -60 -1.208% os/signal/internal/pty.s 3011 2990 -21 -0.697% testing/quick.s 12179 12125 -54 -0.443% cmd/internal/bio.s 9286 9274 -12 -0.129% cmd/internal/src.s 17684 17663 -21 -0.119% cmd/internal/goobj2.s 12588 12558 -30 -0.238% cmd/internal/objabi.s 16408 16390 -18 -0.110% go/printer.s 77417 77308 -109 -0.141% go/parser.s 80045 79113 -932 -1.164% go/format.s 5434 5419 -15 -0.276% cmd/internal/goobj.s 26146 25954 -192 -0.734% runtime/pprof/internal/profile.s 102518 102178 -340 -0.332% text/template.s 95343 94935 -408 -0.428% cmd/internal/dwarf.s 31718 31572 -146 -0.460% cmd/vendor/golang.org/x/arch/arm/armasm.s 45240 45151 -89 -0.197% internal/lazytemplate.s 1470 1457 -13 -0.884% cmd/vendor/golang.org/x/arch/ppc64/ppc64asm.s 37253 37220 -33 -0.089% cmd/asm/internal/flags.s 2593 2590 -3 -0.116% cmd/asm/internal/lex.s 25068 24921 -147 -0.586% cmd/internal/buildid.s 18536 18263 -273 -1.473% cmd/vendor/golang.org/x/arch/x86/x86asm.s 80209 80105 -104 -0.130% go/doc.s 75140 74585 -555 -0.739% cmd/internal/edit.s 3893 3899 +6 +0.154% html/template.s 89377 88809 -568 -0.636% cmd/vendor/golang.org/x/arch/arm64/arm64asm.s 117998 117824 -174 -0.147% cmd/internal/obj.s 115015 114290 -725 -0.630% go/build.s 69379 68862 -517 -0.745% cmd/internal/objfile.s 48106 47982 -124 -0.258% cmd/cover.s 46239 46113 -126 -0.272% cmd/addr2line.s 2845 2833 -12 -0.422% cmd/internal/obj/arm.s 68658 66855 -1803 -2.626% cmd/internal/obj/mips.s 57486 56272 -1214 -2.112% cmd/internal/obj/riscv.s 63834 63006 -828 -1.297% cmd/compile/internal/syntax.s 146582 145456 -1126 -0.768% cmd/internal/obj/wasm.s 44117 44066 -51 -0.116% cmd/cgo.s 242645 241653 -992 -0.409% cmd/internal/obj/arm64.s 152107 147163 -4944 -3.250% net.s 295972 292010 -3962 -1.339% go/types.s 321371 319432 -1939 -0.603% vendor/golang.org/x/net/http/httpproxy.s 9450 9423 -27 -0.286% net/textproto.s 19455 19406 -49 -0.252% cmd/internal/obj/ppc64.s 125544 120456 -5088 -4.053% go/internal/srcimporter.s 6475 6409 -66 -1.019% log/syslog.s 8017 7929 -88 -1.098% cmd/compile/internal/logopt.s 10183 10162 -21 -0.206% net/mail.s 24085 23948 -137 -0.569% mime/multipart.s 21527 21420 -107 -0.497% cmd/internal/obj/s390x.s 127610 127757 +147 +0.115% go/internal/gcimporter.s 34913 34548 -365 -1.045% vendor/golang.org/x/net/nettest.s 28103 28016 -87 -0.310% cmd/go/internal/cfg.s 9967 9916 -51 -0.512% cmd/api.s 39703 39603 -100 -0.252% go/internal/gccgoimporter.s 56470 56120 -350 -0.620% go/importer.s 2077 2056 -21 -1.011% cmd/compile/internal/types.s 48202 47282 -920 -1.909% cmd/go/internal/str.s 4341 4320 -21 -0.484% cmd/internal/obj/x86.s 89440 88625 -815 -0.911% cmd/go/internal/base.s 12667 12580 -87 -0.687% cmd/go/internal/cache.s 30754 30571 -183 -0.595% cmd/doc.s 62976 62755 -221 -0.351% cmd/go/internal/search.s 20114 19993 -121 -0.602% cmd/vendor/golang.org/x/xerrors.s 17923 17855 -68 -0.379% cmd/go/internal/lockedfile.s 16451 16415 -36 -0.219% cmd/vendor/golang.org/x/mod/sumdb/note.s 18200 18150 -50 -0.275% cmd/vendor/golang.org/x/mod/module.s 17869 17851 -18 -0.101% cmd/asm/internal/arch.s 37533 37482 -51 -0.136% cmd/fix.s 87728 87492 -236 -0.269% cmd/vendor/golang.org/x/mod/sumdb/tlog.s 36394 36367 -27 -0.074% cmd/vendor/golang.org/x/mod/sumdb/dirhash.s 4990 4963 -27 -0.541% cmd/go/internal/imports.s 16499 16469 -30 -0.182% cmd/vendor/golang.org/x/mod/zip.s 18816 18745 -71 -0.377% cmd/go/internal/cmdflag.s 5126 5123 -3 -0.059% cmd/internal/test2json.s 9540 9452 -88 -0.922% cmd/go/internal/tool.s 3629 3623 -6 -0.165% cmd/go/internal/version.s 11232 11220 -12 -0.107% cmd/go/internal/mvs.s 25383 25179 -204 -0.804% cmd/nm.s 5815 5803 -12 -0.206% cmd/dist.s 210146 209140 -1006 -0.479% cmd/asm/internal/asm.s 68655 68549 -106 -0.154% cmd/vendor/golang.org/x/mod/modfile.s 72974 72510 -464 -0.636% cmd/go/internal/load.s 107548 106861 -687 -0.639% cmd/link/internal/sym.s 18708 18581 -127 -0.679% cmd/asm.s 3367 3343 -24 -0.713% cmd/gofmt.s 30795 30698 -97 -0.315% cmd/link/internal/objfile.s 21828 21630 -198 -0.907% cmd/pack.s 14878 14869 -9 -0.060% cmd/vendor/github.com/google/pprof/internal/elfexec.s 6788 6782 -6 -0.088% cmd/test2json.s 1647 1641 -6 -0.364% cmd/link/internal/loader.s 48677 48483 -194 -0.399% cmd/vendor/golang.org/x/tools/go/analysis/internal/analysisflags.s 16783 16773 -10 -0.060% cmd/link/internal/loadelf.s 35464 35126 -338 -0.953% cmd/link/internal/loadmacho.s 29438 29180 -258 -0.876% cmd/link/internal/loadpe.s 16440 16371 -69 -0.420% cmd/vendor/golang.org/x/tools/go/analysis/passes/internal/analysisutil.s 2106 2100 -6 -0.285% cmd/link/internal/loadxcoff.s 11711 11615 -96 -0.820% cmd/vendor/golang.org/x/tools/go/analysis/internal/facts.s 14954 14883 -71 -0.475% cmd/vendor/golang.org/x/tools/go/ast/inspector.s 5394 5374 -20 -0.371% cmd/vendor/golang.org/x/tools/go/analysis/passes/asmdecl.s 37029 36822 -207 -0.559% cmd/vendor/golang.org/x/tools/go/analysis/passes/inspect.s 340 337 -3 -0.882% cmd/vendor/golang.org/x/tools/go/analysis/passes/cgocall.s 9919 9858 -61 -0.615% cmd/vendor/golang.org/x/tools/go/analysis/passes/bools.s 6705 6690 -15 -0.224% cmd/vendor/golang.org/x/tools/go/analysis/passes/copylock.s 9783 9741 -42 -0.429% cmd/vendor/golang.org/x/tools/go/cfg.s 31699 30742 -957 -3.019% cmd/vendor/golang.org/x/tools/go/analysis/passes/ifaceassert.s 2768 2762 -6 -0.217% cmd/vendor/golang.org/x/tools/go/analysis/passes/loopclosure.s 3031 2998 -33 -1.089% cmd/vendor/golang.org/x/tools/go/analysis/passes/shift.s 4382 4376 -6 -0.137% cmd/vendor/golang.org/x/tools/go/analysis/passes/stdmethods.s 8654 8642 -12 -0.139% cmd/vendor/golang.org/x/tools/go/analysis/passes/stringintconv.s 3458 3446 -12 -0.347% cmd/vendor/golang.org/x/tools/go/analysis/passes/structtag.s 8011 7995 -16 -0.200% cmd/vendor/golang.org/x/tools/go/analysis/passes/tests.s 6205 6193 -12 -0.193% cmd/vendor/golang.org/x/tools/go/ast/astutil.s 66183 65861 -322 -0.487% cmd/vendor/github.com/google/pprof/profile.s 150844 150261 -583 -0.386% cmd/vendor/golang.org/x/tools/go/analysis/passes/unreachable.s 8057 8054 -3 -0.037% cmd/vendor/golang.org/x/tools/go/analysis/passes/unusedresult.s 3670 3667 -3 -0.082% cmd/vendor/github.com/google/pprof/internal/measurement.s 10464 10440 -24 -0.229% cmd/vendor/golang.org/x/tools/go/types/typeutil.s 12319 12274 -45 -0.365% cmd/vendor/golang.org/x/tools/go/analysis/unitchecker.s 13503 13342 -161 -1.192% cmd/vendor/golang.org/x/tools/go/analysis/passes/ctrlflow.s 5261 5218 -43 -0.817% cmd/vendor/golang.org/x/tools/go/analysis/passes/errorsas.s 1462 1459 -3 -0.205% cmd/vendor/golang.org/x/tools/go/analysis/passes/lostcancel.s 9594 9582 -12 -0.125% cmd/vendor/golang.org/x/tools/go/analysis/passes/printf.s 34397 34338 -59 -0.172% cmd/vendor/github.com/google/pprof/internal/graph.s 53225 52936 -289 -0.543% cmd/vendor/github.com/ianlancetaylor/demangle.s 177450 175329 -2121 -1.195% crypto/x509.s 147892 147388 -504 -0.341% cmd/go/internal/work.s 306465 304950 -1515 -0.494% cmd/go/internal/run.s 4664 4657 -7 -0.150% crypto/tls.s 313130 311833 -1297 -0.414% net/http/httptrace.s 3979 3905 -74 -1.860% net/smtp.s 14413 14344 -69 -0.479% cmd/link/internal/ld.s 545343 542279 -3064 -0.562% cmd/link/internal/mips.s 6218 6215 -3 -0.048% cmd/link/internal/mips64.s 6108 6103 -5 -0.082% cmd/link/internal/amd64.s 18154 18112 -42 -0.231% cmd/link/internal/arm64.s 22527 22494 -33 -0.146% cmd/link/internal/arm.s 22574 22494 -80 -0.354% cmd/link/internal/s390x.s 20779 20746 -33 -0.159% cmd/link/internal/wasm.s 16531 16493 -38 -0.230% cmd/link/internal/x86.s 18906 18849 -57 -0.301% cmd/link/internal/ppc64.s 26856 26778 -78 -0.290% net/http.s 559101 556513 -2588 -0.463% net/http/cookiejar.s 15912 15885 -27 -0.170% expvar.s 9531 9525 -6 -0.063% net/http/httptest.s 16616 16475 -141 -0.849% net/http/cgi.s 23624 23458 -166 -0.703% cmd/go/internal/web.s 16546 16489 -57 -0.344% cmd/vendor/golang.org/x/mod/sumdb.s 33197 33117 -80 -0.241% net/http/fcgi.s 19266 19169 -97 -0.503% net/http/httputil.s 39875 39728 -147 -0.369% cmd/vendor/github.com/google/pprof/internal/symbolz.s 5888 5867 -21 -0.357% net/rpc.s 34154 34003 -151 -0.442% cmd/vendor/github.com/google/pprof/internal/transport.s 2746 2716 -30 -1.092% cmd/vendor/github.com/google/pprof/internal/binutils.s 35999 35875 -124 -0.344% net/rpc/jsonrpc.s 6637 6598 -39 -0.588% cmd/vendor/github.com/google/pprof/internal/symbolizer.s 11533 11458 -75 -0.650% cmd/go/internal/get.s 62921 62803 -118 -0.188% cmd/vendor/github.com/google/pprof/internal/report.s 80364 80058 -306 -0.381% cmd/go/internal/modfetch/codehost.s 89680 89066 -614 -0.685% cmd/trace.s 117171 116701 -470 -0.401% cmd/vendor/github.com/google/pprof/internal/driver.s 144268 143297 -971 -0.673% cmd/go/internal/modfetch.s 126299 125860 -439 -0.348% cmd/vendor/github.com/google/pprof/driver.s 9042 9000 -42 -0.464% cmd/go/internal/modconv.s 17947 17889 -58 -0.323% cmd/pprof.s 12399 12326 -73 -0.589% cmd/go/internal/modload.s 151182 150389 -793 -0.525% cmd/go/internal/generate.s 11738 11636 -102 -0.869% cmd/go/internal/help.s 6571 6531 -40 -0.609% cmd/go/internal/clean.s 11174 11142 -32 -0.286% cmd/go/internal/vet.s 7897 7867 -30 -0.380% cmd/go/internal/envcmd.s 22176 22095 -81 -0.365% cmd/go/internal/list.s 15216 15067 -149 -0.979% cmd/go/internal/modget.s 38698 38519 -179 -0.463% cmd/go/internal/modcmd.s 46674 46441 -233 -0.499% cmd/go/internal/test.s 64664 64456 -208 -0.322% cmd/go.s 6730 6703 -27 -0.401% cmd/compile/internal/ssa.s 3592565 3582500 -10065 -0.280% cmd/compile/internal/gc.s 1549123 1537123 -12000 -0.775% cmd/compile/internal/riscv64.s 14579 14483 -96 -0.658% cmd/compile/internal/mips.s 20578 20419 -159 -0.773% cmd/compile/internal/ppc64.s 25524 25359 -165 -0.646% cmd/compile/internal/mips64.s 19795 19636 -159 -0.803% cmd/compile/internal/wasm.s 13329 13290 -39 -0.293% cmd/compile/internal/s390x.s 28097 27892 -205 -0.730% cmd/compile/internal/arm.s 31489 31321 -168 -0.534% cmd/compile/internal/arm64.s 29803 29590 -213 -0.715% cmd/compile/internal/amd64.s 32961 33221 +260 +0.789% cmd/compile/internal/x86.s 31029 30878 -151 -0.487% total 18534966 18440341 -94625 -0.511% Change-Id: I830d37364f14f0297800adc42c99f60a74c51aca Reviewed-on: https://go-review.googlesource.com/c/go/+/226367 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>

view details

Cuong Manh Le

commit sha 7b30a2d268ccb56221d0d8b149300548ce0308e1

cmd/compile: make isSmallMakeSlice checks slice cap only If slice cap is not set, it will be equal to slice len. So isSmallMakeSlice only needs to check whether slice cap is constant. While at it, also add test to make sure panicmakeslicecap is called when make slice contains invalid non-constant len. For this benchmark: func BenchmarkMakeSliceNonConstantLen(b *testing.B) { len := 1 for i := 0; i < b.N; i++ { s := make([]int, len, 2) _ = s } } Result compare with parent: name old time/op new time/op delta MakeSliceNonConstantLen-12 18.4ns ± 1% 0.2ns ± 2% -98.66% (p=0.008 n=5+5) Fixes #37975 Change-Id: I4bc926361bc2ffeab4cfaa888ef0a30cbc3b80e8 Reviewed-on: https://go-review.googlesource.com/c/go/+/226278 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org>

view details

Josh Bleecher Snyder

commit sha 82253ddc7a6b85240fd74cc5138f685ca931f355

cmd/compile: constant fold CtzNN Change-Id: I3ecd2c7ed3c8ae35c2bb9562aed09f7ade5c8cdd Reviewed-on: https://go-review.googlesource.com/c/go/+/221609 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>

view details

Cherry Zhang

commit sha 6e3bde5f302a20c457459fdaedba21d8ff37ee08

[dev.link] cmd/link: store external relocations in Reloc2 format Store external relocations in (almost) the same format as the Go objects, so we can handle them more uniformly. There is a small speedup: (linking cmd/compile) Deadcode 67.8ms ± 3% 61.1ms ± 3% -9.94% (p=0.008 n=5+5) Dostkcheck 41.2ms ± 2% 38.8ms ± 3% -5.99% (p=0.008 n=5+5) Change-Id: I8616e10b26235904201d6c9465f5ae32a49c9949 Reviewed-on: https://go-review.googlesource.com/c/go/+/226365 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Cherry Zhang

commit sha 0e0ee115c5110f83c763af5c8797759887fe0cb3

[dev.link] cmd/link: unify Relocs.Count and len(rs) The Count field in Relocs type is always equal to len(rs). Unify them. Change-Id: Ic77288ea58b61a98482b218e051d81047d0ddd88 Reviewed-on: https://go-review.googlesource.com/c/go/+/226717 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Cuong Manh Le

commit sha 6edd7971bb3e83356544b2cd6e7a93fdabff1246

cmd/compile: optimize len check when make slice In CL 226278, we did: if len < 0 { panicmakeslicelen } if len > cap { panicmakeslicecap } But due to the fact that cap is constrained to [0,2^31), so it is safe to do: if uint64(len) > cap { if len < 0 { panicmakeslicelen() } panicmakeslicecap() } save us a comparison in common case when len is within range. Passes toolstash-check. Change-Id: I0ebd52914ccde4cbb45f16c9e020b0c8f42e0663 Reviewed-on: https://go-review.googlesource.com/c/go/+/226737 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>

view details

Cherry Zhang

commit sha 7939c43748932c0caf1a1538410eb70fcd5a705f

runtime: generate dummy duffcopy Although duffcopy is not used on PPC64, duff_ppc64x.s and mkduff.go don't match. Make it so. Fixes #38188. Change-Id: Ic6c08e335795ea407880efd449f4229696af7744 Reviewed-on: https://go-review.googlesource.com/c/go/+/226719 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

push time in 2 months

issue commentgolang/go

all: stop using direct syscalls on OpenBSD

Heh, how could I miss that? Well, at least I learned something by trying to do it myself.

That's always a good thing :)

@4a6f656c: Can I do something to accelerate this? Should I try to adapt your work to i386? I have a system here were I could develop and test it.

Getting it working on openbsd/386 would be great!

I've just pushed an update to that repo that is based on Go -tip.

4a6f656c

comment created time in 2 months

issue commentgolang/go

all: stop using direct syscalls on OpenBSD

Does that mean Go will always use dynamic linking or raw syscalls will still be used when linking statically?

Go will always use dynamic linking (and possibly always external linking) - it would be a significant amount of effort to maintain both libc based syscalls and raw syscalls and switch between to two. Any Go binary on OpenBSD that pulls in the net package is already going to result in a dynamic cgo-based binary (unless cgo is explicitly disabled - see https://github.com/golang/go/issues/36435#issuecomment-572138195).

I agree with @beoran and iirc OpenBSD will not enforce libc.so stubs if you won't play their security theater, so you don't have to sacrifice both efficiency and actual security.

If you do not want OpenBSD's "security theater" then I would suggest not using OpenBSD. Additionally, have you actually measured the performance difference? Both Solaris and macOS already both use libc-style syscalls and IIRC the switch on macOS resulted in a minimal performance impact.

4a6f656c

comment created time in 2 months

issue commentgolang/go

all: stop using direct syscalls on OpenBSD

I would like to work on this. After a brief look, Solaris seems to be a good role model for OpenBSD. What would be the best strategy here? OpenBSD seems to share definitions with the other BSD platforms, which result in conflicting definitions when I try to hook it into mksyscall_libc.pl. Or should I try to do things more like MacOS? Is that an easier way? How should I proceed?

@bw-86, the git repo referenced in the first comment contains a full implementation for openbsd/amd64:

https://github.com/4a6f656c/go/tree/openbsd-syscall

I've since rebased and cleaned some aspects of this up, but need to push a new branch.

As noted, there is still work required to complete the migration for openbsd/386, openbsd/arm and openbsd/arm64. There are also some issues relating to the linker that impact this work (see https://github.com/golang/go/issues/39257 and https://github.com/golang/go/issues/39256). Aside from the remaining architectures, most of the remaining work is around being able to split this up to merge upstream and I have some concerns about cross-compiling and bootstrapping that I've not yet had time to investigate.

4a6f656c

comment created time in 2 months

issue commentlibressl-portable/portable

Libressl 3.1.3 force TLS1.3 and doesn't fallback to TLS1.2

Additionally, does this still occur if you specify a maximum version of TLSv1.2?

jkoderu-git

comment created time in 3 months

issue commentlibressl-portable/portable

Libressl 3.1.3 force TLS1.3 and doesn't fallback to TLS1.2

The change that you reference is actually the opposite - if your cipher string only specifies TLSv1.2 capable cipher suites, yet you advertise that TLSv1.3 is capable, your connection will fail since the server will select TLSv1.3 and then discover that there are no TLSv1.3 cipher suites available. This behaviour is effectively the same as what OpenSSL v1.1.x does, the difference being that we do not currently expose the new SSL_set_ciphersuites yet. If TLSv1.3 is not enabled then TLSv1.3 cipher suites will not be included in the client hello.

That said, there appears to be an issue here - unfortunately nothing in the above output shows what the actual problem is. Are you able to get detailed logs from both the client and server? If not, are you able to provide details on reproducing the problem?

jkoderu-git

comment created time in 3 months

issue closedlibressl-portable/openbsd

Is libressl compatible with Linux?

Hi there, I know the repository is called openbsd and all, but is libressl not compatible at all with Linux?

closed time in 3 months

philip-peterson

PR opened canonical/libco

Provide architecture specific implementation for riscv64 (RV64G).

Fixes https://github.com/canonical/libco/issues/18

+131 -0

0 comment

2 changed files

pr created time in 3 months

create barnch4a6f656c/libco

branch : riscv64

created branch time in 3 months

fork 4a6f656c/libco

Mirror of https://byuu.org/library/libco

fork in 3 months

more