profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/alex/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Alex Gaynor alex Washington D.C. https://alexgaynor.net I program computers, and build teams that program computers, with a heavy focus on security.

alex/bagel 21

Bagels are delicious

alex/alex-s-language 6

Inteded to be a compiled Python, by translating source files to C++

alex/api-serializer 2

Random hack, don't use.

alex/bcrypt 2

Modern password hashing for your software and your servers

alex/acme-spec 1

ACME Specification

alex/arewepythonyet 1

http://arewepythonyet.com

PR opened Rust-for-Linux/linux

Simple Rust driver that touches real hardware: PR 1/5

Simple Rust driver that touches real h/w: step 1 of 5

@alex and @ojeda suggested that #254 should be split into smaller PRs, so they can be reviewed and merged individually.

Roadmap:

  • [ ] platform_device (this PR)
  • [ ] probe
  • [ ] DrvData
  • [ ] regmap/iomem
  • [ ] finally the actual hwrng driver
+631 -1

0 comment

10 changed files

pr created time in a few seconds

startedasg017/dataflow

started time in a few seconds

Pull request review commentRust-for-Linux/linux

rust/kernel: move from_kernel_result! macro to error.rs

 impl From<AllocError> for Error {     } } +// # Invariant: `-bindings::MAX_ERRNO` fits in an `i16`.+crate::static_assert!(bindings::MAX_ERRNO <= -(i16::MIN as i32) as u32);

See if you like #269 :)

It would allow you to do:

static_assert!((-(bindings::MAX_ERRNO as i128)) fits in i16);
TheSven73

comment created time in a minute

PR opened Rust-for-Linux/linux

rust: improve `static_assert!`

Now static_assert! allows for several forms:

  • Boolean assertion: expr.
  • Set membership assertion: (expr) is in {a0, ..., aN}.
  • Interval membership assertion: (expr) is in [min, max].
  • Fits-in-type assertion: (expr) fits in type.

These are all static_assert!s instead of being split into a separate macro (e.g. fits_in!) because we want to ensure they are only within/as a static_assert! (e.g. for the i128 trick).

The documentation is also improved for the boolean assertion case.

Signed-off-by: Miguel Ojeda ojeda@kernel.org

+165 -2

0 comment

1 changed file

pr created time in 3 minutes

Pull request review commentRust-for-Linux/linux

rust/error: add helper function to convert a C error pointer to a `Result`

 impl From<AllocError> for Error {         Error::ENOMEM     } }++// # Invariant: `-bindings::MAX_ERRNO` fits in an `i16`.+crate::static_assert!(bindings::MAX_ERRNO as i64 <= -(i16::MIN as i64));++/// Transform a kernel "error pointer" to a normal pointer.+///+/// Some kernel C API functions return an "error pointer" which optionally+/// embeds an `errno`. Callers are supposed to check the returned pointer+/// for errors. This function performs the check and converts the "error pointer"+/// to a normal pointer in an idiomatic fashion.+///+/// # Examples+///+/// ```rust,no_run+/// fn devm_platform_ioremap_resource(+///     pdev: &mut PlatformDevice,+///     index: u32,+/// ) -> Result<*mut c_types::c_void> {+///     // SAFETY: FFI call.+///     unsafe {+///         ptr_err_check(bindings::devm_platform_ioremap_resource(+///             pdev.to_ptr(),+///             index,+///         ))+///     }+/// }+/// ```+// TODO: remove `dead_code` marker once an in-kernel client is available.+#[allow(dead_code)]+pub(crate) unsafe fn ptr_err_check<T>(ptr: *mut T) -> Result<*mut T> {

The "official" name of this kernel abstraction is "error pointer". So how about from_kernel_error_pointer() ?

TheSven73

comment created time in 2 hours

PR closed rust-fuzz/libfuzzer

Add custom mutator macro

This adds a new macro that defines a custom mutator macro for libfuzzer.

Custom mutator

The mutator receives a mutable C array of bytes that is afterwards fed into the fuzzer. The user can use libfuzzer's standard mutator by calling the llvm_fuzzer_mutate wrapper function.

Handling of the C byte array

In Rust, the byte array can be exposed as a mutable slice of length max_len. In the C API, the user must return the actual length used by the array without any guarantee that len <= max_len. I have added two options in the mutator declaration macro, either provide a mutable Vec<u8> and then trim the vector if its length is more than max_len before copying it back into the C API's slice, or use a custom struct Buffer that works like a Vec but ignores any attempts at adding more bytes if the final length surpasses max_len. Buffer is not a very clean solution, but at least it prevents copying in each mutation step.

Next steps

If the Arbritary trait provides a method to turn objects back into bytes (like mentioned in rust-fuzz/arbitrary/issues/44) the macro can take a data: &mut T argument so that the user can work directly on an object rather than raw bytes.

+749 -0

3 comments

2 changed files

epilys

pr closed time in 2 hours

pull request commentrust-fuzz/libfuzzer

Add custom mutator macro

Closing in favor of #79.

epilys

comment created time in 2 hours

pull request commentrust-fuzz/libfuzzer

Add support for defining custom mutators

Published!

fitzgen

comment created time in 2 hours

created tagrust-fuzz/libfuzzer

tag0.4.1

Rust bindings and utilities for LLVM’s libFuzzer

created time in 2 hours

push eventrust-fuzz/libfuzzer

Nick Fitzgerald

commit sha 062f36b424c6dcdbd403c3a5d4384d731c8a3f84

Bump to version 0.4.1

view details

push time in 2 hours

push eventrust-fuzz/libfuzzer

Nick Fitzgerald

commit sha 41289fa5bc212a01c2d3fb3d6cc49c361811a182

Update libFuzzer to llvm/llvm-project's 70cbc6d

view details

Nick Fitzgerald

commit sha 84e5ca2110634c253f5dbe7bbfe76fc8db01d282

Put example crates in this workspace

view details

Nick Fitzgerald

commit sha c8fedd2601a01250e8658d622affd0963cf61450

Update the `arbitrary` example in the docs for `arbitrary` 1.0

view details

Nick Fitzgerald

commit sha b882dd6436d577acf5395a7af2dcdbb1a376db29

Mention the `arbitrary-derive` feature in the docs for greater discoverability

view details

Nick Fitzgerald

commit sha 70d77fb84c810b35ed83296cce8e83826aff6524

Add support for defining custom mutators This adds support for defining custom mutators, as described in https://github.com/google/fuzzing/blob/master/docs/structure-aware-fuzzing.md

view details

Nick Fitzgerald

commit sha b5dfd80a21e36d48af3c927aa046a53a64f0a6f7

Also run doc tests in CI

view details

Nick Fitzgerald

commit sha 9a13a0c31e9748a0debb5c1bd26d394d862baac7

Add a `max_size` parameter to `fuzzer_mutate` This allows users to force libfuzzer to only perform shrinking mutations.

view details

Nick Fitzgerald

commit sha e80623eb76bf163e7b4970a8e5803a6fdbd071be

Ignore crash files inside `./example_mutator`

view details

Nick Fitzgerald

commit sha f6f3f14c50fab3c0db0a33bd70b56bad0703770b

Merge pull request #79 from fitzgen/custom-mutators Add support for defining custom mutators

view details

push time in 2 hours

PR merged rust-fuzz/libfuzzer

Add support for defining custom mutators

See the doc comments for the fuzz_mutator! macro for example usage and user-level information.

There is some slightly funky stuff going on with data, size, and max_size that doesn't feel 100% Rust-y / is a little subtle to support size-aware mutations. data is basically a vec's heap allocation, size is basically vec.len(), and max(size, max_size) is basically vec.capacity(). Not sure that this API can really be improved upon while remaining a thin wrapper over what libfuzzer gives us (i.e. doesn't introduce a ~fork of std::vec::Vec) but I'm open to ideas!

Supersedes #62.

+739 -583

1 comment

33 changed files

fitzgen

pr closed time in 2 hours

pull request commentrust-fuzz/libfuzzer

Add support for defining custom mutators

Thanks for review @Manishearth @frewsxcv!

I've pushed a tiny commit that adds a max_size parameter to the libfuzzer_sys::fuzzer_mutate function, so that users can force libfuzzer to only make shrinking mutations on the data they ask it to mutate (the old signature only allowed users to force equal-or-smaller mutations or allow growth as well).

I'll merge and cut a release as soon as CI is green!

fitzgen

comment created time in 3 hours

issue closedfishinabarrel/analysis

oss-fuzz last week: 56 bug-security

https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-modified&colspec=ID%20Type%20Component%20Status%20Library%20Reported%20Summary%20Modified&cells=ids&q=Type%3DBug-Security%20status%3AVerified%20Modified%3E2021-05-05%20Modified%3C2021-05-14&can=1

54/56

closed time in 3 hours

alex

startedasottile/pyupgrade

started time in 3 hours

Pull request review commentRust-for-Linux/linux

rust/error: add helper function to convert a C error pointer to a `Result`

 impl From<AllocError> for Error {         Error::ENOMEM     } }++// # Invariant: `-bindings::MAX_ERRNO` fits in an `i16`.+crate::static_assert!(bindings::MAX_ERRNO as i64 <= -(i16::MIN as i64));++/// Transform a kernel "error pointer" to a normal pointer.+///+/// Some kernel C API functions return an "error pointer" which optionally+/// embeds an `errno`. Callers are supposed to check the returned pointer+/// for errors. This function performs the check and converts the "error pointer"+/// to a normal pointer in an idiomatic fashion.+///+/// # Examples+///+/// ```rust,no_run+/// fn devm_platform_ioremap_resource(+///     pdev: &mut PlatformDevice,+///     index: u32,+/// ) -> Result<*mut c_types::c_void> {+///     // SAFETY: FFI call.+///     unsafe {+///         ptr_err_check(bindings::devm_platform_ioremap_resource(+///             pdev.to_ptr(),+///             index,+///         ))+///     }+/// }+/// ```+// TODO: remove `dead_code` marker once an in-kernel client is available.+#[allow(dead_code)]+pub(crate) unsafe fn ptr_err_check<T>(ptr: *mut T) -> Result<*mut T> {

We can give it any name. Let's think of one.

Good point, it doesn't have to be an unsafe function. Move the two calls to unsafe functions in an unsafe block?

TheSven73

comment created time in 3 hours

Pull request review commentRust-for-Linux/linux

rust/error: add helper function to convert a C error pointer to a `Result`

 impl From<AllocError> for Error {         Error::ENOMEM     } }++// # Invariant: `-bindings::MAX_ERRNO` fits in an `i16`.+crate::static_assert!(bindings::MAX_ERRNO as i64 <= -(i16::MIN as i64));++/// Transform a kernel "error pointer" to a normal pointer.+///+/// Some kernel C API functions return an "error pointer" which optionally+/// embeds an `errno`. Callers are supposed to check the returned pointer+/// for errors. This function performs the check and converts the "error pointer"+/// to a normal pointer in an idiomatic fashion.+///+/// # Examples+///+/// ```rust,no_run+/// fn devm_platform_ioremap_resource(+///     pdev: &mut PlatformDevice,+///     index: u32,+/// ) -> Result<*mut c_types::c_void> {+///     // SAFETY: FFI call.+///     unsafe {+///         ptr_err_check(bindings::devm_platform_ioremap_resource(+///             pdev.to_ptr(),+///             index,+///         ))+///     }+/// }+/// ```+// TODO: remove `dead_code` marker once an in-kernel client is available.+#[allow(dead_code)]+pub(crate) unsafe fn ptr_err_check<T>(ptr: *mut T) -> Result<*mut T> {

Also I don't think we need the unsafe for this function: we don't dereference the pointer and we know there is no way this function will cause UB.

TheSven73

comment created time in 3 hours

Pull request review commentRust-for-Linux/linux

rust/error: add helper function to convert a C error pointer to a `Result`

 impl From<AllocError> for Error {         Error::ENOMEM     } }++// # Invariant: `-bindings::MAX_ERRNO` fits in an `i16`.+crate::static_assert!(bindings::MAX_ERRNO as i64 <= -(i16::MIN as i64));++/// Transform a kernel "error pointer" to a normal pointer.+///+/// Some kernel C API functions return an "error pointer" which optionally+/// embeds an `errno`. Callers are supposed to check the returned pointer+/// for errors. This function performs the check and converts the "error pointer"+/// to a normal pointer in an idiomatic fashion.+///+/// # Examples+///+/// ```rust,no_run+/// fn devm_platform_ioremap_resource(+///     pdev: &mut PlatformDevice,+///     index: u32,+/// ) -> Result<*mut c_types::c_void> {+///     // SAFETY: FFI call.+///     unsafe {+///         ptr_err_check(bindings::devm_platform_ioremap_resource(+///             pdev.to_ptr(),+///             index,+///         ))+///     }+/// }+/// ```+// TODO: remove `dead_code` marker once an in-kernel client is available.+#[allow(dead_code)]+pub(crate) unsafe fn ptr_err_check<T>(ptr: *mut T) -> Result<*mut T> {

Why name it as ptr_err_check? check sounds like an operation to me, and a *_check function seems like a function will return nothing or bool. Just want to know the reason of the name ;-)

Maybe we can name it as ptr_or_err or something?

TheSven73

comment created time in 3 hours

Pull request review commentRust-for-Linux/linux

rust/kernel: move from_kernel_result! macro to error.rs

 impl From<AllocError> for Error {     } } +// # Invariant: `-bindings::MAX_ERRNO` fits in an `i16`.+crate::static_assert!(bindings::MAX_ERRNO <= -(i16::MIN as i32) as u32);

I am grabbing the popcorn !! :)

TheSven73

comment created time in 4 hours

Pull request review commentRust-for-Linux/linux

rust/kernel: move from_kernel_result! macro to error.rs

 impl From<AllocError> for Error {     } } +// # Invariant: `-bindings::MAX_ERRNO` fits in an `i16`.+crate::static_assert!(bindings::MAX_ERRNO <= -(i16::MIN as i32) as u32);

I have taken a look at this -- it is indeed a bit painful. After having tried several approaches, I am preparing a PR with a fun approach.

TheSven73

comment created time in 4 hours

pull request commentRust-for-Linux/linux

Improvement to Error

Don't mind at all :)

Alternative suggestion in #268

fbq

comment created time in 4 hours

PR opened Rust-for-Linux/linux

rust/error: add helper function to convert a C error pointer to a `Result`

Some kernel C API functions return a pointer which embeds an optional errno. Callers are supposed to check the returned pointer with IS_ERR() and if this returns true, retrieve the errno using PTR_ERR().

Create a Rust helper function to implement the Rust equivalent: transform a *mut T to Result<*mut T>.

Co-Created-By: Boqun Feng boqun.feng@gmail.com Co-Created-By: Miguel Ojeda ojeda@users.noreply.github.com Signed-off-by: Sven Van Asbroeck thesven73@gmail.com

+64 -0

0 comment

2 changed files

pr created time in 4 hours

Pull request review commentRust-for-Linux/linux

Improvement to Error

 impl Error {     pub fn to_kernel_errno(&self) -> c_types::c_int {         self.0     }++    /// Creates an [`Error`] from a kernel pointer.+    ///+    /// # Pointer value range+    ///+    /// According to `include/linux/err.h`:+    /// - [0, .., `core::usize::MAX - bindings::MAX_ERRNO`) is the range for+    ///   normal values of pointer.+    ///+    /// - [`core::usize::MAX - bindings::MAX_ERRNO`,..,`core::usize::MAX] is the+    ///   range for error values stored in pointer.+    pub fn from_kernel_ptr(ptr: *mut c_types::c_void) -> Option<Error> {

Anyway thanks for looking into the generated code to prove I'm wrong ;-)

I didn't want to imply that you were wrong - you were asking a question that I didn't know the answer to either (Would unnecessary template functions increase the code size?) and it sounded like an interesting question.

I apologize if it came across that way.

No need to apologize ;-) Actually I'm glad you looked into it.

Note that I actually kinda answered my question myself with "For example, if we have from_kernel_ptr<i32> and from_kernel_ptr<i8>, there will be two functions instead of one.", so literally, I was wrong and you simply showed the answer is opposite.

fbq

comment created time in 5 hours

Pull request review commentRust-for-Linux/linux

Improvement to Error

 impl Error {     pub fn to_kernel_errno(&self) -> c_types::c_int {         self.0     }++    /// Creates an [`Error`] from a kernel pointer.+    ///+    /// # Pointer value range+    ///+    /// According to `include/linux/err.h`:+    /// - [0, .., `core::usize::MAX - bindings::MAX_ERRNO`) is the range for+    ///   normal values of pointer.+    ///+    /// - [`core::usize::MAX - bindings::MAX_ERRNO`,..,`core::usize::MAX] is the+    ///   range for error values stored in pointer.+    pub fn from_kernel_ptr(ptr: *mut c_types::c_void) -> Option<Error> {+        let value = ptr as usize;++        if value >= core::usize::MAX - bindings::MAX_ERRNO as usize {

I think you're right. This is indeed an embarrassing bug, and prove the point ;-)

fbq

comment created time in 5 hours

Pull request review commentRust-for-Linux/linux

Improvement to Error

 impl Error {     pub fn to_kernel_errno(&self) -> c_types::c_int {         self.0     }++    /// Creates an [`Error`] from a kernel pointer.+    ///+    /// # Pointer value range+    ///+    /// According to `include/linux/err.h`:+    /// - [0, .., `core::usize::MAX - bindings::MAX_ERRNO`) is the range for+    ///   normal values of pointer.+    ///+    /// - [`core::usize::MAX - bindings::MAX_ERRNO`,..,`core::usize::MAX] is the+    ///   range for error values stored in pointer.+    pub fn from_kernel_ptr(ptr: *mut c_types::c_void) -> Option<Error> {

Anyway thanks for looking into the generated code to prove I'm wrong ;-)

I didn't want to imply that you were wrong - you were asking a question that I didn't know the answer to either (Would unnecessary template functions increase the code size?) and it sounded like an interesting question.

I apologize if it came across that way.

fbq

comment created time in 5 hours

pull request commentRust-for-Linux/linux

Improvement to Error

In the meanwhile, @TheSven73 feel free to submit your version as a PR, I will close this one once your version has been fully reviewed.

When PRs are as closely reviewed as we're doing here, I feel that they are always co-owned. So I wouldn't like to call it "my version". A new PR just means we try again, from a different starting point.

"your version" was simply a reference ;-) I could say "the implementation which reuses the Linux functions/macros" but I was lazy typing. Hope you don't mind ;-)

fbq

comment created time in 5 hours

startedalex/csv-sql

started time in 5 hours

Pull request review commentRust-for-Linux/linux

Improvement to Error

 impl Error {     pub fn to_kernel_errno(&self) -> c_types::c_int {         self.0     }++    /// Creates an [`Error`] from a kernel pointer.+    ///+    /// # Pointer value range+    ///+    /// According to `include/linux/err.h`:+    /// - [0, .., `core::usize::MAX - bindings::MAX_ERRNO`) is the range for+    ///   normal values of pointer.+    ///+    /// - [`core::usize::MAX - bindings::MAX_ERRNO`,..,`core::usize::MAX] is the+    ///   range for error values stored in pointer.+    pub fn from_kernel_ptr(ptr: *mut c_types::c_void) -> Option<Error> {

Note that I agree we need a template ptr_err_check or ptr_to_result, because the return type will use the template parameter, and that will empower us with some strong type checking. I also made ptr_to_result as a template function.

And if we think that from_kernel_ptr is worth discussing, I don't think the template parameter will buy us anything, it only appears at the input parameter, and the type information gets lost afterwards. So it's really unnecessary ;-(

Anyway thanks for looking into the generated code to prove I'm wrong ;-)

fbq

comment created time in 5 hours

pull request commentRust-for-Linux/linux

Improvement to Error

In the meanwhile, @TheSven73 feel free to submit your version as a PR, I will close this one once your version has been fully reviewed.

When PRs are as closely reviewed as we're doing here, I feel that they are always co-owned. So I wouldn't like to call it "my version". A new PR just means we try again, from a different starting point.

fbq

comment created time in 5 hours

pull request commentRust-for-Linux/linux

Improvement to Error

From #254:

In general, I think we want to go for re-using the C functions/macros where possible. Performance work should be based on actual numbers, which we can focus on later. And, anyway, we should be able to have cross-language LTO at some point, which will most likely inline those.

Yep, I also hope that cross-language LTO could work, I'd like also to try some experiments myself. In the meanwhile, @TheSven73 feel free to submit your version as a PR, I will close this one once your version has been fully reviewed.

fbq

comment created time in 5 hours