linux-kernel - Re: C aggregate passing (Rust kernel policy)

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: <CAFJgqgSzqGKdeT88fJzrFOex7i-yvVte3NiQDdgXeWEFtnq=9A@mail.gmail.com>
Date: Wed, 26 Feb 2025 08:21:45 -0700
From: Ventura Jack <venturajack85@...il.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Alice Ryhl <aliceryhl@...gle.com>, Linus Torvalds <torvalds@...ux-foundation.org>, 
	Kent Overstreet <kent.overstreet@...ux.dev>, Gary Guo <gary@...yguo.net>, airlied@...il.com, 
	boqun.feng@...il.com, david.laight.linux@...il.com, ej@...i.de, 
	gregkh@...uxfoundation.org, hch@...radead.org, hpa@...or.com, 
	ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	rust-for-linux@...r.kernel.org, Ralf Jung <post@...fj.de>
Subject: Re: C aggregate passing (Rust kernel policy)

On Wed, Feb 26, 2025 at 6:52 AM Miguel Ojeda
<miguel.ojeda.sandonis@...il.com> wrote:
>
> On Wed, Feb 26, 2025 at 1:36 PM Ventura Jack <venturajack85@...il.com> wrote:
> >
> > In a preprint paper, both stacked borrows and tree burrows are as
> > far as I can tell described as having false positives.
> >
> > Are you sure that both stacked borrows and tree borrows are
> > meant to be full models with no false positives and false negatives,
> > and no uncertainty, if I understand you correctly? It should be
> > noted that they are both works in progress.
>
> I think you are mixing up two things: "a new model does not allow
> every single unsafe code pattern out there" with "a new model, if
> adopted, would still not be able to tell if something is UB or not".

I am not certain that I understand either you or Alice correctly.
But Ralf Jung or others will probably help clarify matters.

> > The aliasing rules being tied to a specific compiler backend,
> > instead of a specification, might make it harder for other
> > Rust compilers, like gccrs, to implement the same behavior for
> > compiled programs, as what the sole major Rust compiler,
> > rustc, has of behavior for compiled programs.
>
> It is not "tied to a specific compiler backend". The reference (or
> e.g. the standard library implementation, which you mentioned) may
> mention LLVM, as well as other backends, but that does not imply the
> final rules will (or need to) refer to the LLVM reference. And even if
> a spec refers to a given revision of another spec (it is not
> uncommon), that is different from being "tied to a specific compiler
> backend".
>
> Moreover, if it makes it easier, another compiler could always assume less.

You are right that I should have written "currently tied", not "tied", and
I do hope and assume that the work with aliasing will result
in some sorts of specifications.

The language reference directly referring to LLVM's aliasing rules,
and that the preprint paper also refers to LLVM, does indicate a tie-in,
even if that tie-in is incidental and not desired. With more than one
major compiler, such tie-ins are easier to avoid.

    https://doc.rust-lang.org/stable/reference/behavior-considered-undefined.html
        "Breaking the pointer aliasing rules
        http://llvm.org/docs/LangRef.html#pointer-aliasing-rules
        . Box<T>, &mut T and &T follow LLVM’s scoped noalias
        http://llvm.org/docs/LangRef.html#noalias
        model, except if the &T contains an UnsafeCell<U>.
        References and boxes must not be dangling while they are
        live. The exact liveness duration is not specified, but some
        bounds exist:"

Best, VJ.