lkml.org 
[lkml]   [2023]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v10 25/27] x86: enable initial Rust support
    On Thu, Oct 12, 2023 at 11:31 AM Kees Cook <keescook@chromium.org> wrote:
    >
    > On Thu, Oct 12, 2023 at 10:50:36AM -0700, Sami Tolvanen wrote:
    > > On Thu, Oct 12, 2023 at 3:47 AM Peter Zijlstra <peterz@infradead.org> wrote:
    > > >
    > > > On Fri, Oct 14, 2022 at 11:34:30AM -0700, Sami Tolvanen wrote:
    > > > > On Fri, Oct 14, 2022 at 11:05 AM Miguel Ojeda
    > > > > <miguel.ojeda.sandonis@gmail.com> wrote:
    > > > > >
    > > > > > On Tue, Oct 11, 2022 at 1:16 AM Sami Tolvanen <samitolvanen@google.com> wrote:
    > > > > > >
    > > > > > > Rust supports IBT with -Z cf-protection=branch, but I don't see this
    > > > > > > option being enabled in the kernel yet. Cross-language CFI is going to
    > > > > > > require a lot more work though because the type systems are not quite
    > > > > > > compatible:
    > > > > > >
    > > > > > > https://github.com/rust-lang/rfcs/pull/3296
    > > > > >
    > > > > > I have pinged Ramon de C Valle as he is the author of the RFC above
    > > > > > and implementation work too; since a month or so ago he also leads the
    > > > > > Exploit Mitigations Project Group in Rust.
    > > > >
    > > > > Thanks, Miguel. I also talked to Ramon about KCFI earlier this week
    > > > > and he expressed interest in helping with rustc support for it. In the
    > > > > meanwhile, I think we can just add a depends on !CFI_CLANG to avoid
    > > > > issues here.
    > > >
    > > > Having just read up on the thing it looks like the KCFI thing is
    > > > resolved.
    > > >
    > > > I'm not sure I understand most of the objections in that thread through
    > > > -- enabling CFI *will* break stuff, so what.
    > > >
    > > > Squashing the integer types seems a workable compromise I suppose. One
    > > > thing that's been floated in the past is adding a 'seed' attribute to
    > > > some functions in order to distinguish functions of otherwise identical
    > > > signature.
    > > >
    > > > The Rust thing would then also need to support this attribute.
    > > >
    > > > Are there any concrete plans for this? It would allow, for example,
    > > > to differentiate address_space_operations::swap_deactivate() from any
    > > > other random function that takes only a file argument, say:
    > > > locks_remove_file().
    > >
    > > I haven't really had time to look into it, so no concrete plans yet.
    > > Adding an attribute shouldn't be terribly difficult, but Kees
    > > expressed interest in automatic salting as well, which might be a more
    > > involved project:
    > >
    > > https://github.com/ClangBuiltLinux/linux/issues/1736
    >
    > Automatic would be nice, but having an attribute would let us at least
    > start the process manually (or apply salting from static analysis
    > output, etc).

    An idea would be to add something like the Rust cfi_encoding
    attribute[1] and use it with something similar to the Newtype
    Pattern[2], but in C[3], for aggregating function pointers that
    otherwise would be aggregated in the same group in different groups.

    [1]: https://doc.rust-lang.org/nightly/unstable-book/language-features/cfi-encoding.html
    [2]: https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction
    [3]: Wrapping a type in a struct should achieve something similar even
    without using the cfi_encoding attribute since the encoding for
    structs is <length><name>, where <name> is <unscoped-name>.

    \
     
     \ /
      Last update: 2023-10-13 00:27    [W:3.296 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site