[HN Gopher] Deploying Rust in Existing Firmware Codebases
       ___________________________________________________________________
        
       Deploying Rust in Existing Firmware Codebases
        
       Author : pjmlp
       Score  : 90 points
       Date   : 2024-09-05 17:02 UTC (5 hours ago)
        
 (HTM) web link (security.googleblog.com)
 (TXT) w3m dump (security.googleblog.com)
        
       | Kostarrr wrote:
       | It's really cool that google is investing so heavily in rust.
       | However, the blog post is more of a "starting point" than a
       | "lessons learned" (which I hoped for).
        
         | Analemma_ wrote:
         | It's not a great title for the post, because it's ambiguous and
         | could go either way, but the post itself doesn't pretend to be
         | anything other than a how-to documentation guide for Android
         | integrators.
        
         | nicce wrote:
         | In some sense it is bit missleading as well. On firmware level,
         | you typically need to use a lot of unsafe code. Of course, this
         | highlights the potential danger zones very well, if you use it
         | correctly. But there is still chance that human made a mistake
         | that leads into memory bug. It should be addressed, while it
         | greatly reduces the risks.
        
           | timschmidt wrote:
           | I'm hacking on a firmware in Rust right now, for the
           | ESP32-C3, and the only unsafe bits are buried deeply in the
           | esp-hal crate for the C FFI to ESP-IDF and low level hardware
           | twiddling. esp-hal exposes safe interfaces to all of that, so
           | I've had to write zero unsafe code.
        
             | nicce wrote:
             | But someone else just has written that unsafe code. It is
             | there and unsafe is used as intended, to create an
             | abstraction layer and limit the risky area. Note that even
             | if you use safe abstractions, interactions through safe
             | abstractions can leak to issues in unsafe code.
        
               | mecsred wrote:
               | This may come as a shock, but it's actually unsafe all
               | the way down. Turns out everything needs to become
               | machine code eventually, and CPUs can do all kinds of
               | nasty stuff. Doesn't make containing the unsafe codes to
               | a region of the program any less of a good idea.
        
               | nicce wrote:
               | I was just about to edit my comment, because indeed that
               | is the case, and someone will grab into it. But firmware
               | as a term includes typically writing also that part which
               | parent used "safely". In Rust world hal is own term and
               | as abstraction more known term, but that is not the case
               | if you advertise Rust in blog in order to make non-Rust
               | users to make an understanding. If you build your own
               | products, there is no hal, you need to write it. And use
               | of unsafe to limit the dangerous code is indeed excellent
               | practice.
               | 
               | But why leave that part out from the blog post which gets
               | a lot of audience?
        
           | oll3 wrote:
           | Yes, on hal level there will be a bunch of unsafe. On
           | firmware application level it's not often I find the need to
           | reach for unsafe though. It would typically be if the hal is
           | lacking in some sense.
        
             | jsheard wrote:
             | I was a bit taken aback when I realized that Embassy's low-
             | level PAC crates expose all of the devices raw registers
             | through "safe" interfaces though. I'm pretty sure that
             | letting you configure DMA engines arbitrarily at any time
             | is not in the spirit of safe Rust. AFAIK their high-level
             | HAL crates do aim to be properly safe but their PAC
             | approach makes me nervous.
             | 
             | https://docs.embassy.dev/rp-
             | pac/git/default/dma/struct.Chann...
        
             | nicce wrote:
             | But firmware is kinda generic term that usually includes
             | the hal. I am not sure what it meant in this blog post.
        
       | unwind wrote:
       | Uh, I get a mostly blank page with a randomly-placed YouTube icon
       | on the right, and no actual text? Wut?
       | 
       | Edit: Firefox on Linux/x64.
        
         | pm215 wrote:
         | It doesn't seem to display properly on all browsers - I got
         | that on Linux Firefox at work earlier, but Android Firefox
         | seems to manage to display it OK.
        
           | Sindisil wrote:
           | Not always. I just tried it in FF on my Android phone. No
           | luck. Assuming I'm not missing anything, if they can't be
           | bothered to make a simple blog page loadable.
           | 
           | FFS.
        
         | gpm wrote:
         | Try refreshing a few times. It seems that they've managed to
         | partially break the page on firefox. I'm currently also on
         | x64/firefox/linux and it works roughly half the time for me.
        
         | tux3 wrote:
         | Impressive that they managed to make a plain blog post break.
         | What kind of insane Javascript must be running, that a vertical
         | scroll view with text and pictures has been overcomplicated to
         | the point of breakage
        
           | swatcoder wrote:
           | Last time I looked up a function in the Android API
           | reference, it involved a 10MB of file transfer (mostly crude
           | custom fonts, IIRC), and the browser gave up trying to
           | resolve the anchor url meant to jump me to the function
           | itself, so I had to Ctrl-f or manually scroll to actually get
           | to my information.
           | 
           | In recent years, FAANG web teams are way more invested in
           | automating things than engineering them to be efficient,
           | durable, or gracefully adaptive products.
        
           | winrid wrote:
           | Loading this page actually makes my CPU fan spin faster for a
           | few seconds :D
        
           | wmf wrote:
           | I also got a blank page on Firefox so I opened the inspector
           | and found manmade horrors sadly within my comprehension: a
           | bunch of elements that initially load as hidden then get
           | unhidden later by JS (which never runs) and the body of the
           | blog post is nothing but a script tag. What the fuck, Google.
        
             | 01HNNWZ0MV43FF wrote:
             | Thank goodness no natural intelligence will be able to
             | scrape and copy the content
        
           | sim7c00 wrote:
           | maybe they can replace javascript with rust :')
        
             | smaudet wrote:
             | Their Javascript must have got wet - it rusted too much...
        
               | FridgeSeal wrote:
               | That makes it sound like JS is analogous to iron, instead
               | of the damp cardboard it actually is hahahaha
        
         | tripdout wrote:
         | On the same platform and browser, it displays the header line
         | separator and my CPU fan ramps up but it does load after a few
         | seconds.
        
         | loeg wrote:
         | If you use the uBlock Origin "disable Javascript for this
         | site," it loads totally fine (all of the content is hidden
         | behind either <noscript> tags or some broken javascript).
        
         | dsissitka wrote:
         | It's choking on this regex with a "too much recursion" error:
         | var match = data.match(/([\s\S]+?)<div data-is-
         | preview.+?>([\s\S]+)<\/div>/m);
        
         | piperswe wrote:
         | Works fine for me with no JavaScript, but if I open it in a
         | private browsing window without LibreJS I get what you
         | describe. Funny, usually it's the opposite!
        
       | yazaddaruvala wrote:
       | I hope this effort can also translate into more Rust in Linux,
       | rather than potentially Android on a different OS.
        
         | vlovich123 wrote:
         | This isn't relevant to either thing you've said. The post is
         | about taking the firmware code that's on various peripherals
         | (eg the microcontroller the IMU is connected to which Android
         | then talks to or the WiFi/BT microcontroller that talks to the
         | actual PHY radio).
         | 
         | Rust in Linux is about the Linux kernel having more rust code
         | but Linux is not firmware in the traditional sense (unless
         | you're talking about ucLinux which no one in my experience
         | uses) and this would have nothing to do with porting Android to
         | another kernel which I can't see happening considering how much
         | custom kernel code there is (unless you are talking about
         | fuschia but fuschia is not Android even though it implements an
         | Android compat layer).
        
       | smaudet wrote:
       | This page came up for me blank...
       | 
       | I had to stick it in brave for it to work. I guess google doesn't
       | make web pages anymore...
        
         | jeroenhd wrote:
         | Ad blockers get really weird with Google blog pages, especially
         | if you use multiple or very strict ones. There are plenty of
         | rule lists where most Google domains are just blacklisted by
         | default in case something tries to load javascript from them,
         | and those will break the blog posts.
         | 
         | Page works for me, but the CSS is screwed up by adblock. It is
         | what it is.
        
         | wging wrote:
         | In what browser did it fail to work? It works for me in both
         | iOS Safari and desktop Firefox.
        
           | tom_ wrote:
           | Comes up blank for me on Firefox 129.0.2 and Firefox 130.0,
           | both on Windows. I don't use ad blockers.
        
         | monocasa wrote:
         | Comes up essentially blank for me too on Firefox desktop on
         | ubuntu 24.04. Still comes up blank with the only adblocker I
         | use (ublock) disabled as well.
        
           | Gigachad wrote:
           | Loaded fine for me on Firefox on Macos
        
         | freedomben wrote:
         | I had to whitelist a script from ajax.googleapis.com to get the
         | page to load.
        
       ___________________________________________________________________
       (page generated 2024-09-05 23:00 UTC)