[HN Gopher] Enable ARMv9 Memory Tagging Extension (MTE) on Pixel 8
___________________________________________________________________
Enable ARMv9 Memory Tagging Extension (MTE) on Pixel 8
Author : transpute
Score : 102 points
Date : 2023-11-03 06:55 UTC (16 hours ago)
(HTM) web link (outflux.net)
(TXT) w3m dump (outflux.net)
| maxloh wrote:
| Why isn't it enabled by default?
| vesinisa wrote:
| There's probably a very good reason for it.
|
| I would definitely advice anyone against enabling "Developer
| options" on your phone without having a good understanding what
| those options do. They are hidden and hard to access for a
| reason.
| j1elo wrote:
| Sadly they contain some options which ought to be part of the
| normal system settings, but they aren't.
|
| Such as animation speed. I hate _so much_ all the wobblyness
| of the GUI! Everything bouncing, sliding, and hovering
| around. Thankfully one can enable Developer options and set
| all that stuff to 0x, which effectively disables everything
| and now the system becomes crisp and instant, as it should
| be.
|
| Another essential setting for saving much precious battery,
| is to not have the cellular data active at all times even
| when WiFi is active. If I come home and enable wifi, I _do
| not_ want the cellular data to stay active too in the
| background. It 's much better waiting the couple seconds it
| might take to switch networks, in exchange for some extra
| juice.
| tuukkah wrote:
| Also, configure "Smallest width" to a high dp value to fit
| more content on the screen.
| j1elo wrote:
| For sure! that one is a very good candidate for basic
| option to tune on any phone. I always up it a bit to gain
| more screen estate.
| helloooooooo wrote:
| Because it keeps catching poorly written code that hasn't yet
| been fixed.
| muricula wrote:
| There is almost certainly a performance and battery life hit.
| Each pointer dereference will trigger a lookup in the MTE tag
| table, and a comparison between the pointer's tag and the
| table's tag.
|
| So you have a decently sized chunk of RAM set aside for the tag
| table, more memory bandwidth used up by table lookups, and the
| cost of the actual tag checks.
| shermozle wrote:
| Multicultural Toronto English? Something else?
|
| (site seems dead)
| darkamaul wrote:
| Memory Tagging Extension (MTE)
|
| This allows to assign tag to each memory allocation. And
| subsequent accesses to the same memory area must be made with a
| pointer having a correct tag.
| zerocrates wrote:
| Memory Tagging Extension, an arm v9 hardware feature for
| mitigating some memory safety bugs.
| LoganDark wrote:
| Is this the outcome of the Morello project? Honestly sounds
| nice.
| akyuu wrote:
| No, AFAIK Morello project is about designing an Arm CPU
| with CHERI, a hardware architecture with extra security
| capabilities that is still WIP: https://tratt.net/laurie/bl
| og/2023/two_stories_for_what_is_c...
| LoganDark wrote:
| I've been trying to get a Morello board for months, but
| they only offer them to large research institutions, not
| individuals who just want a hobby project. I'm aware of
| CHERI being different from this, but it still seems
| similar.
| obnauticus wrote:
| CHERI vs MTE is a bit of a nuanced topic. At least one part
| of the limiting factor for MTE is that you get a finite
| number of tag "color codes" which opens the opportunity for
| some form of probabilistic attacks. Of course this helps
| with defense in depth as it's yet another layer of
| security, but it isn't as strong of a prevention as a CHERI
| capability for example.
|
| This page explains it pretty well: https://msrc.microsoft.c
| om/blog/2022/01/an_armful_of_cheris/
| fuklief wrote:
| This survey by the same author also provides a good
| comparison
| https://saaramar.github.io/memory_safety_blogpost_2022/
| saagarjha wrote:
| MTE is somewhat like an in-band, weak version of Morello,
| but the project is independent of MTE.
| Moldoteck wrote:
| Memory tagged extension, to prevent some memory access bugs Here
| more info: https://brandulox.medium.com/pixel-8-and-8-pro-the-
| first-sma...
| cjnicholls wrote:
| https://archive.is/09uCE
| akyuu wrote:
| Consider using GrapheneOS instead of stock Android for an
| improved version of MTE (and extra security and privacy as a
| bonus): https://discuss.grapheneos.org/d/8439-mte-support-status-
| for...
|
| > _Stock Pixel OS has it as a developer option which isn 't
| usable in practice since it breaks far too much. The
| implementation is also much less powerful than hardened_malloc._
|
| > _We integrated it into hardened_malloc where it 's able to
| provide stronger security properties than the experimental stock
| OS implementation._
|
| > _When fully integrated into the compiler and each heap
| allocator, MTE enforces a form of memory safety. It detects
| memory corruption as it happens. 4 bit tags limit it to
| probabilistic detection for the general case, but deterministic
| guarantees are possible via reserving tags. In hardened_malloc,
| we deterministically prevent sequential overflows by excluding
| adjacent tags._
|
| Also, currently it's not clear if it makes sense to enable kernel
| MTE:
|
| > _MTE support for protecting the Linux kernel isn 't enabled
| yet, but we can likely enable that by default too. However, it's
| currently part of kasan and is more oriented towards debugging
| than hardening. It's not entirely clear that enabling it in the
| current state is a good idea._
| matheusmoreira wrote:
| GrapheneOS is the number one reason to get a Pixel. They do a
| lot of good work. Strcat's posts are very informative:
|
| https://news.ycombinator.com/threads?id=strcat
| mikae1 wrote:
| Writing this from a Pixel running GrapheneOS. I've been away
| from Graphene (using Lineage) since the CopperheadOS days.
| Coming back I can safely say I will be buying Pixels as long as
| GrapheneOS is around. The robustness a finish is just amazing.
|
| To anyone using a Pixel: install and donate (if you can)!
|
| The web installer[1] is basically a few clicks on a web page.
| So damned impressed.
|
| [1] https://grapheneos.org/install/web
| galangalalgol wrote:
| Do you lose the whole play store? Does it even make sense if
| I use gmail? I like the idea at least. And my 4a isn't
| getting updates now(on graphene either apparently) which is a
| shame because I still like it. I used to ise lineage on
| Samsung devices.
| piaste wrote:
| One of GrapheneOS's absolute best features is the sandboxed
| Google Play Services.
|
| Basically, where other privacy AOSP forks typically offer
| up to three choices...
|
| - no Google at all
|
| - root and install an extremely fragile FOSS alternative
| GPS implementation (MicroG)
|
| - root and install the full Google Play Services binary
| blobs
|
| ... GrapheneOS offers option #4: you can install Google
| Play Services in a sandbox so that they still run, but they
| don't get root-level access to your system, instead they
| are treated the same as any other app (so e.g. you get to
| manage their access to location/storage/contacts etc.).
|
| Note that you don't have to, it's just an option in the
| built-in Apps menu. I personally run GrapheneOS with no GPS
| at all in my main profile, and occasionally access my old
| Gmail/Gdrive accounts via web browser.
| jetbalsa wrote:
| One of the things that Graphene doesn't support is
| Android Auto -- They have stated they will never support
| it due to the sheer rootkit levels that Android Auto does
| to the OS. Its a shame they have not found a good work
| around for it yet.
| sliken wrote:
| Play store is available, just not installed by default. It
| also lives in a sandbox so has to ask for permission more
| than it does under standard android.
|
| I never realized how many permissions the play store had,
| until I ran it under graphene.
| tcbawo wrote:
| Coming from an absolute outsider (recent ambivalent iPhone
| switch, previously Android), how can I know that GrapheneOS is
| secure and the provenance of my build is legitimate, so that I
| can trust it with my banking, email, photos, identity, etc.?
| akyuu wrote:
| Builds are reproducible [1], so you can compile them yourself
| and check they match the official ones. Additionally,
| official releases are signed and the update client verifies
| them and prevents downgrade attacks [2]. You can also install
| updates offline from a computer if you prefer [3].
|
| [1] https://grapheneos.org/build#reproducible-builds
|
| [2] https://grapheneos.org/releases#about-the-releases
|
| [3] https://grapheneos.org/usage#updates-sideloading
| bubblethink wrote:
| Provenance -> They have a bunch of tooling including
| attestation that you can use to verify your OS. GrapheneOS
| also operates like the stock OS with a locked bootloader,
| just signed with their keys, and the integrity of the boot
| chain up to and including the OS is what the attenstation app
| can verify after an initial pairing.
|
| Secure -> It's code. There are no absolute guarantees. They
| have security enhancements on top of AOSP. So that's a rough
| proxy for what you should expect.
| jchw wrote:
| Speaking of which, what ever happened with all of the kerfuffle
| going on around GrapheneOS leadership, anyway?
|
| I remember Louis Rossmann posting a video[1] that felt pretty
| damning regarding project leadership, especially given that he
| seemed to be implicated in the mess for almost no reason at
| all. In general I wouldn't give a good god damn about drama,
| but I'll admit it: it's ALREADY hard to trust operating
| systems, and especially security software, that's effectively
| made by effectively random strangers on the Internet, but much
| worse so if it's unclear they wouldn't be willing to abuse
| their position.
|
| Daniel Micay (aka strcat on here I believe) apparently
| announced they were stepping down from leadership roles in the
| project shortly after, according to tweets that appear to now
| be deleted, but that Wikipedia has links to an archive of.[2]
| At least from the code side of things though, they are still
| working quite actively.[3] Which is not a bad thing, but it
| doesn't tell us much about what happened.
|
| What I'd hope to hear is that Daniel Micay is in better mental
| health, but they made the almost-certainly wise choice to stop
| engaging with social media, and I can't find much information
| about what actually went down, so I guess it's a question mark.
|
| This is unfortunate because as I understand it, the closest
| competitor to GrapheneOS, CalyxOS, is not nearly as
| sophisticated. I'd really prefer to just be able to trust
| GrapheneOS, but I'm left absolutely unsure about what even
| happened. Did I miss something?
|
| [1]: https://www.youtube.com/watch?v=4To-F6W1NT0
|
| [2]:
| https://web.archive.org/web/20230530063836/https://nitter.fd...
|
| [3]: https://github.com/thestinger
| piaste wrote:
| > What I'd hope to hear is that Daniel Micay is in better
| mental health, but they made the almost-certainly wise choice
| to stop engaging with social media, and I can't find much
| information about what actually went down, so I guess it's a
| question mark.
|
| I mean, it sounds like you have pretty much all the relevant
| information already?
|
| strcat's technical chops were AFAIK never in question, but he
| had a tendency to pick up loud internet fights - to be fair,
| sometimes the other party were also being hostile jerks, but
| sometimes they weren't and he'd just swing at shadows.
|
| After he pissed off Rossmann, he either realized or someone
| close to him made him realize (doesn't really matter which)
| that he should step away from the public square, and he did.
| Now he's just an ordinary, and I presume highly valued,
| contributor to GrapheneOS and to upstream AOSP.
|
| Whether he still lurks the GrapheneOS discussion threads or
| not, or whether he is currently undergoing therapy or just
| chilling with a good book isn't really anyone else's
| business.
|
| What else do you need to know?
| jchw wrote:
| I was curious if that actually happened or not. However, I
| didn't actually see anything about GrapheneOS's leadership
| structure, or any kind of blog or anything where news like
| this would be announced.
|
| So if it happened, who replaced them? Are they trustworthy?
| At least in my cursory searching, I didn't figure out an
| answer to that.
|
| I assume the answer is actually out there, but I don't have
| it.
|
| > Whether he still lurks the GrapheneOS discussion threads
| or not, or whether he is currently undergoing therapy or
| just chilling with a good book isn't really anyone else's
| business.
|
| Sure, whatever. But failing any information about whether
| or not anything happened, I assume they still have root
| access to critical infrastructure. If so... I mean,
| naturally, the problem of trust hasn't changed much. If
| that's the case, then you still need to trust them to trust
| GrapheneOS. Can you? Don't know.
| jacoblambda wrote:
| > So if it happened, who replaced them? Are they
| trustworthy? At least in my cursory searching, I didn't
| figure out an answer to that.
|
| https://github.com/thestinger/daniel.micay.dev/commit/79e
| 44b...
|
| They just stepped down as the official head and stopped
| making public comments. They still are a major developer
| for the project and still seem to own/run parts of the
| project.
| jchw wrote:
| That's an orphaned commit on their personal website (and
| that text doesn't appear anywhere on it), and still
| nobody seems to have any idea who has taken their place.
| I don't believe that someone should be eternally punished
| because of making poor decisions, and with time even a
| pattern of poor decisions can be forgiven, but as it
| stands from the outside there's zero clarity on what, if
| anything, actually happened, no apologies, and ultimately
| no way to know who you're trusting when you install
| GrapheneOS.
|
| On one hand, the track record for the actual OS is still
| completely fine as far as anyone knows. On the other
| hand, the stuff said and done on record is pretty tough
| to swallow for someone you are investing a lot of trust
| into, for an OS that is meant to be privacy and security
| focused.
|
| Like. It's one thing if you are a casual user running
| random ROMs off XDA, the risk is high and the only real
| assurance you get is online reputation and the normal
| assurances of social pressure. But this is software
| endorsed by Edward Snowden and many others whose opinions
| regarding security and privacy are well-regarded. The
| stakes could be quite high for some users. In the light
| of that, I really don't like the situation here at all.
|
| Dismiss it if you want to, but there's really absolutely
| no good reason for this to simply remain effectively
| unaddressed indefinitely.
| refulgentis wrote:
| It sickens me that this tabloid blathering is the 2nd thing
| after the story link and about 1/2 the page after load. The
| disclaimer that it's important because it's an OS, OS' are
| important, thus people who work on OS' are important, and you
| are discussing their mental health because you need to know
| if they'd "abuse their position" is ham-fisted.
| jchw wrote:
| What?
| transpute wrote:
| Arm memory tagging whitepaper (2019),
| https://developer.arm.com/-/media/Arm%20Developer%20Communit...
|
| _> MTE provides a mechanism to detect both [spatial, temporal]
| categories of memory safety violation. MTE assists the detection
| of potential vulnerabilities before deployment by increasing the
| effectiveness of testing and fuzzing. MTE also assists detection
| of vulnerabilities at scale after deployment ... Memory locations
| are tagged by adding four bits of metadata to each 16 bytes of
| physical memory. This is the Tag Granule. Tagging memory
| implements the lock. Pointers, and therefore virtual addresses,
| are modified to contain the key._
| kramerger wrote:
| And Googles announcement from 2019...
|
| https://security.googleblog.com/2019/08/adopting-arm-memory-...
| transpute wrote:
| Project Zero today,
| https://googleprojectzero.blogspot.com/2023/11/first-
| handset...
|
| _> The ability of MTE to detect memory corruption
| exploitation at the first dangerous access is a significant
| improvement in diagnostic and potential security
| effectiveness. The availability of MTE on a production
| handset for the first time is a big step forward, and I think
| there 's real potential to use this technology to make 0-day
| harder._
| soulbadguy wrote:
| Sounds very useful. Even just for testing.
|
| Does x86 have something comparable?
| kafrofrite wrote:
| IIRC, Intel announced about a year later plans to develop
| something similar. That being said, at the time they didn't
| have a specific timeline.
| higherhalf wrote:
| Yes. Kind of.
|
| AMD processors have Upper Address Ignore (UAI) with 7 bits of
| ancillary data, for Intel there is Linear Address Masking (LAM)
| with 6 or 15 bits [1]. The latter has made it into Linux after
| some initial resistance [2].
|
| [1]: https://lwn.net/Articles/888914
|
| [2]: https://www.phoronix.com/news/Intel-LAM-Merged-Linux-6.4
| Liquid_Fire wrote:
| Those sound analogous to the TBI feature in Arm, rather than
| MTE itself (which uses TBI).
| pjmlp wrote:
| They did, MPX, however the design was buggy and eventually
| removed.
|
| Currently x86 is the only mainstrem architecture without a plan
| for hardware memory tagging.
|
| Even RISC-V has an ongoing discussion for hardware memory
| tagging extensions.
| hmry wrote:
| If AMD and Intel drag their feet long enough, CHERI will be
| production ready before then.
| howtofly wrote:
| MTE is something like hardware-blessed address sanitizer. For
| more on MTE, I would recommend this nice short article:
| https://lwn.net/Articles/834289/
| kramerger wrote:
| Wait, is this the first ARMv9 chip?
|
| (Apple M3 is ARMv8.x, with X being 4 or 6 depending on who you
| ask)
| saagarjha wrote:
| Tensor G3 uses Cortex-X3/Cortex-A715/Cortex-510 from ARM, which
| are all ARMv9 cores. That said, there are other, earlier cores
| that also implement the ISA: Cortex-X2/Cortex-A710, for
| example.
| vzaliva wrote:
| I would love to hear a first-hand report of running in this mode
| from a week or two. Any bugs? Performance isses?
| jacoblambda wrote:
| GrapheneOS runs with MTE on by default and it works great. I
| can't speak to issues with stock AOSP or Pixel roms but if
| there are issues, the GrapheneOS team has patched over them
| well enough that I haven't noticed one yet
| jsight wrote:
| I just wish there were a great virtual machine manager for
| Pixels. Apparently it is now possible without root, but only
| nestbox is available, AFAIK. It might be ok, but the monthly fee
| isn't a great deal, IMO.
___________________________________________________________________
(page generated 2023-11-03 23:02 UTC)