One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 4593790 |
| Date de publication | 2022-02-23 14:07:46 (vue: 2022-05-13 21:47:30) |
| Titre | Mitigating kernel risks on 32-bit ARM |
| Texte | Posted by Ard Biesheuvel, Google Open Source Security Team Linux kernel support for the 32-bit ARM architecture was contributed in the late 90s, when there was little corporate involvement in Linux development, and most contributors were students or hobbyists, tinkering with development boards, often without much in the way of documentation. Now 20+ years later, 32-bit ARM's maintainer has downgraded its support level to 'odd fixes,' while remaining active as a kernel contributor. This is a common pattern for aging and obsolete architectures: corporate funding for Linux kernel development has tremendously increased the pace of development, but only for architectures with a high return on investment. As a result, the 32-bit ARM port of Linux is essentially in maintenance-only mode, and lacks core Linux advancements such as THREAD_INFO_IN_TASK or VMAP_STACK, which protect against stack overflow attacks.The lack of developer attention does not imply that the 32-bit ARM port has ceased to make economic sense, though. Instead, it has evolved from being one of the spearheads of Linux innovation to a stable and mature platform, and while funding its upstream development may not make sense in the long term, deploying 32-bit ARM into the field today most certainly still makes economic sense when margins are razor thin and BOM costs need to be kept to an absolute minimum. This is why 32-bit ARM is still widely used in embedded systems like set-top boxes and wireless routers.Running 32-bit Linux on 64-bit ARM systemsIronically, at these low price points, the DRAM is actually the dominant component in terms of BOM cost, and many of these 32-bit ARM systems incorporate a cheap ARMv8 SoC that happens to be capable of running in 64-bit mode as well. The reason for running 32-bit applications nonetheless is that these generally use less of the expensive DRAM, and can be deployed directly without the need to recompile the binaries. As 32-bit applications don't need a 64-bit kernel (which itself uses more memory due to its internal use of 64-bit pointers), the product ships with a 32-bit kernel instead.If you're choosing to use a 32-bit kernel for its smaller memory footprint, it's not without risks. You'll likely experience performance issues, unpatched vulnerabilities, and unexpected misbehaviors such as:32-bit kernels generally cannot manage more than 1 GiB of physical memory without resorting to HIGHMEM bouncing, and cannot provide a full virtual address space of 4 GiB to user space, as 64-bit kernels can.Side channels or other flaws caused by silicon errata may exist that haven't been mitigated in 32-bit kernels. For example, the hardening against Spectre and Meltdown vulnerabilities were only done for ARMv7 32-bit only CPUs, and many ARMv8 cores running in 32-bit mode may still be vulnerable (only Cortex-A73 and A75 are handled specifically). And in general, silicon flaws in 64-bit parts that affect the 32-bit kernel are less likely to be found or documented, simply because the silicon validation teams don't prioritize them.The 32-bit ARM kernel does not implement the elaborate alternatives patching framework that is used by other architectures to implement handling of silicon errata, which are particular to certain revisions of certain CPUs. Instead, on 32-bit multiplatform ker |
| Envoyé | Oui |
| Condensat | 20+ 90s a32 a73 a75 absolute accesses accumulating active actually address adjacent adjusting advancements affect affecting against aging all allocated already also alternatives ancient any applications architecture architectures architectures: ard are arm armv7 armv8 as:32 attacks attention attributes available back base because been before behalf behaved being between biesheuvel binaries bit boards bom bookkeeping both bouncing bounded boxes buffer but called can cannot capable case cases caused causing ceased certain certainly changes channels cheap cheaper choice choosing code codebase comes common comparatively compatible complex complexity component components conclusionwith containing contents contexts contracts contributed contributor contributors control core cores coresfor coresthe corporate corrupting corruption cortex cost costly costs cpu cpus cycles data dating decoupling dedicated deployed deploying designs developer development did different direction directly distribution documentation documented does dominant don done downgraded dram drivers dropped due each economic ecosystem effort either elaborate eliminated embedded enable enabled enabling end ends errata especially essentially even ever evolved example exception execute exist existing expected expensive experience exploitable fact far features field fires first fixes flaws flow footprint found framework from full funding general generally gib given global goal google guaranteed guard handful handled handlers handling happen happens hard hardening hardware has have haven heap help hierarchical high highly highmem hobbyists hold however image implement implementation implemented implements imply including incorporate increased info initial innovation instead internal interrupt interrupts investment involvement irq issues its itself keep keeping kept kernel kernels lack lacks land late later layer leaves legacy less level life like likelihood likely linux little lives location long longer lot low maintainer maintenance make makes making manage management many mapped margins mature may meltdown memory minimum misbehaviors missing mitigate mitigated mitigating mode more most moving much multiplatform need needed needs netwinder never new newer nonetheless normally not note now obsolete occur occurring occurs odd off often one ones only open operating opposite option other out over overflow overflows pace part particular parts patching pathological pattern per performance peripherals phasing physical place platform pointers points port posted potentially prevent price prioritize procurement product products program proposed protect protection protects provide provided question randomization rare rather razor reason reasonably recent recompile regions register release relying remaining resorting result resulting return revisions right risc risk risks rodata=full routers routines run running runs safe same securethere security sense set shared ships should side silicon simply since size smaller smp soc soft software some sometimes soon source space spearheads special specifically spectre stable stack stacks stackscoming state step structures students such support supported supportpreventing supports surrounded systems systemsironically task team linux teams technically term terminate terminated terms than them themselves: these thin though thousands thread time times tinkering tiny today top track tremendously trigger try unexpected unnecessarily unpatched unpopulated unrelated unused upstream use used user users uses using usually validation variable vendors version very virtual vmap vulnerabilities vulnerable way well when where which why widely will wireless without workarounds worst years yet you |
| Tags | Patching |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.