[go] crypto/rand: generate random numbers using RtlGenRandom on Windows
Gobot Gobot (Gerrit)
TryBots beginning. Status page: https://farmer.golang.org/try?commit=bbb5cb5e
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
Jason A. Donenfeld uploaded patch set #2 to this change.
crypto/rand: generate random numbers using RtlGenRandom on Windows
CryptGenRandom appears to be unfavorable these days, whereas the classic
RtlGenRandom is still going strong.
Fixes #33542
Change-Id: I5c02a5917572f54079d627972401efb6e1ce4057
---
M src/crypto/rand/rand.go
M src/crypto/rand/rand_windows.go
M src/syscall/syscall_windows.go
M src/syscall/zsyscall_windows.go
4 files changed, 18 insertions(+), 32 deletions(-)
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
Jason A. Donenfeld has uploaded this change for review.
crypto/rand: generate random numbers using RtlGenRandom on Windows
CryptGenRandom appears to be unfavorable these days, whereas the classic
RtlGenRandom is still going wrong.
Fixes #33542
Change-Id: I5c02a5917572f54079d627972401efb6e1ce4057
---
M src/crypto/rand/rand.go
M src/crypto/rand/rand_windows.go
M src/syscall/syscall_windows.go
M src/syscall/zsyscall_windows.go
4 files changed, 18 insertions(+), 32 deletions(-)
diff --git a/src/crypto/rand/rand.go b/src/crypto/rand/rand.go
index a5ccd19..127e1b7 100644
--- a/src/crypto/rand/rand.go
+++ b/src/crypto/rand/rand.go
@@ -14,7 +14,7 @@
// On Linux and FreeBSD, Reader uses getrandom(2) if available, /dev/urandom otherwise.
// On OpenBSD, Reader uses getentropy(2).
// On other Unix-like systems, Reader reads from /dev/urandom.
-// On Windows systems, Reader uses the CryptGenRandom API.
+// On Windows systems, Reader uses the RtlGenRandom API.
// On Wasm, Reader uses the Web Crypto API.
var Reader io.Reader
diff --git a/src/crypto/rand/rand_windows.go b/src/crypto/rand/rand_windows.go
index 78a4ed6..d53018e 100644
--- a/src/crypto/rand/rand_windows.go
+++ b/src/crypto/rand/rand_windows.go
@@ -9,48 +9,20 @@
import (
"os"
- "sync"
- "sync/atomic"
"syscall"
- "time"
)
-// Implemented by using Windows CryptoAPI 2.0.
-
func init() { Reader = &rngReader{} }
-// A rngReader satisfies reads by reading from the Windows CryptGenRandom API.
-type rngReader struct {
- used int32 // atomic; whether this rngReader has been used
- prov syscall.Handle
- mu sync.Mutex
-}
+type rngReader struct{}
func (r *rngReader) Read(b []byte) (n int, err error) {
- if atomic.CompareAndSwapInt32(&r.used, 0, 1) {
- // First use of randomness. Start timer to warn about
- // being blocked on entropy not being available.
- t := time.AfterFunc(60*time.Second, warnBlocked)
- defer t.Stop()
- }
- r.mu.Lock()
- if r.prov == 0 {
- const provType = syscall.PROV_RSA_FULL
- const flags = syscall.CRYPT_VERIFYCONTEXT | syscall.CRYPT_SILENT
- err := syscall.CryptAcquireContext(&r.prov, nil, nil, provType, flags)
- if err != nil {
- r.mu.Unlock()
- return 0, os.NewSyscallError("CryptAcquireContext", err)
- }
- }
- r.mu.Unlock()
-
if len(b) == 0 {
return 0, nil
}
- err = syscall.CryptGenRandom(r.prov, uint32(len(b)), &b[0])
+ err = syscall.RtlGenRandom(&b[0], uint32(len(b)))
if err != nil {
- return 0, os.NewSyscallError("CryptGenRandom", err)
+ return 0, os.NewSyscallError("RtlGenRandom", err)
}
return len(b), nil
}
diff --git a/src/syscall/syscall_windows.go b/src/syscall/syscall_windows.go
index 992f673..b899ef0 100644
--- a/src/syscall/syscall_windows.go
+++ b/src/syscall/syscall_windows.go
@@ -210,6 +210,7 @@
//sys CryptAcquireContext(provhandle *Handle, container *uint16, provider *uint16, provtype uint32, flags uint32) (err error) = advapi32.CryptAcquireContextW
//sys CryptReleaseContext(provhandle Handle, flags uint32) (err error) = advapi32.CryptReleaseContext
//sys CryptGenRandom(provhandle Handle, buflen uint32, buf *byte) (err error) = advapi32.CryptGenRandom
+//sys RtlGenRandom(buf *uint8, bytes uint32) (err error) = advapi32.SystemFunction036
//sys GetEnvironmentStrings() (envs *uint16, err error) [failretval==nil] = kernel32.GetEnvironmentStringsW
//sys FreeEnvironmentStrings(envs *uint16) (err error) = kernel32.FreeEnvironmentStringsW
//sys GetEnvironmentVariable(name *uint16, buffer *uint16, size uint32) (n uint32, err error) = kernel32.GetEnvironmentVariableW
diff --git a/src/syscall/zsyscall_windows.go b/src/syscall/zsyscall_windows.go
index 2348f65..b4222f0 100644
--- a/src/syscall/zsyscall_windows.go
+++ b/src/syscall/zsyscall_windows.go
@@ -95,6 +95,7 @@
procCryptAcquireContextW = modadvapi32.NewProc("CryptAcquireContextW")
procCryptReleaseContext = modadvapi32.NewProc("CryptReleaseContext")
procCryptGenRandom = modadvapi32.NewProc("CryptGenRandom")
+ procSystemFunction036 = modadvapi32.NewProc("SystemFunction036")
procGetEnvironmentStringsW = modkernel32.NewProc("GetEnvironmentStringsW")
procFreeEnvironmentStringsW = modkernel32.NewProc("FreeEnvironmentStringsW")
procGetEnvironmentVariableW = modkernel32.NewProc("GetEnvironmentVariableW")
@@ -821,6 +822,18 @@
return
}
+func RtlGenRandom(buf *uint8, bytes uint32) (err error) {
+ r1, _, e1 := Syscall(procSystemFunction036.Addr(), 2, uintptr(unsafe.Pointer(buf)), uintptr(bytes), 0)
+ if r1 == 0 {
+ if e1 != 0 {
+ err = errnoErr(e1)
+ } else {
+ err = EINVAL
+ }
+ }
+ return
+}
+
func GetEnvironmentStrings() (envs *uint16, err error) {
r0, _, e1 := Syscall(procGetEnvironmentStringsW.Addr(), 0, 0, 0, 0)
envs = (*uint16)(unsafe.Pointer(r0))
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
Patch set 2:Run-TryBot +1
Brad Fitzpatrick (Gerrit)
2 comments:
Patch Set #2, Line 10:
strongI was very confused by switching to something that's "going wrong". 😊
File src/crypto/rand/rand_windows.go:
Patch Set #2, Line 27:
len(b)return int(uint32(len(b)), nil
?
If they're trying to read GBs of randomness, this would technically be wrong, right?
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Gobot Gobot (Gerrit)
TryBots are happy.
Patch set 2:TryBot-Result +1
Jason A. Donenfeld (Gerrit)
Jason A. Donenfeld uploaded patch set #3 to this change.
crypto/rand: generate random numbers using RtlGenRandom on Windows
CryptGenRandom appears to be unfavorable these days, whereas the classic
RtlGenRandom is still going strong.
Fixes #33542
Change-Id: I5c02a5917572f54079d627972401efb6e1ce4057
---
M src/crypto/rand/rand.go
M src/crypto/rand/rand_windows.go
M src/syscall/syscall_windows.go
M src/syscall/zsyscall_windows.go
4 files changed, 19 insertions(+), 33 deletions(-)
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
Patch set 3:Run-TryBot +1
2 comments:
Patch Set #2, Line 10:
strong
I was very confused by switching to something that's "going wrong". […]
Ack
File src/crypto/rand/rand_windows.go:
Patch Set #2, Line 27:
len(b)
return int(uint32(len(b)), nil […]
Good call. I'll change this like so, though of course int is signed and smaller than uint32, so sometimes we'll return negative numbers.
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Gobot Gobot (Gerrit)
Gobot Gobot (Gerrit)
TryBots are happy.
Patch set 3:TryBot-Result +1
Alex Brainman (Gerrit)
Jason, thank you for fixing this.
Why do you think we should use RtlGenRandom here?
The RtlGenRandom doco
https://docs.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom
suggests that we should use CryptGenRandom
It may be altered or unavailable in subsequent versions. Instead, use the CryptGenRandom function
Filippo, you added wait-release tag. Does it mean that we cannot submit this CL until after go1.14 is released?
Alex
1 comment:
Patch Set #2, Line 27:
len(b)
Good call. […]
Why, if len(b) is grater than largest int32, don't you pass largest int32 into syscall.RtlGenRandom instead? This will allow you never return negative numbers. No?
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Filippo Valsorda (Gerrit)
Patch Set 3:
(1 comment)
Jason, thank you for fixing this.
Why do you think we should use RtlGenRandom here?
The RtlGenRandom doco
https://docs.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom
suggests that we should use CryptGenRandom
There's some discussion already on the issue, let's keep discussing there.
It may be altered or unavailable in subsequent versions. Instead, use the CryptGenRandom function
Filippo, you added wait-release tag. Does it mean that we cannot submit this CL until after go1.14 is released?
Yes, unless there is a concrete security concern, or we think the current API will break soon, the tree is frozen and this will have to wait for Go 1.15.
Felix Kollmann (Gerrit)
From my POV
a) the `RtlGenRandom` is not to be used because it's purely internal: "It may be altered or unavailable in subsequent versions. Instead, use the CryptGenRandom function."
b) the suggested `CryptGenRandom` function is deprecated. (That's what this patch is trying to fix. Thanks to Jason for working on this.)
c) The official solution would be to use the new `BCryptGenRandom` function: https://docs.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom ; Example: https://github.com/golang/go/issues/33542#issuecomment-562210275
Lubomir I. Ivanov (Gerrit)
agreed with the latest comment by Felix.
BCryptGenRandom *should* be used instead of RtlGenRandom, because RtlGenRandom might go away in a near future release of Windows and Go's stdlib has to be updated again.
Jason, let me know if you wish to update this change or if i should send a separate one.
Jason A. Donenfeld (Gerrit)
RtlGenRandom is not going to go away. There's not a chance Microsoft would do something like that.
Felix Kollmann (Gerrit)
No, they won't. But RtlGenRandom is not part of the Universal Windows Platform, unlike BCryptGenRandom. If support for future Windows-based (non-PC) platforms is desired, the UWP is the way to go.
Ian Lance Taylor (Gerrit)
Filippo, Jason, any interest in trying to get this into 1.15? Needs to be soon.
Jason A. Donenfeld (Gerrit)
Patch Set 3:
Filippo, Jason, any interest in trying to get this into 1.15? Needs to be soon.
Sure. I think this patchset here is basically ready to go. And will be an improvement over what was there before.
Lubomir I. Ivanov (Gerrit)
hello, i've just sent a separate change to use the recommended function BCryptGenRandom here:
https://go-review.googlesource.com/c/go/+/232860
Jason A. Donenfeld (Gerrit)
Patch set 3:Trust +1
1 comment:
Patchset:
Can we approve/submit this finally?
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Alex Brainman (Gerrit)
1 comment:
Patchset:
Filippo,
Can you, please, decide between this change or
https://go-review.googlesource.com/c/go/+/232860
or no change.
We could not decide this for Go 1.15. We are about to miss Go 1.16 too.
Thank you.
Alex
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Filippo Valsorda (Gerrit)
Patch set 3:Code-Review +2
3 comments:
File src/crypto/rand/rand_windows.go:
The documentation is really scarce, does this API not block at boot?
Patch Set #3, Line 46:
r.mu.Unlock()Likewise, did we check this API can be used concurrently?
Patch Set #3, Line 27:
int(uint32(len(b)))I assume this is to make sure values larger than a uint32 are properly truncated before returning. It'd be good to have a comment so no one passes by and removes the nested conversions.
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
4 comments:
Patchset:
Will post a new version shortly.
File src/crypto/rand/rand_windows.go:
The documentation is really scarce, does this API not block at boot?
Oh. I'm pretty sure it does block at boot, as Fortuna is well designed, which means deleting this hunk here is wrong. I'll re-add that.
Patch Set #3, Line 46:
r.mu.Unlock()Likewise, did we check this API can be used concurrently?
SystemFunction036->ProcessPrng->AesRNGState_generate->EnterCriticalSection
So it looks like MSFT has at least thought about this. There could be other setup code around it that's not, but I'd be very, very surprised if it wasn't. I can run some quick tests, I guess.
Patch Set #3, Line 27:
int(uint32(len(b)))
I assume this is to make sure values larger than a uint32 are properly truncated before returning. […]
Ack
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
2 comments:
File src/crypto/rand/rand_windows.go:
Oh. […]
Actually, as far as I can tell, the RNG is seeded during dll initialization, which means the process will block before we even hit this code. I guess Windows is confident enough it'll always have enough entropy by the time programs run, and so this isn't an actual issue they have.
DllMain -> MsProviderStart -> InitUmRootRngState -> GetSeedFromKernelState -> DeviceIoControl -> {kernel}
Funny enough, if any of those fail, DllMain will return FALSE, and the RNG (and hence the program, usually) will just fail to load at all. That's a nice fail safe. Way to go Microsoft!
Patch Set #3, Line 46:
r.mu.Unlock()
SystemFunction036->ProcessPrng->AesRNGState_generate->EnterCriticalSection […]
"All access to the buffered PRNG state is gated on the lock. This ensures that multiple threads do not attempt to read or modify the same state at the same time."
...
"Just like in kernel mode, we have per-processor buffered PRNG states in each process. These are again created on-demand and seeded from the process base PRNG. The perprocessor PRNG states are maintained by BCryptPrimitives.dll."
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
1 comment:
File src/crypto/rand/rand_windows.go:
Actually, as far as I can tell, the RNG is seeded during dll initialization, which means the process […]
Oh, this is confirmed by that paper I linked earlier:
"For each user-mode process, we have a (buffered) base PRNG maintained by BCryptPrimitives.dll. When this DLL loads it requests a random seed from kernel mode (where it is produced by the per-CPU states) and seeds the process base PRNG. If this were to fail, BCryptPrimitive.dll fails to load, which in most cases causes the process to terminate. This behavior ensures that we never have to return an error code from the RNG system."
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
Jason A. Donenfeld uploaded patch set #4 to this change.
crypto/rand: generate random numbers using RtlGenRandom on Windows
CryptGenRandom appears to be unfavorable these days, whereas the classic
RtlGenRandom is still going strong.
This commit also moves the warnBlocked function into rand_unix, rather
than rand, because it's now only used on unix.
Fixes #33542
Change-Id: I5c02a5917572f54079d627972401efb6e1ce4057
---
M src/crypto/rand/rand.go
M src/crypto/rand/rand_unix.go
M src/crypto/rand/rand_windows.go
M src/syscall/syscall_windows.go
M src/syscall/zsyscall_windows.go
5 files changed, 27 insertions(+), 37 deletions(-)
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
Patch set 4:Run-TryBot +1
Jason A. Donenfeld (Gerrit)
Patch set 4:Code-Review +2
1 comment:
Patchset:
I think we're good to go here.
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
Patch set 4:-Code-Review
1 comment:
Patchset:
Hm, go bot is odd.
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Alberto Donizetti (Gerrit)
1 comment:
Patchset:
Hm, go bot is odd.
Yeah the bot doesn't like +2s from the author, this was added recently to prevent self-reviews. Anyway you already have a +2 from Filippo so you can press the submit button (unless you expect him to want to look at your update first).
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
1 comment:
Patchset:
Yeah the bot doesn't like +2s from the author, this was added recently to prevent self-reviews. […]
Right, I was considering just submitting it, but this isn't the kind of change I want to be too hasty about, so I'll let Filippo have a final look.
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
1 comment:
Patchset:
Looks like no objections. I'll submit.
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
Jason A. Donenfeld submitted this change.
crypto/rand: generate random numbers using RtlGenRandom on Windows
CryptGenRandom appears to be unfavorable these days, whereas the classic
RtlGenRandom is still going strong.
This commit also moves the warnBlocked function into rand_unix, rather
than rand, because it's now only used on unix.
Fixes #33542
Change-Id: I5c02a5917572f54079d627972401efb6e1ce4057
Reviewed-on: https://go-review.googlesource.com/c/go/+/210057
Run-TryBot: Jason A. Donenfeld <Ja...@zx2c4.com>
TryBot-Result: Go Bot <go...@golang.org>
Reviewed-by: Filippo Valsorda <fil...@golang.org>
Trust: Jason A. Donenfeld <Ja...@zx2c4.com>
---
M src/crypto/rand/rand.go
M src/crypto/rand/rand_unix.go
M src/crypto/rand/rand_windows.go
M src/syscall/syscall_windows.go
M src/syscall/zsyscall_windows.go
5 files changed, 27 insertions(+), 37 deletions(-)
diff --git a/src/crypto/rand/rand.go b/src/crypto/rand/rand.go
index a5ccd19..fddd114 100644
--- a/src/crypto/rand/rand.go
+++ b/src/crypto/rand/rand.go
@@ -14,7 +14,7 @@
// On Linux and FreeBSD, Reader uses getrandom(2) if available, /dev/urandom otherwise.
// On OpenBSD, Reader uses getentropy(2).
// On other Unix-like systems, Reader reads from /dev/urandom.
-// On Windows systems, Reader uses the CryptGenRandom API.
+// On Windows systems, Reader uses the RtlGenRandom API.
// On Wasm, Reader uses the Web Crypto API.
var Reader io.Reader
@@ -23,7 +23,3 @@
func Read(b []byte) (n int, err error) {
return io.ReadFull(Reader, b)
}
-
-func warnBlocked() {
- println("crypto/rand: blocked for 60 seconds waiting to read random data from the kernel")
-}
diff --git a/src/crypto/rand/rand_unix.go b/src/crypto/rand/rand_unix.go
index 0610f69..548a5e4 100644
--- a/src/crypto/rand/rand_unix.go
+++ b/src/crypto/rand/rand_unix.go
@@ -47,6 +47,10 @@
// urandom-style randomness.
var altGetRandom func([]byte) (ok bool)
+func warnBlocked() {
+ println("crypto/rand: blocked for 60 seconds waiting to read random data from the kernel")
+}
+
func (r *devReader) Read(b []byte) (n int, err error) {
if atomic.CompareAndSwapInt32(&r.used, 0, 1) {
// First use of randomness. Start timer to warn about
diff --git a/src/crypto/rand/rand_windows.go b/src/crypto/rand/rand_windows.go
index 78a4ed6..8b2c960 100644
--- a/src/crypto/rand/rand_windows.go
+++ b/src/crypto/rand/rand_windows.go
@@ -9,48 +9,24 @@
import (
"os"
- "sync"
- "sync/atomic"
"syscall"
- "time"
)
-// Implemented by using Windows CryptoAPI 2.0.
-
func init() { Reader = &rngReader{} }
-// A rngReader satisfies reads by reading from the Windows CryptGenRandom API.
-type rngReader struct {
- used int32 // atomic; whether this rngReader has been used
- prov syscall.Handle
- mu sync.Mutex
-}
+type rngReader struct{}
func (r *rngReader) Read(b []byte) (n int, err error) {
- if atomic.CompareAndSwapInt32(&r.used, 0, 1) {
- // First use of randomness. Start timer to warn about
- // being blocked on entropy not being available.
- t := time.AfterFunc(60*time.Second, warnBlocked)
- defer t.Stop()
- }
- r.mu.Lock()
- if r.prov == 0 {
- const provType = syscall.PROV_RSA_FULL
- const flags = syscall.CRYPT_VERIFYCONTEXT | syscall.CRYPT_SILENT
- err := syscall.CryptAcquireContext(&r.prov, nil, nil, provType, flags)
- if err != nil {
- r.mu.Unlock()
- return 0, os.NewSyscallError("CryptAcquireContext", err)
- }
- }
- r.mu.Unlock()
+ // RtlGenRandom only accepts 2**32-1 bytes at a time, so truncate.
+ inputLen := uint32(len(b))
- if len(b) == 0 {
+ if inputLen == 0 {
return 0, nil
}
- err = syscall.CryptGenRandom(r.prov, uint32(len(b)), &b[0])
+
+ err = syscall.RtlGenRandom(&b[0], inputLen)
if err != nil {
- return 0, os.NewSyscallError("CryptGenRandom", err)
+ return 0, os.NewSyscallError("RtlGenRandom", err)
}
- return len(b), nil
+ return int(inputLen), nil
}
diff --git a/src/syscall/syscall_windows.go b/src/syscall/syscall_windows.go
index 40c43de..0eea2b8 100644
--- a/src/syscall/syscall_windows.go
+++ b/src/syscall/syscall_windows.go
@@ -234,6 +234,7 @@
//sys CryptAcquireContext(provhandle *Handle, container *uint16, provider *uint16, provtype uint32, flags uint32) (err error) = advapi32.CryptAcquireContextW
//sys CryptReleaseContext(provhandle Handle, flags uint32) (err error) = advapi32.CryptReleaseContext
//sys CryptGenRandom(provhandle Handle, buflen uint32, buf *byte) (err error) = advapi32.CryptGenRandom
+//sys RtlGenRandom(buf *uint8, bytes uint32) (err error) = advapi32.SystemFunction036
//sys GetEnvironmentStrings() (envs *uint16, err error) [failretval==nil] = kernel32.GetEnvironmentStringsW
//sys FreeEnvironmentStrings(envs *uint16) (err error) = kernel32.FreeEnvironmentStringsW
//sys GetEnvironmentVariable(name *uint16, buffer *uint16, size uint32) (n uint32, err error) = kernel32.GetEnvironmentVariableW
diff --git a/src/syscall/zsyscall_windows.go b/src/syscall/zsyscall_windows.go
index 2348f65..b4222f0 100644
--- a/src/syscall/zsyscall_windows.go
+++ b/src/syscall/zsyscall_windows.go
@@ -95,6 +95,7 @@
procCryptAcquireContextW = modadvapi32.NewProc("CryptAcquireContextW")
procCryptReleaseContext = modadvapi32.NewProc("CryptReleaseContext")
procCryptGenRandom = modadvapi32.NewProc("CryptGenRandom")
+ procSystemFunction036 = modadvapi32.NewProc("SystemFunction036")
procGetEnvironmentStringsW = modkernel32.NewProc("GetEnvironmentStringsW")
procFreeEnvironmentStringsW = modkernel32.NewProc("FreeEnvironmentStringsW")
procGetEnvironmentVariableW = modkernel32.NewProc("GetEnvironmentVariableW")
@@ -821,6 +822,18 @@
return
}
+func RtlGenRandom(buf *uint8, bytes uint32) (err error) {
+ r1, _, e1 := Syscall(procSystemFunction036.Addr(), 2, uintptr(unsafe.Pointer(buf)), uintptr(bytes), 0)
+ if r1 == 0 {
+ if e1 != 0 {
+ err = errnoErr(e1)
+ } else {
+ err = EINVAL
+ }
+ }
+ return
+}
+
func GetEnvironmentStrings() (envs *uint16, err error) {
r0, _, e1 := Syscall(procGetEnvironmentStringsW.Addr(), 0, 0, 0, 0)
envs = (*uint16)(unsafe.Pointer(r0))
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Austin Clements (Gerrit)
1 comment:
Patchset:
This introduces an unsafe API. I realized we already have a bunch of these in the syscall package for Windows, but we've avoided unsafe APIs on other platforms. Is there a reason this can't take a []byte instead of a pointer and an unchecked length?
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Russ Cox (Gerrit)
Attention is currently required from: Jason A. Donenfeld.
1 comment:
Patchset:
This introduces an unsafe API. […]
Indeed. This should be moved to internal/syscall/windows.
We don't add new exported API to package syscall too.
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Austin Clements (Gerrit)
Patchset:
Indeed. This should be moved to internal/syscall/windows. […]
Filed golang.org/issue/43704 to track this.
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.
Jason A. Donenfeld (Gerrit)
1 comment:
Patchset:
Filed golang.org/issue/43704 to track this.
I will fix it.
To view, visit change 210057. To unsubscribe, or for help writing mail filters, visit settings.