profile
viewpoint
John Starks jstarks @Microsoft Container+Linux guy at Microsoft

push eventjstarks/hcsshim

John Starks

commit sha 225a953c31de94107bfe02da9d03533cd611e31d

cim: Rename cim.go to reader.go

view details

push time in 2 days

push eventjstarks/hcsshim

John Starks

commit sha 4a3f09478667f06f7f209576273f4ee172bf5e85

cim: Rename Cim to Reader

view details

push time in 2 days

push eventjstarks/hcsshim

John Starks

commit sha 3898240b988816ef1dbc8edc555bd1e5763a0cc4

cim: Cleanup, improve error codes

view details

John Starks

commit sha 453216518fa328c42397b22eaccd41638cf0a46b

cim: Add docs

view details

push time in 2 days

push eventjstarks/hcsshim

John Starks

commit sha 15eed9c21b85eafab37576a00b7a89c9a7999a06

cim: Remove FileID export

view details

John Starks

commit sha 9d6f1d95b6bde0c344a7b483474190c9731bd352

cim: Stream support, cimtool, fixes

view details

push time in 2 days

push eventjstarks/hcsshim

John Starks

commit sha 656f1b699ae071d8f39d3755663250e17d2b8759

cim: Improve perf

view details

John Starks

commit sha efe083c0eb7f6ac56af6c929af7ee8552a6fe213

cim: Cache inodes

view details

John Starks

commit sha c802f89444808e97b943c1bf3fbded218a8732d6

cim: Tweak comment

view details

push time in 3 days

push eventjstarks/hcsshim

John Starks

commit sha f55fac873c79b547de71a9a6a8686e1343615aaa

Some fixes

view details

John Starks

commit sha 810a23b874a8c5bee7a52ee7b854d58685285fe6

cim: Add working Open API

view details

push time in 3 days

issue commentgolang/go

runtime: "fatal error: PowerRegisterSuspendResumeNotification failure" when running in Windows docker containers

We can look into whether this could be supported in a future version of Windows containers. I think it would be reasonable to ignore failure in this case.

The bigger question to me is whether the change that introduced this regression was the right one at all. The Windows kernel team changed timer behavior in Windows 8 to stop advancing relative timeouts on wake. Otherwise when you open your laptop lid, every timer in the system goes off all at once and you get a bunch of unpredictable errors. Software is generally written to assume that local processes will make forward progress over reasonable time periods, and if they don't then something is wrong. When the machine is asleep, this assumption is violated. By making relative timers behave like threads, so that they both run together or they both don't, the illusion is maintained. You can claim these programs are buggy, but they obviously exist. Watchdog timers are well-known constructs.

This was a conscious design decision in Windows, and so it's disappointing to see the Go runtime second guess this several years later in a bug fix.

As far as behavior on Linux, there is clearly no consensus in issue #24595, which discusses this same problem. And indeed you can see that the CLOCK_MONOTONIC/CLOCK_BOOTTIME convergence was reverted in the kernel exactly because of the reason we stopped advancing time in Windows: random code has random failures due to timeouts. See https://lkml.org/lkml/2018/4/26/929 for a brief justification.

But despite the lack of consensus on Linux, for some reason the change in Windows behavior was merged already.

I think the change that introduced this should be reverted and the original proposal to use QueryUnbiasedInterruptTime (to match the behavior of WaitForSingleObject) should be adopted.

@mpx @networkimprov @ianlancetaylor seemed interested in this topic from the other issue.

KnicKnic

comment created time in 4 days

create barnchjstarks/hcsshim

branch : cim

created branch time in 5 days

pull request commentmoby/moby

Windows: Only set VERSION_QUAD if unset

LGTM

cpuguy83

comment created time in 8 days

Pull request review commentmicrosoft/opengcs

add ability to read runc log for errors in runc commands

 func (r *runcRuntime) processExists(pid int) bool { 	_, err := os.Stat(filepath.Join("/proc", strconv.Itoa(pid))) 	return !os.IsNotExist(err) }++func getRuncLogError(logPath string) interface{} {+	reader, err := os.OpenFile(logPath, syscall.O_RDONLY, 0644)+	if err != nil {+		return nil+	}+	defer reader.Close()++	var lastErr interface{}+	dec := json.NewDecoder(reader)+	for {+		var out map[string]interface{}

It's interesting to me that we're unmarshaling the JSON into a map instead of into a struct like we did in hcsshim when handling the same case... Is there a reason for this?

katiewasnothere

comment created time in 12 days

issue commentgolang/go

os: file open+write+close blocks subsequent Open() with "sharing violation"

I was able to repro this. We're looking into it internally.

networkimprov

comment created time in 13 days

issue commentgolang/go

os: file open+write+close blocks subsequent Open() with "sharing violation"

I'll try to get a repro on OneDrive and report the issue internally.

networkimprov

comment created time in 13 days

issue commentgolang/go

os: file open+write+close blocks subsequent Open() with "sharing violation"

Interesting. Are you trying this on a path that is backed up by OneDrive?

networkimprov

comment created time in 14 days

issue commentgolang/go

os: file open+write+close blocks subsequent Open() with "sharing violation"

In the past I have seen antivirus software keep files open for analysis after the file has been closed, blocking subsequent opens. I do not know whether Norton Lifelock has this problem. It would be interesting to temporarily disable all such security software on the machine (this can be difficult!) and try the repro again. If it stops reproing, then the best course of action would be to report the issue to Symantec.

If it continues to repro, I would suggest looking for any other atypical driver software in the file system stack. Try running fltmc.exe to see if there are any interesting file system filters installed, for example--compare the result to a stock Windows installation.

In any case, I don't think there's any evidence of a Go bug here, and it seems inappropriate for Go to try to work around reliability issues with basic file system APIs. These bugs need to be fixed in the components that are at fault.

networkimprov

comment created time in 14 days

Pull request review commentmicrosoft/opengcs

add ability to read runc log for errors in runc commands

 func (r *runcRuntime) CreateContainer(id string, bundlePath string, stdioSet *st // CreateContainer. func (c *container) Start() error { 	logPath := c.r.getLogPath(c.id)-	cmd := exec.Command("runc", "--log", logPath, "start", c.id)+	cmd := exec.Command("runc", "--log", logPath, "--log-format", "json", "start", c.id)

Would be nice to make a helper for this (exec.Command("runc", "--log", logPath, "--log-format", "json", args...))

katiewasnothere

comment created time in 14 days

issue commentgolang/go

os, syscall: CreateFile() needs FILE_SHARE_*

Except for ReadLink, they should work, yes.

networkimprov

comment created time in 15 days

issue commentgolang/go

os, syscall: CreateFile() needs FILE_SHARE_*

Although this is not documented well (that I can find), Windows will ignore the share flags if the requested access does not include FILE_READ_DATA, FILE_WRITE_DATA, FILE_EXECUTE, or DELETE. The only case that you've pointed out above is the one in ReadLink, which specifies GENERIC_READ (which is translated internally to FILE_GENERIC_READ, which includes FILE_READ_DATA).

And to fix ReadLink, you can probably just remove GENERIC_READ and replace it with 0 or READ_FILE_ATTRIBUTES--according to my reading of the Windows code, issuing FSCTL_GET_REPARSE_POINT does not require any special permissions on the file. And indeed, internally we generally pass 0 or READ_FILE_ATTRIBUTES when opening files for the purpose of issuing this FSCTL.

Having said all that, adding these share flags in these cases certainly doesn't hurt either--it just isn't necessary to fix any functional bug.

networkimprov

comment created time in 15 days

issue commentgolang/go

os: Stat() blocks concurrent Open() with "sharing violation"

stat calls CreateFile in a fallback path since apparently there are cases where GetFileAttributesEx fails.

networkimprov

comment created time in 15 days

issue commentgolang/go

os: Stat() blocks concurrent Open() with "sharing violation"

I let it run overnight with no repro.

networkimprov

comment created time in 15 days

issue commentgolang/go

os: Stat() blocks concurrent Open() with "sharing violation"

I'm unable to reproduce this on the latest version of Windows 10 with Go 1.13.1 (I should probably update...).

@networkimprov, do you have third-party antivirus software installed?

networkimprov

comment created time in 15 days

issue commentmicrosoft/terminal

Writing random output to console output handle fails with no last error set

Although there's also a call to _RemoveInvalidSequences before that, which presumably should remove any invalid UTF-8 sequences.

benhillis

comment created time in 16 days

issue commentmicrosoft/terminal

Writing random output to console output handle fails with no last error set

Should _InvolvedParse just stop passing MB_ERR_INVALID_CHARS to MultiByteToWideChar?

benhillis

comment created time in 16 days

issue commentgolang/go

internal/syscall/windows/registry: TestWalkFullRegistry failing on windows-amd64-longtest

Thanks for pointing this out; I can report these internally. But I think you'll have to keep your ignore list around, since it seems unlikely that we would backport fixes for these bugs.

bradfitz

comment created time in 18 days

issue commentmoby/moby

The recent Windows update breaks symlink handling on a Docker volume

Looking into this...

db4

comment created time in 20 days

issue commentgolang/go

syscall: windows doesn't allow read-only directories

There is no such document that I am aware of.

I don't think you want to try to do anything automatic with ACLs. You're unlikely to come up with a policy that will make everyone happy.

zx2c4

comment created time in 21 days

pull request commentmicrosoft/hcsshim

wclayer: Work around Windows bug when expanding sandbox size

Can we merge this? Can someone work to get this integrated into Moby?

jstarks

comment created time in 25 days

issue commentmicrosoft/hcsshim

Revert #718 when Windows 19H1 has expand sandbox fix

#718 for reference

jstarks

comment created time in a month

PR closed microsoft/hcsshim

Add osversion 18362

I have downloaded the ISO files for Windows 10 1903 and Windows Server, version 1903 and found version 18362 in docker info output. It's time to add it to the list of osversions.

+4 -0

1 comment

1 changed file

StefanScherer

pr closed time in a month

pull request commentmicrosoft/hcsshim

Add osversion 18362

This was added as V19H1 in an unrelated PR.

StefanScherer

comment created time in a month

push eventjstarks/hcsshim

Sebastiaan van Stijn

commit sha 92cb5b6976045984f6f746ca62c37ba952d37cae

Enhancement: add osversion.Build() utility Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

view details

John Howard

commit sha 2226e083fc390003ae5aa8325c3c92789afa0e7a

Merge pull request #569 from thaJeztah/add_build_function Enhancement: add osversion.Build() utility

view details

John Starks

commit sha 741b914f1849708bf7fd9a3c0a4cf729597b8503

internal/hcs: Improve process stdio lifetime To better support the external bridge, associate the stdio handles with the owning process and close them when the process object is closed.

view details

John Starks

commit sha 0dcdb44b887a6a528ca916a8eac85104efca39ff

shimdiag: New tool to diagnose runhcs shims Currently this tool allows listing running shims and execing a process in the shim's associated utility VM.

view details

John Starks

commit sha 40e0b86ace8a904c599158c97f7a0870103716ff

Replace linuxkit's hvsock support with go-winio's This fixes some race conditions when Close is called concurrently with other operations.

view details

John Starks

commit sha c5f1ca9ee8bd64317296ff0ce30002dfe013baa1

Merge pull request #576 from jstarks/hvsock Replace linuxkit's hvsock support with go-winio's

view details

John Starks

commit sha f072d47a533cf2dcdc8aedd12d415206e775ef3c

Merge pull request #572 from jstarks/stdio internal/hcs: Improve process stdio lifetime

view details

John Starks

commit sha 8c442edd4f71f556f7cd6c1b346c36fd57354b61

Merge pull request #575 from jstarks/shimdiag shimdiag: New tool to diagnose runhcs shims

view details

John Starks

commit sha f2a4e6f63ac499a3518df5ab2fc6b00259564fd8

shim: Fix build break

view details

John Starks

commit sha e38f6590af69e45ff38af046b7bf4d395e3e1142

Merge pull request #579 from jstarks/fix_build shim: Fix build break

view details

Justin Terry (VM)

commit sha 20158f49bf79623d48228d82a093e8c447a58f84

Fix shimdiag Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>

view details

John Starks

commit sha ad87c9209ca3465af1cf59c399a31d228b8d7558

shimdiag: Add stacks command to dump stacks

view details

Justin

commit sha 0d86597ce55f24b735815d0152362ef33f7985ec

Merge pull request #580 from Microsoft/shimdiag_fix Fix shimdiag

view details

Justin

commit sha 58f8f4bd40f183ca7697fc978e9f3b4cac9a7a8c

Merge pull request #578 from jstarks/shimdiag_stacks shimdiag: Add stacks command to dump stacks

view details

Sebastiaan van Stijn

commit sha ef775b6a90143374b7d5d99ed8e44a512e3cd162

Fix Windows Server version for RS4 in comment Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

view details

Justin Terry (VM)

commit sha 6fc80f50d764c1a621900d54f6eaeb298a75473f

Fix bug in documentation for UVM processor.limit Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>

view details

Justin Terry (VM)

commit sha 76d1d3a4dec488088c437c5b98f4916d1fa4e641

Move to golang 1.12.4 Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>

view details

Justin

commit sha 965235930020a817a95c5bc76ef51fe9c71c84a7

Merge pull request #585 from Microsoft/golang_1_12_4 Move to golang 1.12.4

view details

Justin

commit sha 41f3a0988b5e2321658612e19301c60a4d895bf0

Merge pull request #584 from Microsoft/processor_limit_doc_fix Fix bug in documentation for UVM processor.limit

view details

John Starks

commit sha c853b9ac561f8a4620ae69713bbbbc86d28c0260

hcs: Fail operations when the HCS service crashes If the HCS service crashes, then all processes and compute systems get notified of this. The code was previously ignoring this notification, meaning outstanding waits would never be satisfied. Now the notification causes all pending waits to complete with an error.

view details

push time in a month

push eventjstarks/hcsshim

John Starks

commit sha 823c83612a5e11222adfd4fb167a753d2a7eac50

osversion: Add version for 19H1

view details

John Starks

commit sha 164f6a773d063a500616fd6d13404ffc357540b7

wclayer: Work around Windows bug when expanding sandbox size This change works around a bug in Windows where a sandbox VHDX that has been resized cannot be successfully mounted. This is due to a failure in the path that resizes the NTFS volume inside the VHDX during the sandbox mount process. To work around this, manually expand the volume in the wclayer package just after making the call to expand the VHDX. This change hurts the performance of the resize operation on affected Windows hosts (19H1 and prerelease versions of Vb) and should be reverted once the Windows bug has been fixed and is widely deployed.

view details

push time in a month

PR opened microsoft/hcsshim

wclayer: Work around Windows bug when expanding sandbox size

This change works around a bug in Windows where a sandbox VHDX that has been resized cannot be successfully mounted. This is due to a failure in the path that resizes the NTFS volume inside the VHDX during the sandbox mount process. To work around this, manually expand the volume in the wclayer package just after making the call to expand the VHDX.

This change hurts the performance of the resize operation on affected Windows hosts (19H1 and prerelease versions of Vb) and should be reverted once the Windows bug has been fixed and is widely deployed.

This should provide a workaround for #708.

+179 -0

0 comment

3 changed files

pr created time in a month

create barnchjstarks/hcsshim

branch : workaround_expandlayer

created branch time in a month

issue commentmicrosoft/terminal

Feature Request: wt.exe supports command line arguments (profile, command, directory, etc.)

It's not just a tradition, it's encoded in the getopt family of functions, which are available in libc basically everywhere but Windows.

In Windows we use a version of getopt for wsl's option parsing. It might be useful to do the same (e.g. grab a copy of getopt from musl libc) so that things like -- (to separate options from non-option arguments) work in a predictable fashion.

fcharlie

comment created time in a month

Pull request review commentmicrosoft/opengcs

Create Containers and GCS cgroups on GCS startup

 func main() { 		bridgeOut = bridgeCon 	} +	// Setup the UVM cgroups to protect against a workload taking all available

Seems like a reasonable start. Maybe add some command line parameters to configure the sizes, though, so that we can adjust this from the host.

jterry75

comment created time in a month

Pull request review commentmicrosoft/hcsshim

Shorten Shutdown and Terminate timeout to 30 seconds

 func (c *Container) Shutdown(ctx context.Context) (err error) { 	defer func() { oc.SetSpanStatus(span, err) }() 	span.AddAttributes(trace.StringAttribute("cid", c.id)) +	ctx, cancel := context.WithTimeout(ctx, 30*time.Second)

Why not make this change in the caller, or in shutdown()?

Alternatively, should we have changed the global timeout on the bridge, either in the package or in the caller to the package? We already have a mechanism to terminate the bridge entirely if a synchronous RPC does not return in a certain time.

jterry75

comment created time in a month

issue commentgolang/go

proposal: syscall: define Windows O_ALLOW_DELETE for use in os.OpenFile

The motivation of this as well as the original proposal was to make it easier for Go software authors to write code that works cross-platform. We need to pass FILE_SHARE_DELETE to make Windows behave more like POSIX with respect to file deletion. There is general agreement that we cannot make this the default without regressing existing behavior, but the desire to have a clean, simple solution persists.

Any solution that requires extra dependencies, _windows.go files, build tags, etc. deviates from the goal of writing common code everywhere. I know from experience that it will be much easier to convince a random developer to add O_ALLOW_DELETE to their calls to os.OpenFile than to convince them to pull in an additional dependency with a custom fork of os.OpenFile, or to add Windows-specific .go files, just to get Windows to behave like everyone else.

I like the idea of putting a Windows-specific open routine in x/sys/windows to easily expose the wealth of CreateFile functionality! It would be great if we didn't have to replicate the complexity of calling syscall.CreateFile everywhere that needs Windows-specific functionality.

But I also think FILE_SHARE_DELETE is a special case worthy of inclusion in os.OpenFile, since it changes Windows behavior to be closer to all the other operating systems Go supports. I can't immediately think of any other CreateFile flags that do that.

rsc

comment created time in a month

issue commentgolang/go

x/sys/windows: API break in SecurityAttributes struct

Is there an official position on the compatibility guarantees for x/sys/windows? This is the second breaking change I've been made aware of in the last week.

pete-woods

comment created time in a month

PR closed microsoft/go-winio

Adapt to the API renewal of golang.org/x/sys/windows

Why I made this PR

There was a destructive API change in golang/x/sys module. It made it unable to build a module that depends on both this module and newer golang/x/sys. Resolve #161

  • Reference: https://github.com/golang/sys/commit/2dccfee4fd3e23e10ba17b9d696cf2388c28764b
+4 -6

3 comments

3 changed files

uztbt

pr closed time in a month

pull request commentmicrosoft/go-winio

Adapt to the API renewal of golang.org/x/sys/windows

The change in x/sys/windows was reverted: https://github.com/golang/sys/commit/855e68c8590b0d6a9d08863d2982eb8aeddd98d3. So this PR is no longer necessary.

Thanks for the contribution!

uztbt

comment created time in a month

pull request commentmicrosoft/go-winio

Move to upstream Sddl/SecurityAttribute functions

We should leave the existing functions but have them call through to the windows package (and only if the semantics are exactly the same).

zx2c4

comment created time in a month

pull request commentmicrosoft/go-winio

Adapt to the API renewal of golang.org/x/sys/windows

I'm pushing to get this reverted from x/sys/windows. Let's hold this change in the meantime.

uztbt

comment created time in 2 months

CommitCommentEvent

issue commentmicrosoft/hcsshim

docker build freeze at exportLayer phase

I think we need to understand why os.RemoveAll is not returning. What version of Go is this?

tardyp

comment created time in 2 months

PR opened microsoft/opengcs

init: Close entropy-related fds

This is what happens when I don't code for 6 weeks. :)

+3 -0

0 comment

1 changed file

pr created time in 2 months

create barnchjstarks/opengcs

branch : entropy_fix

created branch time in 2 months

Pull request review commentmicrosoft/hcsshim

uvm: Send entropy to Linux UVMs during boot

 func (uvm *UtilityVM) Start(ctx context.Context) (err error) { 	ctx, cancel := context.WithTimeout(ctx, 2*time.Minute) 	defer cancel() +	g, gctx := errgroup.WithContext(ctx)++	// Prepare to provide entropy to the init process in the background. This+	// must be done in a goroutine since, when using the internal bridge, the+	// call to Start() will block until the GCS launches, and this cannot occur+	// until the host accepts and closes the entropy connection.+	if uvm.entropyListener != nil {+		g.Go(func() error {+			conn, err := uvm.acceptAndClose(gctx, uvm.entropyListener)+			uvm.entropyListener = nil

I reshuffled some things and cleaned up the log handling stuff too to follow the same pattern.

jstarks

comment created time in 2 months

push eventjstarks/hcsshim

John Starks

commit sha ca6711998dafdac392699e0f50b155fe926ea5eb

uvm: Send entropy to Linux UVMs during boot This change updates the Linux UVM boot sequence to open a vsock connection to send entropy data to seed the kernel RNG. This is necessary so that early uses of the kernel RNG reliably get unpredictable data. This depends on the corresponding change to init in the opengcs repo.

view details

push time in 2 months

push eventjstarks/hcsshim

John Starks

commit sha 1331c1896d6cfd8afcdf0783fadc2191632e774c

uvm: Send entropy to Linux UVMs during boot This change updates the Linux UVM boot sequence to open a vsock connection to send entropy data to seed the kernel RNG. This is necessary so that early uses of the kernel RNG reliably get unpredictable data. This depends on the corresponding change to init in the opengcs repo.

view details

push time in 2 months

pull request commentmicrosoft/opengcs

init: Add option to initialize entropy from vsock

Ready to merge.

jstarks

comment created time in 2 months

Pull request review commentmicrosoft/opengcs

init: Add option to initialize entropy from vsock

 void init_network(const char *iface, int domain) {     close(s); } +// inject boot-time entropy after reading it from a vsock port+void init_entropy(int port) {+    int s = openvsock(VMADDR_CID_HOST, port);+    if (s < 0) {+        die("openvsock entropy");+    }++    int e = open("/dev/random", O_RDWR);+    if (e < 0) {+        die("open /dev/random");+    }++    struct {+        int entropy_count;+        int buf_size;+        char buf[4096];+    } buf;++    for (;;) {+        ssize_t n = read(s, buf.buf, sizeof(buf.buf));

Right, when host closes we get n == 0. This loop would be a little more complicated in the presence of signals, but we disable signals early on (and I'm not sure where those signals would come from anyway).

jstarks

comment created time in 2 months

PR opened microsoft/opengcs

gcs: Improve error message on pmem mount failure
+5 -1

0 comment

1 changed file

pr created time in 2 months

PR opened microsoft/hcsshim

uvm: Send entropy to Linux UVMs during boot

This change updates the Linux UVM boot sequence to open a vsock connection to send entropy data to seed the kernel RNG. This is necessary so that early uses of the kernel RNG reliably get unpredictable data.

This depends on the corresponding change to init in the opengcs repo.

+86 -10

0 comment

4 changed files

pr created time in 2 months

push eventjstarks/hcsshim

John Starks

commit sha e888725b1cfc18ce4126aa4d2bb4338d565b2fdc

uvm: Send entropy to Linux UVMs during boot This change updates the Linux UVM boot sequence to open a vsock connection to send entropy data to seed the kernel RNG. This is necessary so that early uses of the kernel RNG reliably get unpredictable data. This depends on the corresponding change to init in the opengcs repo.

view details

push time in 2 months

create barnchjstarks/opengcs

branch : pmem_error

created branch time in 2 months

create barnchjstarks/hcsshim

branch : entropy

created branch time in 2 months

push eventjstarks/opengcs

John Starks

commit sha a33866838cc21875c1423e3ee5945c84c566f094

init: Add option to initialize entropy from vsock This change adds a command line option, -e, that specifies a vsock port to read initial RNG entropy. init reads all data written to the connection by the host, adds this data to the kernel RNG, and increments the available entropy count. The host is trusted to write cryptographically random data to this port. Without this, the available entropy at LCOW boot is very low, and data read from /dev/urandom is likely to be highly predicable.

view details

push time in 2 months

PR opened microsoft/opengcs

init: Add option to initialize entropy from vsock

This change adds a command line option, -e, that specifies a vsock port to read initial RNG entropy. init reads all data written to the connection by the host, adds this data to the kernel RNG, and increments the available entropy count. The host is trusted to write cryptographically random data to this port.

Without this, the available entropy at LCOW boot is very low, and data read from /dev/urandom is likely to be highly predicable.

+96 -40

0 comment

5 changed files

pr created time in 2 months

create barnchjstarks/opengcs

branch : entropy

created branch time in 2 months

more