profile
viewpoint
Joseph Richey josephlr @google Seattle, Washington Google Engineer working on Cloud Security. University of Michigan 2016 Grad Mathematics/CS

google/fscrypt 480

Go tool for managing Linux filesystem encryption

google/fscryptctl 54

Small C tool for Linux filesystem encryption

josephlr/argon2rs 0

The pure-Rust password hashing library running on Argon2.

josephlr/bootloader 0

An experimental pure-Rust x86 bootloader

josephlr/cargo-web 0

A Cargo subcommand for the client-side Web

josephlr/cli 0

A simple, fast, and fun package for building command line apps in Go

josephlr/cms 0

CMS (PKCS#7) library for Go

josephlr/cobra 0

A Commander for modern Go CLI interactions

josephlr/compiler-builtins 0

Porting `compiler-rt` intrinsics to Rust

PR opened rust-random/getrandom

Reviewers
Backport #165

Solves #164 for the v0.1 branch

Signed-off-by: Joe Richey joerichey@google.com

+25 -13

0 comment

2 changed files

pr created time in a day

create barnchjosephlr/getrandom

branch : backport

created branch time in a day

pull request commentrust-random/getrandom

Enable v0.1 std-trait workaround for additional targets

@pie-flavor can you verify that this fixes your problem.

josephlr

comment created time in a day

push eventjosephlr/getrandom

Joe Richey

commit sha 14dd9ea3527582b5488d7bfdecddbdddc2dededb

Enable CI for 0.1 branch Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in a day

PR opened rust-random/getrandom

Reviewers
Enable travis for 0.1 branch

Signed-off-by: Joe Richey joerichey@google.com

+2 -2

0 comment

2 changed files

pr created time in a day

push eventjosephlr/getrandom

Joe Richey

commit sha 01ab177d40adcc4f40cb368cc2e55791389a8e1a

Enable travis for 0.1 branch Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in a day

push eventjosephlr/getrandom

Joe Richey

commit sha e35b66a45ad6652e2fc1343e4fc09732ee7d5a0f

Enable travis for 0.1 branch Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in a day

PR opened rust-random/getrandom

Reviewers
Enable v0.1 std-trait workaround for additional targets

Fixes #168

The first commit cleans up how we handle our various helper modules (similar to what we did for v0.2), but does not make any functional changes.

The second commit enables our std::error::Error implementations for windows, target_os = "fuchsia", target_os = "ios". These are the additional windows and unix targets we supported in v0.1.6. We don't enable the workaround for target_arch = "wasm32" as that would be a breaking change (from newer version) for no_std wasm32 targets.

Here is a history of when we've enabled std::error::Error implementations:

  • v0.1.0 - v0.1.6:
    • Initially, we enabled the std feature on most targets
    #[cfg(any(
      feature = "std",
      windows, unix,
      target_os = "redox",
      target_arch = "wasm32",
    ))]
    
  • v0.1.7 - v0.1.8:
    • We later restricted the implementations to certain unix targets that needed util_libc
    #[cfg(any(
      feature = "std",
      target_os = "android",
      target_os = "dragonfly",
      target_os = "emscripten",
      target_os = "freebsd",
      target_os = "haiku",
      target_os = "illumos",
      target_os = "linux",
      target_os = "macos",
      target_os = "netbsd",
      target_os = "openbsd",
      target_os = "redox",
      target_os = "solaris",
    ))]
    
  • v0.1.9 - v0.1.10:
    • We further restricted things to only the "std" feature
    #[cfg(feature = "std")]
    
  • v0.1.11 - v0.1.15
    • We rolled back our v0.1.9 changes (as they were a breaking change)
    #[cfg(any(
      feature = "std",
      target_os = "android",
      target_os = "dragonfly",
      target_os = "emscripten",
      target_os = "freebsd",
      target_os = "haiku",
      target_os = "illumos",
      target_os = "linux",
      target_os = "macos",
      target_os = "netbsd",
      target_os = "openbsd",
      target_os = "redox",
      target_os = "solaris",
    ))]
    
+35 -24

0 comment

3 changed files

pr created time in a day

push eventjosephlr/getrandom

Joe Richey

commit sha 1a3d206d02fe715c169ed8e33d14e5619deb3296

Enable std-trait workaround for windows/unix targets From `v0.1.0` to `v0.1.6` we had this enabled for windows/unix, and we inadvertantly removed it. Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in a day

create barnchjosephlr/getrandom

branch : 0.1

created branch time in 2 days

issue commentgoogle/fscrypt

Bash completion for the fscrypt command

Yes we would be interested, I'm wondering if it's possible to generate the autocompletions directly from the source code.

audeoudh

comment created time in 2 days

pull request commentKeats/rust-bcrypt

Add getrandom/std to bcrypt/std

It is, but a fix for 0.8.x would still be nice for those who can't or don't want to update to 0.9.x.

I think we should just be able to add a bugfix for getrandom 0.1, so there shouldn't be a need for a bcrypt 0.8 fix.

pie-flavor

comment created time in 2 days

IssuesEvent

issue commentrust-random/getrandom

Breaking change re: Error implementations on Windows

@josephlr 0.1.6 did, though. That just means the break took place slightly earlier.

Good catch, reopening.

pie-flavor

comment created time in 2 days

PullRequestReviewEvent

issue closedrust-random/getrandom

Breaking change re: Error implementations on Windows

The re-addition of the default-implementations of std::error::Error without the std feature got all the relevant Linux platforms, but missed Windows, making it still a breaking change. I'm experiencing this issue downstream from bcrypt, which no longer compiles on Windows without overriding the getrandom dep.

closed time in 3 days

pie-flavor

issue commentrust-random/getrandom

Breaking change re: Error implementations on Windows

IIRC std stuff never worked on Windows in the first place, so it's not a breaking change, but an inconsistency between Linux and Windows targets.

You're right.

I confirmed that v0.1.8 never had the std::error::Error implementations for Windows (unless you had the "std" feature enabled). So the removal and readding were not breaking changes on Windows. Closing as not a bug.

pie-flavor

comment created time in 3 days

push eventjosephlr/getrandom

Jurgis

commit sha c29dd5f80e7c32836dfe6838bb582191dd154a19

Fix multithreaded wasm crash (solves #164) (#165) Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 3 days

issue closedrust-random/getrandom

Exception on multithreaded wasm

I'm building a project (bevy) on multithreaded wasm via web workers and this library crashes with exception:

Uncaught (in promise) TypeError: Failed to execute 'getRandomValues' on 'Crypto': The provided ArrayBufferView value must not be shared.

Indeed the spec does not allow generating random numbers into a memory backed by SharedArrayBuffer.

I managed to fix this issue by generating numbers into an intermediate buffer allocated by javascript:

for chunk in dest.chunks_mut(65536) {
    let arr = js_sys::Uint8Array::new_with_length(chunk.len() as u32);
    n.get_random_values(&arr);
    arr.copy_to(chunk);
}

This introduces some overhead, but I'm not sure if there is a standard way to check whether rust's memory is backed by SharedArrayBuffer.

I can submit a PR for this, so let me know how you want me to proceed.

closed time in 3 days

chemicstry

issue commentrust-random/getrandom

Exception on multithreaded wasm

It looks like #165 fixed this problem, closin. Backport for v0.1 (if it happends) can be tracked separtely.

chemicstry

comment created time in 3 days

push eventrust-random/getrandom

Jurgis

commit sha c29dd5f80e7c32836dfe6838bb582191dd154a19

Fix multithreaded wasm crash (solves #164) (#165) Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 3 days

PR merged rust-random/getrandom

Fix multithreaded wasm crash (solves #164)

This solves #164 by using a preallocated Uint8Array for calling crypto.getRandomValues.

The stdweb implementation seems fine, as it already uses Uint8Array.

Should this fix be backported to 0.15? There are a lot of crates that still use that version.

+22 -14

2 comments

3 changed files

chemicstry

pr closed time in 3 days

PR opened rust-lang/rust

Add compiler support for LLVM's x86_64 ERMSB feature

This change is needed for compiler-builtins to check for this feature when implementing memcpy/memset. See: https://github.com/rust-lang/compiler-builtins/pull/365

Without this change, the following code compiles, but does nothing:

#[cfg(target_feature = "ermsb")]
pub unsafe fn ermsb_memcpy() { ... }

The change just does compile-time detection. I think that runtime detection will have to come in a follow-up CL to std-detect.

Like all the CPU feature flags, this just references #44839

Signed-off-by: Joe Richey joerichey@google.com

+6 -1

0 comment

6 changed files

pr created time in 4 days

pull request commentgoogle/go-tpm

Implement some additional hierarchy control and dictionary attack functions for TPM2

The CLA stuff shouldn't be a problem, as Cannonical has singed a new CLA w/ Google since the last update here. If there's still an issue, I'll manually override the CI if a rebase doesn't get the check to work correctly.

If @chrisccoulson is willing to rebase this on latest master (see #163 which implemented some of this functionality), I'd merge it.

chrisccoulson

comment created time in 4 days

pull request commentrust-lang/compiler-builtins

Set the "asm" feature flag by default

@bjorn3 @alexcrichton would having a clif feature for this crate work better? It would make it clear why the feature existed, and could also be used to disable other things Cranelift doesn't support (like stack probes). This also make the Cranelift workarounds opt-it. So -Zbuild-std can use everything normally, and all cg_clif has to do is enable the clif feature on this crate.

This also means that as cg_clif supports more of Rust, we can disable these workarounds without changing the external feature set.

josephlr

comment created time in 4 days

push eventchemicstry/getrandom

Joe Richey

commit sha 1ee238c986309f6d4aa695a850243d61fa8cfecf

Try to fix CI Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 4 days

create barnchjosephlr/rust

branch : ermsb

created branch time in 4 days

PullRequestReviewEvent

push eventchemicstry/getrandom

Joe Richey

commit sha 4219cf0fa3ff8afe55bd712d704a6c09d3d352c4

Whitespace nits Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 4 days

issue commentrust-random/getrandom

Breaking change re: Error implementations on Windows

Look like this was resolved in https://github.com/Keats/rust-bcrypt/pull/57. However, we should still probably update the 0.1 branch to fix this. It was a breaking change, and adding the std stuff back for Windows shouldn't hurt anything.

pie-flavor

comment created time in 4 days

pull request commentrust-lang/rust-clippy

Enable empty_loop lint for no_std crates

@flip1995 this is now rebased and ready for review.

josephlr

comment created time in 4 days

push eventjosephlr/rust-clippy

Joe Richey

commit sha c39386afb2bfa2367ed463f324b8b48a32100892

Enable empty_loop lint for no_std crates We skip the lint if the `loop {}` is in the `#[panic_handler]` as the main recommendation we give is to panic, which obviously isn't possible in a panic handler. Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 4 days

push eventjosephlr/rust-clippy

Geoffrey Copin

commit sha bb0ce32423aefcb8b9eb587881973f56a6a6b0ee

Lint unnecessary int-to-int and float-to-float casts

view details

Tim Nielens

commit sha 915ce3608724e6c900d1b5eb4412cac2fcace33a

manual_unwrap_or / support Result::unwrap_or

view details

Takayuki Nakata

commit sha 114cb218f3ab2a709e3017c380790dd6e407132c

Remove an extra blank line in doc examples

view details

Patrick José Pereira

commit sha ec23db9496807f6c962b74fe0d6bf15be6c6d35b

Add linter for a single element for loop Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>

view details

Patrick José Pereira

commit sha ba1ca19c3bec20401a4cb13e5186c4c5952e94cc

tests: if_same_then_else2: Ignore single_element_loop lint Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>

view details

Tim Nielens

commit sha 65b52d84f83586752bff2834410e131290dc0155

needless-lifetime / multiple where clause predicates regression

view details

Daniel Smith

commit sha 57bf80f77626b134faaf2cd95664403627fba0da

Add lint for holding RefCell Ref across an await

view details

Daniel Smith

commit sha 8727169f7243c87e3708d99e9602562370f01a1a

fmt

view details

Daniel Smith

commit sha 070a751d4cf350a71901f75bc99ca0e0922a3133

update_lints

view details

Daniel Smith

commit sha 0f4abbf99a6f1ed783ea6935c83427c2aef95144

Better naming post copy/paste

view details

Daniel Smith

commit sha b3a427d8733a549b11f9bc88eceb31c857851411

Add another test case

view details

Daniel Smith

commit sha 3ed69cdb13e5953467f9d849d7ad480479ca01d6

Move existing lint into shared file

view details

Daniel Smith

commit sha ee20ebadafc9b2e4995015097e376c0a866d84af

Move refcell lint into shared module

view details

Daniel Smith

commit sha d8c6bce4407b1c99ed961f75a093ffe767818069

Convert the await holding lints to correctness

view details

Daniel Smith

commit sha 86f2b29d2ff33862264e2e6dfdc7cc20ad054ad1

Merge lints into one pass

view details

Daniel Smith

commit sha 4d3322525d9b65ce4c6fc183bc1cd3cfc9477300

Separate tests for each lint

view details

cgm616

commit sha 4a4f998c39b1b7e06c34a5fc8ed90e8752142e20

Add new lint for undropped ManuallyDrop values

view details

cgm616

commit sha e70817e712fd4d4e930ead0d587031e2b4a97a2e

Update tests and add known problems to docs

view details

Andre Bogus

commit sha c693de350aff4a3930e66bccf65caf79b390dca2

New lint: manual-range-contains

view details

varkor

commit sha fcde7683fe7ca10c83e5bc17f0969d2284affcd2

Fix clippy tests

view details

push time in 4 days

delete branch josephlr/rust-clippy

delete branch : empty-loop-no-std

delete time in 4 days

push eventjosephlr/rust-clippy

Geoffrey Copin

commit sha bb0ce32423aefcb8b9eb587881973f56a6a6b0ee

Lint unnecessary int-to-int and float-to-float casts

view details

Tim Nielens

commit sha 915ce3608724e6c900d1b5eb4412cac2fcace33a

manual_unwrap_or / support Result::unwrap_or

view details

Takayuki Nakata

commit sha 114cb218f3ab2a709e3017c380790dd6e407132c

Remove an extra blank line in doc examples

view details

Patrick José Pereira

commit sha ec23db9496807f6c962b74fe0d6bf15be6c6d35b

Add linter for a single element for loop Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>

view details

Patrick José Pereira

commit sha ba1ca19c3bec20401a4cb13e5186c4c5952e94cc

tests: if_same_then_else2: Ignore single_element_loop lint Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>

view details

Tim Nielens

commit sha 65b52d84f83586752bff2834410e131290dc0155

needless-lifetime / multiple where clause predicates regression

view details

Daniel Smith

commit sha 57bf80f77626b134faaf2cd95664403627fba0da

Add lint for holding RefCell Ref across an await

view details

Daniel Smith

commit sha 8727169f7243c87e3708d99e9602562370f01a1a

fmt

view details

Daniel Smith

commit sha 070a751d4cf350a71901f75bc99ca0e0922a3133

update_lints

view details

Daniel Smith

commit sha 0f4abbf99a6f1ed783ea6935c83427c2aef95144

Better naming post copy/paste

view details

Daniel Smith

commit sha b3a427d8733a549b11f9bc88eceb31c857851411

Add another test case

view details

Daniel Smith

commit sha 3ed69cdb13e5953467f9d849d7ad480479ca01d6

Move existing lint into shared file

view details

Daniel Smith

commit sha ee20ebadafc9b2e4995015097e376c0a866d84af

Move refcell lint into shared module

view details

Daniel Smith

commit sha d8c6bce4407b1c99ed961f75a093ffe767818069

Convert the await holding lints to correctness

view details

Daniel Smith

commit sha 86f2b29d2ff33862264e2e6dfdc7cc20ad054ad1

Merge lints into one pass

view details

Daniel Smith

commit sha 4d3322525d9b65ce4c6fc183bc1cd3cfc9477300

Separate tests for each lint

view details

cgm616

commit sha 4a4f998c39b1b7e06c34a5fc8ed90e8752142e20

Add new lint for undropped ManuallyDrop values

view details

cgm616

commit sha e70817e712fd4d4e930ead0d587031e2b4a97a2e

Update tests and add known problems to docs

view details

Andre Bogus

commit sha c693de350aff4a3930e66bccf65caf79b390dca2

New lint: manual-range-contains

view details

varkor

commit sha fcde7683fe7ca10c83e5bc17f0969d2284affcd2

Fix clippy tests

view details

push time in 4 days

delete branch josephlr/compiler-builtins

delete branch : byte-asm

delete time in 4 days

delete branch josephlr/compiler-builtins

delete branch : ermsb

delete time in 4 days

push eventjosephlr/compiler-builtins

Joseph Richey

commit sha 33ad3669db0ac78a917aee787304d1391b6dc676

Use REP MOVSQ/STOSQ on x86_64 (#365) * mem: Move mem* functions to separate directory Signed-off-by: Joe Richey <joerichey@google.com> * memcpy: Create separate memcpy.rs file Signed-off-by: Joe Richey <joerichey@google.com> * benches: Add benchmarks for mem* functions This allows comparing the "normal" implementations to the implementations provided by this crate. Signed-off-by: Joe Richey <joerichey@google.com> * mem: Add REP MOVSB/STOSB implementations The assembly generated seems correct: https://rust.godbolt.org/z/GGnec8 Signed-off-by: Joe Richey <joerichey@google.com> * mem: Add documentations for REP string insturctions Signed-off-by: Joe Richey <joerichey@google.com> * Use quad-word rep string instructions Signed-off-by: Joe Richey <joerichey@google.com> * Prevent panic when compiled in debug mode Signed-off-by: Joe Richey <joerichey@google.com> * Add tests for mem* functions Signed-off-by: Joe Richey <joerichey@google.com> * Add build/test with the "asm" feature Signed-off-by: Joe Richey <joerichey@google.com> * Add byte length to Bencher Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 4 days

pull request commentrust-lang/compiler-builtins

Use REP MOVSQ/STOSQ on x86_64

Thanks again for this! This all looks great to me. As one final thing, though, I'm not sure if the asm feature is actually ever enabled on CI, so could you add a line here to test the feature?

Done (for tests and builds), also the testcrate enables the "asm" feature by default, should that be changed?

josephlr

comment created time in 6 days

Pull request review commentrust-lang/compiler-builtins

Use REP MOVSQ/STOSQ on x86_64

+#![feature(test)]++extern crate test;+use test::{black_box, Bencher};++extern crate compiler_builtins;+use compiler_builtins::mem::{memcmp, memcpy, memmove, memset};++fn memcpy_builtin(b: &mut Bencher, n: usize) {+    let v1 = vec![1u8; n];+    let mut v2 = vec![0u8; n];+    b.iter(|| {

Nice, that's much better than doing the math normally.

josephlr

comment created time in 6 days

PullRequestReviewEvent

push eventjosephlr/compiler-builtins

Joe Richey

commit sha aa326a3abd0d82ff3c9cc2881d9dd07a0cb815ba

Add build/test with the "asm" feature Signed-off-by: Joe Richey <joerichey@google.com>

view details

Joe Richey

commit sha d4a180ad739cb2e61fbab7903b390cae98d6035d

Add byte length to Bencher Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 6 days

issue commentgoogle/fscrypt

Can not change login protector

@kamentomov let me know if the stuff in Step 3 above helps you setup a login protector on the new system.

kamentomov

comment created time in 6 days

issue commentgoogle/fscrypt

Can not change login protector

Thanks for bringing this up @kamentomov. What version of fscrypt are you using? You can run fscrypt --version to find out (current version is 0.2.9).

I was able to reproduce some of your problems. Good news, there's probably a workaround.

Step 1

I created an encrypted directory on a removable drive on System 1. This had two protectors:

  • A login protector for System 1
  • A passphrase protector

This was setup using fscrypt encrypt, fscrypt metadata create protector, and fscrypt metadata add-protector-to-policy, but on newer versions of fscrypt this can also be done automatically (when using a linked protector on a filesystem).

Output of fscrypt status /run/media/joe/Test:

ext4 filesystem "/run/media/joe/Test" has 2 protectors and 1 policy

PROTECTOR         LINKED   DESCRIPTION
03f8914bb6167978  Yes (/)  login protector for joe
ccee3490616f11ef  No       custom protector "Test Password"

POLICY                            UNLOCKED  PROTECTORS
418c630b4d88edf215eab2eb9f49ae1e  No        03f8914bb6167978, ccee3490616f11ef

Step 2

I then attached this drive to System 2. Here's where I encountered bug 1. Running fscrypt status on the newly mounted filesystem gives:

ext4 filesystem "/run/media/joe/847dda65-d5ee-4ebd-bcc5-132ce9255787" has 3 protectors and 1 policy

PROTECTOR         LINKED   DESCRIPTION
                           [/run/media/joe/847dda65-d5ee-4ebd-bcc5-132ce9255787/.fscrypt/protectors/03f8914bb6167978.link: cannot follow filesystem link "UUID=1769bc73-bedb-4f9b-a07b-5602d6e0481c": no device with UUID 1769bc73-bedb-4f9b-a07b-5602d6e0481c]
ccee3490616f11ef  No       custom protector "Test Password"

POLICY                            UNLOCKED  PROTECTORS
418c630b4d88edf215eab2eb9f49ae1e  Yes       03f8914bb6167978, ccee3490616f11ef

Essentially, this is saying protector 03f8914bb6167978 doesn't exist on the current system, which makes sense. That protector was a login protector, only on the old system.

Step 3

Before we remove the old login protector, we should protect the directory with a login protector on the new system.

First we create the login protector with fscrypt metadata create protector /. This login protector may already exist if you have already protected directories on the new system with your login password.

Next, we protect the directory with the new protector:

sudo fscrypt metadata add-protector-to-policy --protector=/:1c9865cfe4acf5d7 --policy=/mnt:418c630b4d88edf215eab2eb9f49ae1e

This might cause some strange output as fscrypt tries to load the linked login protector which doesn't exist on the new system, but you still should be able to do it. We now have fscrypt status /mnt output of:

ext4 filesystem "/mnt" has 3 protectors and 1 policy

PROTECTOR         LINKED   DESCRIPTION
                           [/run/media/joe/847dda65-d5ee-4ebd-bcc5-132ce9255787/.fscrypt/protectors/03f8914bb6167978.link: cannot follow filesystem link "UUID=1769bc73-bedb-4f9b-a07b-5602d6e0481c": no device with UUID 1769bc73-bedb-4f9b-a07b-5602d6e0481c]
ccee3490616f11ef  No       custom protector "Test Password"
1c9865cfe4acf5d7  Yes (/)  login protector for joe

POLICY                            UNLOCKED  PROTECTORS
418c630b4d88edf215eab2eb9f49ae1e  Yes       03f8914bb6167978, ccee3490616f11ef, 1c9865cfe4acf5d7

Using this directory will now work normally.

Step 4

Now we have this weird remaining protector 03f8914bb6167978 that we no longer need on the new system. So we can remove it. Here's where the second bug turns up. We would ideally remove this with fscrypt metadata destroy --protector=.:03f8914bb6167978. However, this protector exists on a system that we're not using, so we get an error about loading the metadata (which is what you're seeing in the above error message).

Right now removing this unnecessary protector is not possible (not that it really harms anything). Ideally, we would have --force remove the remaining links even if they don't exist.

kamentomov

comment created time in 6 days

issue commentrust-osdev/x86_64

Address is not correctly shifted in page table entries

Thanks for looking at this @elegaanz, the function in this crate is correct.

This is because the physical address is already aligned to 4K bytes (so the lower 12 bits of the physical address are already zero). The page table entry doesn't shift the physical address, it uses the fact that some bits must be zero, and then uses those bits to store flags.

Sometimes physical page numbers (PPNs) will be used instead of the physical address. For PPNs, you do have to shift left by 12, as the phsyical address 0x12000 has a PPN of 0x12.

Does that make sense?

elegaanz

comment created time in 7 days

Pull request review commentrust-random/getrandom

Fix multithreaded wasm crash (solves #164)

 use crate::Error; extern crate std; use std::thread_local; +use js_sys::Uint8Array; use wasm_bindgen::prelude::*; +// Maximum is 65536 bytes see https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues+const BROWSER_CRYPTO_BUFFER_SIZE: usize = 256;++struct BrowserCryptoContext {+    crypto: BrowserCrypto,+    // A temporary buffer backed by browser memory to avoid multithreaded wasm exception. See issue #164+    buf: Uint8Array,+}+

Yes, fixing this would be preferable (I can also do it when i have time).

chemicstry

comment created time in 7 days

PullRequestReviewEvent

push eventjosephlr/compiler-builtins

Joe Richey

commit sha fe71a12173682a633add9292bd84035234d3bf9a

Add tests for mem* functions Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 7 days

pull request commentrust-lang/compiler-builtins

Use REP MOVSQ/STOSQ on x86_64

@alexcrichton the tests have been added so this is now ready for final review and merging.

This implementation sticks with the rep movsq/rep stosq implementation used by MUSL and Linux (see the links in the PR description). The final assembly looks optimal (memcpy/memset are identical to Linux's implementation).

For performance numbers, see my link in https://github.com/rust-lang/compiler-builtins/pull/365#issuecomment-710842993

josephlr

comment created time in 7 days

push eventjosephlr/compiler-builtins

Joe Richey

commit sha de4ed289ff88631de7d76fd985f846d768320381

Prevent panic when compiled in debug mode Signed-off-by: Joe Richey <joerichey@google.com>

view details

Joe Richey

commit sha f72f6fc46f1170aac0306c8b579528b687f3d4b5

Add tests for mem* functions Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 7 days

push eventjosephlr/rust-clippy

Joe Richey

commit sha a29a4d491999a1cf4246199b7daee930b20bcf72

Enable empty_loop lint for no_std crates We skip the lint if the `loop {}` is in the `#[panic_handler]` as the main recommendation we give is to panic, which obviously isn't possible in a panic handler. Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 7 days

PR opened rust-lang/rust-clippy

Enable empty_loop lint for no_std crates

Followup to #6162. Fixes #6161

We skip the lint if the loop {} is in the #[panic_handler] as the main recommendation we give is to panic, which obviously isn't possible in a panic handler.

changelog: Enable empty_loop lint for no_std crates

+80 -20

0 comment

6 changed files

pr created time in 7 days

create barnchjosephlr/rust-clippy

branch : empty-loop2

created branch time in 7 days

issue commentrust-lang/rust-clippy

Lint: enable empty_loop for no_std crates

I've updated the description for this issue to make it clear this is no longer about undefined behavior. Now, this issue just tracks re-enabling the style lint for no_std libraries. Even for no_std libraries, it's probably a good idea to for use to have a lint that says "hey, you should panic instead of deadlooping".

I think we should either:

  • Enable this lint for no_std libraries, disabling it in no_std binaries
  • Enable this lint for no_std libraries and binaries, but disable it inside #[panic_handler]
josephlr

comment created time in 7 days

pull request commentrust-lang/rust-clippy

Update empty_loop documentation/message.

IMO we could keep the more detailed documentation regarding the case of burning CPU, but I think the lint should go back to warn-by-default and ignore no_std

@ebroto @jyn514 I've updated this PR to do just this. But I've added a TODO to address #6161. I think we would ideally have this still trigger for no_std crates (as it's still bad style, in general). If we could somehow avoid firing this lint for #[panic_handler], we could enable it everywhere else.

But this sort of discussion can be continued in #6161.

josephlr

comment created time in 7 days

push eventjosephlr/rust-clippy

hosseind75

commit sha ecd308ec394f9d01b4392ee0315ea64d52ab7caa

ICEs should print the top of the query stack

view details

hosseind75

commit sha a9053e4baf251f53d8d6b95cd3f5b8a829ad0ba6

run full query stack print just when RUST_BACKTRACE is set

view details

hosseind75

commit sha 49bc85e947ab7ca793c14b6f3af4a8e9d8db0337

fix clippy custom_ice_message test

view details

hosseind75

commit sha 7f07577e6f873f4a1b3428d29bf520189f4ef79e

add new line

view details

hosseind75

commit sha 3c94914f0c87ba00987e515063dcc9e079a8918d

rebase with master

view details

ThibsG

commit sha 32fdb8fb0c15ddc202eed70b82babca8d529e39b

Lint on identical variable used as args in `assert_eq!` macro call

view details

Chris Ayoup

commit sha 8c28ba39b573c0d9be2ce7aa3cfc60757f3c81e6

suggest a compatible shell for running setup-toolchain.sh setup-toolchain.sh uses "[[" which is a bash builtin, but the guide suggests running it with sh. On Ubuntu, /bin/sh points to dash and running the script as described fails.

view details

ThibsG

commit sha a3e0446afe0ebd7a420f65cd6aec1c56687f0ef5

Extend to the `assert` macro family

view details

ThibsG

commit sha 121a047645270d5e9ac965d57c324301ea1f21c0

Move linting of `assert` macros from early to late pass

view details

hosseind88

commit sha ab0fc477b8b83cb14c584aca281b16fb5cce4c1a

fix stderr file of clippy/custom_ice_message test

view details

ThibsG

commit sha 71c29b5be8526562c3de8d3b7dc94611647ee120

Add iterator test case for `eq_op` lint

view details

Tim Nielens

commit sha 07b2da884cda8103af50beb327723dec8204fc61

add lint less_concise_than_option_unwrap_or

view details

Tim Nielens

commit sha 9c9327980becadc15a68307705b3a06c28116ae1

manual-unwrap-or / rename files

view details

Tim Nielens

commit sha 6d4eeeabcda6d6d25738e1e8e2b64580daefc4b9

manual-unwrap-or / pr remarks

view details

Tim Nielens

commit sha fc846c37fcc720c4a5c2e2075102c1957433e703

manual_unwrap_or / use consts::constant_simple helper

view details

Tim Nielens

commit sha a8fb69f065a427f5d3fc7222b834cad9a2a7a712

manual-unwrap-or / more pr remarks

view details

Tim Nielens

commit sha 690a6a6c0eff1a3edeb5f4c2dcbf9994760c3184

manual-unwrap-or / remove unwrap_or_else suggestion due to ownership issues

view details

est31

commit sha 2c1e8cfc622652ebfb1f0256aa8d2afae91bf416

Remove rustc_session::config::Config The wrapper type led to tons of target.target across the compiler. Its ptr_width field isn't required any more, as target_pointer_width is already present in parsed form.

view details

Dylan DPC

commit sha d2feccc1efcbeff9dfb99daa754b8b47cdac7eaf

Rollup merge of #77493 - hosseind88:ICEs_should_always_print_the_top_of_the_query_stack, r=oli-obk ICEs should always print the top of the query stack see #76920

view details

Joe Richey

commit sha ef91de640294e6d0fbf881082196ba83379ea447

Run cargo dev fmt Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 7 days

push eventjosephlr/rust-clippy

ThibsG

commit sha 32fdb8fb0c15ddc202eed70b82babca8d529e39b

Lint on identical variable used as args in `assert_eq!` macro call

view details

Chris Ayoup

commit sha 8c28ba39b573c0d9be2ce7aa3cfc60757f3c81e6

suggest a compatible shell for running setup-toolchain.sh setup-toolchain.sh uses "[[" which is a bash builtin, but the guide suggests running it with sh. On Ubuntu, /bin/sh points to dash and running the script as described fails.

view details

ThibsG

commit sha a3e0446afe0ebd7a420f65cd6aec1c56687f0ef5

Extend to the `assert` macro family

view details

ThibsG

commit sha 121a047645270d5e9ac965d57c324301ea1f21c0

Move linting of `assert` macros from early to late pass

view details

ThibsG

commit sha 71c29b5be8526562c3de8d3b7dc94611647ee120

Add iterator test case for `eq_op` lint

view details

Tim Nielens

commit sha 07b2da884cda8103af50beb327723dec8204fc61

add lint less_concise_than_option_unwrap_or

view details

Tim Nielens

commit sha 9c9327980becadc15a68307705b3a06c28116ae1

manual-unwrap-or / rename files

view details

Tim Nielens

commit sha 6d4eeeabcda6d6d25738e1e8e2b64580daefc4b9

manual-unwrap-or / pr remarks

view details

Tim Nielens

commit sha fc846c37fcc720c4a5c2e2075102c1957433e703

manual_unwrap_or / use consts::constant_simple helper

view details

Tim Nielens

commit sha a8fb69f065a427f5d3fc7222b834cad9a2a7a712

manual-unwrap-or / more pr remarks

view details

Tim Nielens

commit sha 690a6a6c0eff1a3edeb5f4c2dcbf9994760c3184

manual-unwrap-or / remove unwrap_or_else suggestion due to ownership issues

view details

flip1995

commit sha 6d358d29b0eb4e6f21526ccfb29636dea20d8993

Update semver 0.10 -> 0.11

view details

bors

commit sha e351e5ca693d52abc63b3737ab2abeff0aef15ad

Auto merge of #6180 - flip1995:rustup, r=flip1995 Update semver 0.10 -> 0.11 r? `@ghost,` blocking CI changelog: none

view details

Eduardo Broto

commit sha 701c7e2fbac1f05064519f0800128ea92491689a

bump cargo_metadata version

view details

Santiago Pastorino

commit sha 0af467ebf2da4994aee56b2b70c59028170a88ba

Handle ExprKind::ConstBlock on clippy

view details

bors

commit sha 81890c541e2da0d22992237c78190379b7497bb4

Auto merge of #6184 - ebroto:bump_cargo_metadata, r=ebroto bump cargo_metadata version changelog: none r? `@ghost` (master broken)

view details

bors

commit sha 4e83a38618cb6160cf6a7297ed3413f434149242

Auto merge of #6123 - montrivo:less_concise_than, r=ebroto add lint manual_unwrap_or Implements partially #5923. changelog: add lint manual_unwrap_or

view details

ThibsG

commit sha 5a13217ea9c07121e7d3cdcfb0ddd2aa52b90f12

Assert macro args extractor as a common function in higher

view details

Jacob Hughes

commit sha 29392a1728df1b334b48115ad24cc592f04ca15e

Appease the almightly lord clippy, hallowed be thy name

view details

Yuki Okushi

commit sha 82f775d2c4fd25615d7db2a5340aae0ee9f9901b

Rollup merge of #77851 - exrook:split-btreemap, r=dtolnay BTreeMap: refactor Entry out of map.rs into its own file btree/map.rs is approaching the 3000 line mark, splitting out the entry code buys about 500 lines of headroom. I've created this PR because the changes I've made in #77438 will push `map.rs` over the 3000 line limit and cause tidy to complain. I picked `Entry` to factor out because it feels less tightly coupled to the rest of `BTreeMap` than the various iterator implementations. Related: #60302

view details

push time in 7 days

pull request commentrust-lang/compiler-builtins

Use REP MOVSQ/STOSQ on x86_64

@Soveu and what do you get with the 'rep movsb' implementation on AMD. I.e. running the benchmarks against https://github.com/rust-lang/compiler-builtins/pull/365/commits/2a0132cfae362f429b6da7b5ba206ee20ec9aa1f

josephlr

comment created time in 11 days

pull request commentrust-lang/compiler-builtins

Use REP MOVSQ/STOSQ on x86_64

idk if i messed up something with constants or something, ryzen 2500u performance looks at best like movsb from sandybridge movsb is as fast as movsq

Was that with the benchmarks in this PR?

josephlr

comment created time in 11 days

pull request commentrust-lang/compiler-builtins

Use REP MOVSQ/STOSQ on x86_64

Are you sure you have been benchmarking it properly?

The benchmark code is in this PR, let me know if you find any issues. The results I found above seem consistent with what the Intel/AMD optimization manuals would suggest. Note that the benchmarks here are not intended to be fully comprehensive, just to give a rough idea of the perf.

gamozo found very interesting patterns in rep movsb behaviour, that are reproducible on my sandybridge laptop (tommorow i'll test it on ryzen)

As they mention, it seems mostly like a cache effect, so I'm not sure how much the actual memcpy implementation matters here, but it looks like going with rep movsq is the right move.

josephlr

comment created time in 12 days

Pull request review commentrust-osdev/x86_64

Add ability to add iomap to TSS (take 2)

 impl Descriptor {     /// Creates a TSS system descriptor for the given TSS.     #[inline]     pub fn tss_segment(tss: &'static TaskStateSegment) -> Descriptor {+        // SAFETY: if iomap_size is zero, there are no requirements to uphold.+        unsafe { Self::tss_segment_raw(tss, 0) }+    }++    /// Creates a TSS system descriptor for the given TSS, setting up the IO permissions bitmap.+    pub fn tss_segment_with_iomap(+        tss: &'static TaskStateSegment,+        iomap: &'static [u8],+    ) -> Result<Descriptor, InvalidIoMap> {+        if iomap.len() > 8193 {+            return Err(InvalidIoMap::TooLong { len: iomap.len() });+        }++        let base = iomap.as_ptr() as usize - tss as *const _ as usize;

We need to use wrapping_offset_from here and get an isize. We need to deal with isizes because the iomap could come before the tss, and that would also be wrong.

Restioson

comment created time in 13 days

PullRequestReviewEvent

Pull request review commentrust-osdev/x86_64

Add ability to add iomap to TSS (take 2)

 impl Descriptor {     /// Creates a TSS system descriptor for the given TSS.     #[inline]     pub fn tss_segment(tss: &'static TaskStateSegment) -> Descriptor {+        // SAFETY: if iomap_size is zero, there are no requirements to uphold.+        unsafe { Self::tss_segment_with_iomap(tss, 0) }+    }++    /// Creates a TSS system descriptor for the given TSS, setting up the IO permissions bitmap.+    ///+    /// # Safety

I think it should just check that the iomap_base is correct, and return an error if it's wrong.

Restioson

comment created time in 13 days

PullRequestReviewEvent

Pull request review commentrust-osdev/x86_64

Add ability to add iomap to TSS (take 2)

 impl Descriptor {     /// Creates a TSS system descriptor for the given TSS.     #[inline]     pub fn tss_segment(tss: &'static TaskStateSegment) -> Descriptor {+        // SAFETY: if iomap_size is zero, there are no requirements to uphold.+        unsafe { Self::tss_segment_with_iomap(tss, 0) }+    }++    /// Creates a TSS system descriptor for the given TSS, setting up the IO permissions bitmap.+    ///+    /// # Safety

Later on, we could add a structure (the TssWithIoMap) to this library. That structure would make sure things stay valid (iomap_addr is correctly initialized, there's always a trailing 0xff byte, etc...) And we'd have a descriptor method on that structure that calls this method.

Restioson

comment created time in 13 days

PullRequestReviewEvent

Pull request review commentrust-osdev/x86_64

Add ability to add iomap to TSS (take 2)

 impl Descriptor {     /// Creates a TSS system descriptor for the given TSS.     #[inline]     pub fn tss_segment(tss: &'static TaskStateSegment) -> Descriptor {+        // SAFETY: if iomap_size is zero, there are no requirements to uphold.+        unsafe { Self::tss_segment_with_iomap(tss, 0) }+    }++    /// Creates a TSS system descriptor for the given TSS, setting up the IO permissions bitmap.+    ///+    /// # Safety

Ya I think the idea would be:

In this PR, we have a function that takes two arguements a TSS and a bitmap slice, and does the necessary checks. This allows for custom sized iomaps of any size/position.

This would allow users to definite their own TssWithIoMap structure, and then just call the method we define here.

Restioson

comment created time in 13 days

PullRequestReviewEvent

Pull request review commentrust-osdev/x86_64

Add ability to add iomap to TSS (take 2)

 impl Descriptor {         // base         low.set_bits(16..40, ptr.get_bits(0..24));         low.set_bits(56..64, ptr.get_bits(24..32));-        // limit (the `-1` in needed since the bound is inclusive)-        low.set_bits(0..16, (size_of::<TaskStateSegment>() - 1) as u64);+        // limit (the `-1` is needed since the bound is inclusive)+        let iomap_limit = tss.iomap_base as u64 + iomap_size as u64 - 1;+        low.set_bits(+            0..16,+            cmp::max(mem::size_of::<TaskStateSegment>() as u64, iomap_limit),

We need to do the subtraction after the ma

Restioson

comment created time in 13 days

PullRequestReviewEvent

Pull request review commentrust-osdev/x86_64

Add ability to add iomap to TSS (take 2)

 impl Descriptor {     /// Creates a TSS system descriptor for the given TSS.     #[inline]     pub fn tss_segment(tss: &'static TaskStateSegment) -> Descriptor {+        // SAFETY: if iomap_size is zero, there are no requirements to uphold.+        unsafe { Self::tss_segment_with_iomap(tss, 0) }+    }++    /// Creates a TSS system descriptor for the given TSS, setting up the IO permissions bitmap.+    ///+    /// # Safety

Either that or panic. We would need a custom error type for that (it could live in the tss module).

Restioson

comment created time in 13 days

PullRequestReviewEvent

issue commentrust-osdev/x86_64

The iomap_base of TaskStateSegment shouldn't be initialized to zero

It will depend on exactly what interface we end up with, but I think a separate PR will be better.

josephlr

comment created time in 13 days

push eventjosephlr/compiler-builtins

Joe Richey

commit sha 2a0132cfae362f429b6da7b5ba206ee20ec9aa1f

mem: Add documentations for REP string insturctions Signed-off-by: Joe Richey <joerichey@google.com>

view details

Joe Richey

commit sha aa75260e068348b11f36dfa90c06be1794a0d67d

Use quad-word rep string instructions Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 13 days

pull request commentrust-lang/compiler-builtins

Use REP MOVSQ/STOSQ on x86_64

I did some final benchmarking of various approaches here are the results. Long story short, the rep movsq/rep stosq are faster the their byte-based equivalents. This is especially notable on AMD where it's not even close (6x faster). The byte-based instructions were only faster in two senarios:

  • memcpy, in the forward direction, on Intel hardware with the erms capability.
  • memset, in the forward direction, on Intel hardware with the erms capability.

The PR title/description and the comments have been updated. The only thing left is to add tests for the memory functions.

Thanks for the feedback @andyhhp, comments inline.

Presumably here we're talking about mem*() calls which have survived through LLVM's optimisations passes, and are the variations which don't decompose nicely?

Correct. This is also why we aren't really concerned about short memcpys here, as they are usually directly inlined by LLVM.

If alignment information is available at compile time, then rep stos{l,q} is faster than rep stosb on earlier hardware.

Yes, this is true on essentially all AMD hardware and all Intel hardware without ERMSB ("Enhanced REP MOVSB/STOSB").

Intel have some forthcoming features literally named Fast Zero-Length MOVSB, Fast Short STOSB, Fast short CMPSB/SCASB (https://software.intel.com/content/dam/develop/external/us/en/documents/intel-tdx-module-1eas.pdf Page 120. Not sure if this was intended to be public right now, but it is.)

It looks like the TDX manual has the CPUID listing for Sapphire Rapids, and that the main Intel manual hasn't been updated yet. I would imagine these features will appear in the main SDM once it gets updated. I've update the file comment to also mention those features.

Frankly, study a popular libc and follow their lead. A lot of time and effort has gone into optimising them generally across multiple generations of processor.

Oh I definitely realize this. This PR is based off the implementations in MUSL and in the Linux kernel . I've updated the comments/descriptions to make this more clear (I referenced it in the comments). As @Soveu noted above, the kernel prefers rep movsb over rep movsq, but only when the erms feature is present. The above results would be seem to validate that approach.

Alternatively, if you do feel like doing feature-based dispatch, that will get better results if you can pick the optimum algorithm for the CPU you're on.

We may do compile-time feature dispatch in a followup CL (if people care). It would basically switch to the rep movsb-only variants if #[cfg(target_feature = "ermsb")].

josephlr

comment created time in 13 days

Pull request review commentrust-osdev/x86_64

Add ability to add iomap to TSS (take 2)

 impl Descriptor {     /// Creates a TSS system descriptor for the given TSS.     #[inline]     pub fn tss_segment(tss: &'static TaskStateSegment) -> Descriptor {+        // SAFETY: if iomap_size is zero, there are no requirements to uphold.+        unsafe { Self::tss_segment_with_iomap(tss, 0) }+    }++    /// Creates a TSS system descriptor for the given TSS, setting up the IO permissions bitmap.+    ///+    /// # Safety

I'm wondering if we could put enough checks here to make this method safe. We could take the IO map as a [u8] slice and then do all of the necessary checks (it's in range, byte past the end is all 1s, iomap_base is <= 0xDFFFH, etc..). We either need to do these checks or document all the requirements from the SDM in the # Safety section.

Restioson

comment created time in 13 days

Pull request review commentrust-osdev/x86_64

Add ability to add iomap to TSS (take 2)

 impl Descriptor {     /// Creates a TSS system descriptor for the given TSS.     #[inline]     pub fn tss_segment(tss: &'static TaskStateSegment) -> Descriptor {+        // SAFETY: if iomap_size is zero, there are no requirements to uphold.+        unsafe { Self::tss_segment_with_iomap(tss, 0) }+    }++    /// Creates a TSS system descriptor for the given TSS, setting up the IO permissions bitmap.+    ///+    /// # Safety+    ///+    /// If `iomap_size` is greater than zero, there **must** be a valid IO map at `tss_ptr + iomap_base`.

This might be more clear if Rust syntax was used,

There must be a valid IO map at `(tss as *const u8).offset(tss.iomap_base)` of length `iomap_size`
Restioson

comment created time in 13 days

Pull request review commentrust-osdev/x86_64

Add ability to add iomap to TSS (take 2)

 impl Descriptor {         // base         low.set_bits(16..40, ptr.get_bits(0..24));         low.set_bits(56..64, ptr.get_bits(24..32));-        // limit (the `-1` in needed since the bound is inclusive)-        low.set_bits(0..16, (size_of::<TaskStateSegment>() - 1) as u64);+        // limit (the `-1` is needed since the bound is inclusive)+        low.set_bits(+            0..16,+            (size_of::<TaskStateSegment>() + (tss.iomap_base + iomap_size) as usize - 1) as u64,

This doesn't seem correct. If I'm reading the SDM correctly, tss.iomap_base is relative to the start of the TSS not the end. So the limit should be:

max(size_of::<TaskStateSegment>(), tss.iomap_base + iomap_size as usize) as u64 - 1
Restioson

comment created time in 13 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventjosephlr/ring

BlackHoleFox

commit sha 8ebd8e451df4a53724a4d26e2f3220de78dccdf4

Fix a PBKDF2 documentation comment typo

view details

francescocarzaniga

commit sha 3dbfb785a8214b60f2525813a47da0c99a9cd417

Update Cargo.toml Add illumos support.

view details

francescocarzaniga

commit sha 020eb5422c4cd8b69bf1de98dbec0e148731f7b9

Update rand.rs Add illumos support.

view details

Joe Richey

commit sha ff0d3d78fcf06151f0cada9d883080ecf9c2e496

Update doc links to use correct branch It looks like *ring* is using `main` now. Signed-off-by: Joe Richey <joerichey@google.com>

view details

push time in 13 days

push eventjosephlr/compiler-builtins

Joe Richey

commit sha 29273147820a4047a997ac1af15010f47bdb8576

Raw byte-based asm for loop

view details

push time in 13 days

create barnchjosephlr/compiler-builtins

branch : byte-asm

created branch time in 13 days

pull request commentrust-osdev/x86_64

Add a `Mapper::map` convenience method

@phil-opp this looks reasonable to me. If you rebase, I can review.

phil-opp

comment created time in 14 days

issue openedrust-osdev/x86_64

Tracking issue for breaking changes

Many issues/PR currently proposed would break the API of this create. This seems reasonable, but we should try to consolidate changes as much as possible. This issue tracks these changes.

Add any breaking changes you're interested in:

  • [ ] Including PageTableFlags in the result of translate (https://github.com/rust-osdev/x86_64/pull/150)
  • [ ] Rename MapperAllSizes to Translate (https://github.com/rust-osdev/x86_64/issues/152)
  • [ ] Potentially changing which methods are required and which are provided for Mapper (https://github.com/rust-osdev/x86_64/issues/192)
  • [ ] Remove PhysFrameRange, PhysFrameRangeInclusive, PageRange, PageRangeInclusive to instead use the Rust types.
  • [ ] Make PhysToVirt actually map PhysAddr to VirtAddr (instead of returning a pointer)
  • [ ] Make DescriptorTablePointer::base a VirtAddr (makes it clear segmentation is applied before paging).
  • [ ] Make read_rip return a VirtAddr
  • [ ] Use correct types for InterruptStackFrameValue:
    • code_segment should be a SegmentSelector
    • cpu_flags should be a RFlags
    • stack_segment should be a SegmentSelector
  • [ ] Remove deprecated items:
    • UnusedPhysFrame
    • ExceptionStackFrame
    • VirtAddr::new_unchecked

created time in 14 days

issue commentrust-osdev/x86_64

Removing CR3 check from RecursivePageTable?

@phil-opp Do you think we should update the Safety section of RecursivePageTable::new_unchecked to reflect the above? Right now the docs are unclear here.

CWood1

comment created time in 14 days

issue commentrust-lang/rust-clippy

git subtree crashes: can't sync rustc clippy changes into rust-lang/rust-clippy

Only the first time. Once it is cached, it is a matter of seconds. Still not optimal though.

Yup, running again only took 20 seconds. The .git/subtree-cache is large (about 515 MiB for me), make sense why it took so long to generate (still seems like there has to be a better way).

matthiaskrgr

comment created time in 14 days

push eventjosephlr/rust-clippy

hosseind75

commit sha ecd308ec394f9d01b4392ee0315ea64d52ab7caa

ICEs should print the top of the query stack

view details

hosseind75

commit sha a9053e4baf251f53d8d6b95cd3f5b8a829ad0ba6

run full query stack print just when RUST_BACKTRACE is set

view details

hosseind75

commit sha 49bc85e947ab7ca793c14b6f3af4a8e9d8db0337

fix clippy custom_ice_message test

view details

hosseind75

commit sha 7f07577e6f873f4a1b3428d29bf520189f4ef79e

add new line

view details

hosseind75

commit sha 3c94914f0c87ba00987e515063dcc9e079a8918d

rebase with master

view details

hosseind88

commit sha ab0fc477b8b83cb14c584aca281b16fb5cce4c1a

fix stderr file of clippy/custom_ice_message test

view details

est31

commit sha 2c1e8cfc622652ebfb1f0256aa8d2afae91bf416

Remove rustc_session::config::Config The wrapper type led to tons of target.target across the compiler. Its ptr_width field isn't required any more, as target_pointer_width is already present in parsed form.

view details

Dylan DPC

commit sha d2feccc1efcbeff9dfb99daa754b8b47cdac7eaf

Rollup merge of #77493 - hosseind88:ICEs_should_always_print_the_top_of_the_query_stack, r=oli-obk ICEs should always print the top of the query stack see #76920

view details

Joe Richey

commit sha ef91de640294e6d0fbf881082196ba83379ea447

Run cargo dev fmt Signed-off-by: Joe Richey <joerichey@google.com>

view details

bors

commit sha a771557ee92af5e313714f127bb48a1d787a1cff

Auto merge of #6178 - josephlr:sync-from-rust, r=phansch Sync from rust Fix rustc breakage by running: ```rust git subtree push -P src/tools/clippy git@github.com:josephlr/rust-clippy sync-from-rust ``` and then adding a commit that runs `cargo dev fmt` --- changelog: none

view details

push time in 14 days

delete branch josephlr/rust-clippy

delete branch : sync-from-rust

delete time in 14 days

create barnchjosephlr/rust-clippy

branch : sync-from-rust

created branch time in 14 days

delete branch josephlr/rust-clippy

delete branch : sync-from-rust

delete time in 14 days

issue commentrust-osdev/x86_64

Add `Mapper` methods to map `PageRange` to `PhysFrameRange`

This honestly seems quite reasonable (especially if it gives a huge speedup). Algorithmically, I'm not sure about the best way to go about things, but improvements can definitely be made.

My preferred way to do this would be to have a new method: map_range_with_table_flags which has a default implementation based on map_to_with_table_flags, but is overridden by mappers to be more efficient.

Then the following methods can be provided:

  • map_range
  • identity_map_range
chbaker0

comment created time in 14 days

pull request commentrust-random/getrandom

Fix multithreaded wasm crash (solves #164)

Should this fix be backported to 0.15? There are a lot of crates that still use that version.

Ya that should be fine, once we make sure this works, I'll backport it (maybe once we also cleanup the Self usage).

chemicstry

comment created time in 14 days

push eventchemicstry/getrandom

Matt Brubeck

commit sha 7dd681ec08f828c66b25fbf599fd4fef68ed1870

Update to cfg-if 1.0

view details

koushiro

commit sha 3a7e60534591b27e8d6758ae63dc1117fd9f9981

Update wasi to 0.10 Signed-off-by: koushiro <koushiro.cqx@gmail.com>

view details

chemicstry

commit sha e13172566850cb9e4d507d56825a68a1e0846cc6

Fix multithreaded wasm crash

view details

chemicstry

commit sha 2831eccbad032444a94abd674f454bfbaedd7b56

Fix buffer length problem

view details

push time in 14 days

push eventjosephlr/getrandom

Matt Brubeck

commit sha 7dd681ec08f828c66b25fbf599fd4fef68ed1870

Update to cfg-if 1.0

view details

koushiro

commit sha 3a7e60534591b27e8d6758ae63dc1117fd9f9981

Update wasi to 0.10 Signed-off-by: koushiro <koushiro.cqx@gmail.com>

view details

push time in 14 days

Pull request review commentrust-random/getrandom

Fix multithreaded wasm crash (solves #164)

 pub(crate) fn getrandom_inner(dest: &mut [u8]) -> Result<(), Error> {                     return Err(Error::NODE_RANDOM_FILL_SYNC);                 }             }-            RngSource::Browser(n) => {-                // see https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues-                //-                // where it says:-                //-                // > A QuotaExceededError DOMException is thrown if the-                // > requested length is greater than 65536 bytes.-                for chunk in dest.chunks_mut(65536) {-                    if n.get_random_values(chunk).is_err() {+            RngSource::Browser(ctx) => {+                for chunk in dest.chunks_mut(BROWSER_CRYPTO_BUFFER_SIZE) {

Good idea. Thanks!

chemicstry

comment created time in 14 days

Pull request review commentrust-random/getrandom

Fix multithreaded wasm crash (solves #164)

 fn getrandom_init() -> Result<RngSource, Error> {             (_, crypto) if !crypto.is_undefined() => crypto,             _ => return Err(Error::WEB_CRYPTO),         };-        return Ok(RngSource::Browser(crypto));++        let buf = Uint8Array::new_with_length(BROWSER_CRYPTO_BUFFER_SIZE as u32);++        let ctx = BrowserCryptoContext { crypto, buf };++        return Ok(RngSource::Browser(ctx));

This then becomes:

let buf = Uint8Array::new_with_length(BROWSER_CRYPTO_BUFFER_SIZE as u32);
return Ok(RngSource::Browser(crypto, buf));
chemicstry

comment created time in 14 days

Pull request review commentrust-random/getrandom

Fix multithreaded wasm crash (solves #164)

 use crate::Error; extern crate std; use std::thread_local; +use js_sys::Uint8Array; use wasm_bindgen::prelude::*; +// Maximum is 65536 bytes see https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues+const BROWSER_CRYPTO_BUFFER_SIZE: usize = 256;++struct BrowserCryptoContext {+    crypto: BrowserCrypto,+    // A temporary buffer backed by browser memory to avoid multithreaded wasm exception. See issue #164+    buf: Uint8Array,+}+

Instead of having this large structure, we could just do:

enum RngSource {
    Node(NodeCrypto),
    Browser(BrowserCrypto, Uint8Array),
}

and then add the comment about using the temporary buffer when we actually use the temp buffer:

RngSource::Browser(crypto, buf) => {
    // getRandomValues does not work with all types of WASM memory, so
    // we initially write to browser memory to avoid an exception.
    for chunk in dest.chunks_mut(BROWSER_CRYPTO_BUFFER_SIZE) {
        ...
    }
}
chemicstry

comment created time in 14 days

PullRequestReviewEvent
more