linux-kernel - Re: [PATCH v9 12/27] rust: add `kernel` crate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yu5Bex9zU6KJpcEm@yadro.com>
Date:   Sat, 6 Aug 2022 13:24:59 +0300
From:   Konstantin Shelekhin <k.shelekhin@...ro.com>
To:     <ojeda@...nel.org>
CC:     <alex.gaynor@...il.com>, <ark.email@...il.com>,
        <bjorn3_gh@...tonmail.com>, <bobo1239@....de>,
        <bonifaido@...il.com>, <boqun.feng@...il.com>,
        <davidgow@...gle.com>, <dev@...lasmohrin.de>,
        <dsosnowski@...snowski.pl>, <foxhlchen@...il.com>,
        <gary@...yguo.net>, <geofft@...reload.com>,
        <gregkh@...uxfoundation.org>, <jarkko@...nel.org>,
        <john.m.baublitz@...il.com>, <leseulartichaut@...il.com>,
        <linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <m.falkowski@...sung.com>, <me@...enk.de>, <milan@...verde.com>,
        <mjmouse9999@...il.com>, <patches@...ts.linux.dev>,
        <rust-for-linux@...r.kernel.org>, <thesven73@...il.com>,
        <torvalds@...ux-foundation.org>, <viktor@...ar.de>,
        <wedsonaf@...gle.com>
Subject: Re: [PATCH v9 12/27] rust: add `kernel` crate

> +unsafe impl GlobalAlloc for KernelAllocator {
> +    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
> +        // `krealloc()` is used instead of `kmalloc()` because the latter is
> +        // an inline function and cannot be bound to as a result.
> +        unsafe { bindings::krealloc(ptr::null(), layout.size(), bindings::GFP_KERNEL) as *mut u8 }
> +    }
> +
> +    unsafe fn dealloc(&self, ptr: *mut u8, _layout: Layout) {
> +        unsafe {
> +            bindings::kfree(ptr as *const core::ffi::c_void);
> +        }
> +    }
> +}

I sense possible problems here. It's common for a kernel code to pass
flags during memory allocations.

For example:

  struct bio *bio;

  for (...) {
        bio = bio_alloc_bioset(bdev, nr_vecs, opf, GFP_NOIO, bs);
        if (!bio)
        	return -ENOMEM;
  }

Without GFP_NOIO we can run into a deadlock, because the kernel will try
give us free memory by flushing the dirty pages and we need the memory
to actually do it and boom, deadlock.

Or we can be allocating some structs under spinlock (yeah, that happens too):

  struct efc_vport *vport;

  spin_lock_irqsave(...);
  vport = kzalloc(sizeof(*vport), GFP_ATOMIC);
  if (!vport) {
  	spin_unlock_irqrestore(...);
  	return NULL;
  }
  spin_unlock(...);

Same can (and probably will) happen to e.g. Vec elements. So some form
of flags passing should be supported in try_* variants:

  let mut vec = Vec::try_new(GFP_ATOMIC)?;

  vec.try_push(GFP_ATOMIC, 1)?;
  vec.try_push(GFP_ATOMIC, 2)?;
  vec.try_push(GFP_ATOMIC, 3)?;