ARC Prize 2026

Get started and re­ceive of­fi­cial con­test up­dates and news.

No spam. You can un­sub­scribe at any time.

Oracle has banned AI-generated code from OpenJDK con­tri­bu­tions, cit­ing safety, se­cu­rity, and in­tel­lec­tual prop­erty risks. The open-source Java pro­ject stew­ard said de­vel­op­ers can use LLMs pri­vately for de­bug­ging and re­view­ing code but can­not sub­mit AI-generated ma­te­r­ial to repos­i­to­ries, pull re­quests, or other pro­ject chan­nels.

The pol­icy con­trasts sharply with Oracle’s in­ter­nal prac­tices. Co-founder Larry Ellison re­cently de­clared that AI mod­els now write Oracle’s code, whilst co-CEO Mike Sicilia cred­ited AI tools with en­abling smaller en­gi­neer­ing teams to de­liver faster.

Oracle is in­vest­ing $70 bil­lion this year in dat­a­cen­tre ex­pan­sion. The spend­ing spree prompted credit agency S&P to down­grade Oracle’s rat­ing to BBB-, one notch above junk sta­tus, cit­ing un­cer­tain re­turns on in­vest­ment.

Source: thereg­is­ter.com

Assembly Hall of Shame

Overview

Instruction la­tency analy­sis usu­ally fo­cuses on per­for­mance op­ti­miza­tion—mak­ing code run as fast as pos­si­ble. The Assembly Hall of Shame takes the op­po­site ap­proach: search­ing for the ab­solute floor of sin­gle-in­struc­tion per­for­mance.

🏆 Current Champions 🏆

x86: fxrstor64

Strategy: Use fxrstor64 to load 512-byte FPU/MMX/XMM state from a high-la­tency MMIO re­gion in the PCIe fab­ric, then starve the fab­ric while the load is in flight — a fleet of ham­mer cores pounds a dif­fer­ent high-la­tency MMIO reg­is­ter with tight 4-byte reads, sat­u­rat­ing the PCIe root com­plex and end­point with non-posted trans­ac­tions, so CPU 0′s 512-byte fxrstor64 must queue be­hind all that con­tend­ing traf­fic.

Contender: AMD Ryzen 7 5800H

; CPU 0 — timed in­struc­tion movl $0xfcc68830, %rsi fxrstor64 %rsi

; CPUs 1..N — ham­mer loop against a dif­fer­ent high-la­tency lo­ca­tion movl 0xfcc68858, %eax

🏆 Score: 198,002,498,236 cy­cles

🏆 Time: 62 sec­onds

Honorable Mentions

A spec-vi­o­lat­ing un­aligned ymm0 load that forced non-posted dword trans­ac­tions from stalled GPU reg­is­ters was used to break the fun­da­men­tal de­sign of System Management Mode in smi­i­i­i­i­i­i­i­i­i­i­i­i­iii.

vmovdqu 0xfcc003b1, %ymm0

Rules

Instructions may use what­ever setup is nec­es­sary, but only a sin­gle in­struc­tion is el­i­gi­ble to be scored.

Trapped/emulated/virtualized in­struc­tions may only time the trap, not the han­dler.

Instructions must not be in­ter­rupt­ible. rep movs, pause, etc. are dis­qual­i­fied.

Times are nor­mal­ized based on the CPU base clock fre­quency.

All plat­forms must be in their fac­tory stock con­fig­u­ra­tions - no hard­ware mod­i­fi­ca­tions.

x86 Leaderboard

27. nop

Strategy: nop does noth­ing. It opens the leader­board ac­cord­ingly.

Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz

nop

Score: 1 cy­cles

Time: 0 nanosec­onds

26. nop16

Strategy: Regular nop was too short, but how do we make noth­ing take longer? Try a lonnnnnng nop.

Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz

data16 data16 data16 data16 data16 data16 data16 nopl 0x00000000(%%eax,%%eax,1)

Score: 20 cy­cles

Time: 7 nanosec­onds

25. rdtsc

Strategy: Just a ref­er­ence in­struc­tion to get our bear­ings.

Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz

rdtsc

Score: 49 cy­cles

Time: 18 nanosec­onds

24. idiv

Strategy: Use 128-bit div­i­dend (rdx:rax=2:0) with small di­vi­sor to push the quo­tient above the ceil­ing im­posed by sign-ex­ten­sion, dri­ving the longest path through the di­vider mi­croc­ode.

Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz

xorq %rax, %rax  ; rax = 0 (low 64 bits of div­i­dend) movq $2, %rdx  ; rdx = 2 (high 64 bits: full div­i­dend = 2^65) movq $5, %rbx  ; di­vi­sor → quo­tient = 2^65/5 ≈ 7.4×10^18 idivq %rbx

Score: 77 cy­cles

Time: 28 nanosec­onds

23. en­ter

Strategy: Use max­i­mum nest­ing depth (31) to force 30 dis­play-pointer loads and pushes through the mi­croc­ode dis­play-walk path.

Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz

en­ter $0, $31  ; 0 bytes al­lo­cated, nest­ing depth 31 (maximum)

Score: 112 cy­cles

Time: 41 nanosec­onds

22. fldl

Strategy: Try a small de­nor­mal to trig­ger an FP mi­croc­ode as­sist.

Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz

mov­absq $0x0000000000000001, %rax movq %rax, -8(%rsp) fldl -8(%rsp)

Score: 133 cy­cles

Time: 49 nanosec­onds

21. clflush

Strategy: Just en­sure the cache line is dirty.

Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz

clflush (%rax)  ; rax -> dirty cache line res­i­dent in L3

Score: 165 cy­cles

Time: 60 nanosec­onds

20. fsin

Strategy: Use ex­po­nent 0x7ff to reach ‘special val­ue’ pro­cess­ing in mi­croc­ode; pos­i­tive/​neg­a­tive, NaN/inf does­n’t seem to make a dif­fer­ence, go with QNaN.

Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz

mov­absq $0x7fffffffffffffff, %rax movq %rax, -8(%rsp) fldl -8(%rsp) fsin

Score: 257 cy­cles

Time: 94 nanosec­onds

19. mfence

Strategy: Saturate all write-com­bin­ing line-fill buffers with movnti stores to dis­tinct cache lines, forc­ing mfence to drain the full LFB write path to the un­core be­fore re­tir­ing.

Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz

movnti %r9, 0*64(%rdi)  ; ×16 dis­tinct cache lines — sat­u­rate the write-com­bin­ing LFBs ; … movnti %r9, 15*64(%rdi) mfence  ; must drain all pend­ing LFB writes be­fore re­tir­ing

Score: 326 cy­cles

Time: 120 nanosec­onds

18. mov cr3

Strategy: Nothing for now, just check how long it takes to in­val­i­date the TLB.

Contender: AMD Ryzen 7 5800H with Radeon Graphics (Trigkey S5)

mov %rax, %cr3

Score: 352 cy­cles

Time: 110 nanosec­onds

17. fadd

Strategy: Hit x87 FP mi­croc­ode as­sist path by us­ing de­nor­mal source operand.

Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz

fldl sub­norm  ; 1e-310: value < DBL_MIN, bi­ased ex­po­nent = 0 faddl sub­norm  ; source is sub­nor­mal → FP mi­croc­ode as­sist

Score: 677 cy­cles

Time: 249 nanosec­onds

16. split lock

Strategy: Align lock-pre­fixed operand to strad­dle cache-line bound­ary, forc­ing CPU to as­sert the ex­ter­nal bus lock rather than us­ing the fast MESI cache-co­her­ence path.

Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz

; split_ptr % 64 == 63 — dword spans bytes 63 (line N) and 64 – 66 (line N+1) lock xaddl %r9d, (%rdi)

Score: 865 cy­cles

Time: 319 nanosec­onds

15. fdiv -

Strategy: Use sub­nor­mal di­vi­sor, hard­ware hands con­trol to mi­croc­ode as­sist, as­sist nor­mal­izes operand, per­forms the di­vi­sion, then re­stores ar­chi­tec­tural state.

Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz

mov­absq $0x3ff0000000000000, %rax  ; 1.0 (normal div­i­dend) movq %rax, -8(%rsp) fldl -8(%rsp)  ; ST(0) = 1.0

mov­absq $0x0000002000000000, %rax  ; 6.79e-313 (subnormal di­vi­sor) movq %rax, -8(%rsp) fdivl -8(%rsp)  ; ST(0) = 1.0 / sub­nor­mal → FP as­sist

Score: 883 cy­cles

Time: 325 nanosec­onds

The Nixpkgs core team has un­for­tu­nately de­cided to dis­band.

We’re proud to have had the op­por­tu­nity to lead by ex­am­ple in bot­tom‐up, con­sen­sus‐fo­cused gov­er­nance for Nixpkgs, and of our achieve­ments over the past 10 months, in­clud­ing re­form­ing the com­mit­ter del­e­ga­tion process and on­board­ing 19 new com­mit­ters, em­pow­er­ing main­tain­ers by ex­tend­ing the merge bot, re‐es­tab­lish­ing con­tact with GitHub and se­cur­ing the spon­sored Enterprise Cloud up­grade, help­ing triage GHSA-67f2 – 674w-6g63 and track the GitHub se­cu­rity risks ex­posed by that in­ci­dent, and es­tab­lish­ing an ini­tial au­toma­tion/​AI pol­icy, as well as help­ing re­solve many in­ci­dents that were es­ca­lated to us.

However, it has sadly not turned out to be the light­weight role com­pat­i­ble with ac­tive tech­ni­cal con­tri­bu­tion that we had orig­i­nally hoped it would be, and two weeks ago we reached the con­clu­sion that step­ping down is nec­es­sary for our health. We be­lieve that it’s un­sus­tain­able for the team to con­tinue, as demon­strated in part by our at­tri­tion to date. With only one per­son ac­tively ap­ply­ing in re­sponse to our call for new mem­bers and mixed re­sponse to out­reach, re­cruit­ing suf­fi­ciently to keep things healthy looks un­ten­able. Therefore, es­pe­cially with a Steering Committee elec­tion due im­mi­nently, we think the best way for­ward for Nixpkgs gov­er­nance is to be hon­est about the cir­cum­stances that have made dis­solv­ing the team un­avoid­able, in the hopes that it may help fu­ture ef­forts.

Our ex­pe­ri­ence is that the Steering Committee as an in­sti­tu­tion lacks a na­tive in­stinct for the del­e­ga­tion en­vi­sioned by the con­sti­tu­tion, while also not be­ing suf­fi­ciently en­gaged and co­he­sive to han­dle in­di­vid­ual de­ci­sions at those lev­els it­self. This man­i­fests as un­nec­es­sary mi­cro­man­age­ment of teams be­low them and chron­i­cally poor com­mu­ni­ca­tion, in­clud­ing lack of clar­ity from SC mem­bers about when they’re speak­ing for them­selves or rep­re­sent­ing a joint po­si­tion, mat­ters brought to our at­ten­tion with de­sired out­comes al­ready at­tached, tak­ing own­er­ship of is­sues en­tirely within del­e­gated ar­eas with­out in­volv­ing rel­e­vant teams, and in­suf­fi­cient and de­layed re­sponses to con­cerns. The end re­sult has been in­ad­e­quate co­or­di­na­tion on mat­ters like GSoC, grants ini­tia­tives, and AI pol­icy, slow and dif­fi­cult progress on mat­ters rel­e­vant to Nixpkgs like mod­er­a­tion and GitHub org owner re­form, and gen­eral un­cer­tainty about whether we are trusted to au­tonomously make de­ci­sions within our re­mit.

These is­sues have per­sisted de­spite our re­peated at­tempts to dis­cuss them. This is, of course, a sys­temic prob­lem rather than one any sin­gle SC mem­ber could solve; we don’t envy the de­mands of the role, have been im­pressed by the ef­forts of sev­eral mem­bers, and rec­og­nize that every in­di­vid­ual nat­u­rally has lim­ited time and en­ergy and can only do so much in the con­text of a rep­re­sen­ta­tive ma­jori­tar­ian com­mit­tee. Ultimately, though, it leaves the SC not func­tion­ing ef­fec­tively as ei­ther a rep­re­sen­ta­tive back­stop to del­e­ga­tion or a proac­tive de­ci­sion‐mak­ing body. The re­sult­ing en­vi­ron­ment has acted as a con­sis­tent drag on our work, mak­ing it dif­fi­cult for us to ful­fil our con­sti­tu­tional man­date of “Project Direction, Decision-Making, Coordination with the NixOS Foundation Board, and Creation and Management of Teams, where they per­tain to Nixpkgs”.

We be­lieve our high‐trust con­sen­sus de­ci­sion‐mak­ing model has re­sulted in high‐qual­ity dis­cus­sions and good re­sults, and is a bet­ter fit for a del­e­gated lo­cal gov­er­nance team than the ma­jor­ity votes used at the top level by the SC. It’s not news to any­body that our com­mu­nity has many strong di­vides and dis­agree­ments, but nonethe­less we’ve seen many sit­u­a­tions where the abil­ity to call on the core team for a res­o­lu­tion has helped calm ten­sions and led to agree­able out­comes. We con­sider the strong ap­proval for the ini­tial au­toma­tion/​AI pol­icy from peo­ple with highly di­ver­gent views to be proof that it’s pos­si­ble to find paths for­ward and make sig­nif­i­cant im­prove­ments even on seem­ingly in­tractable top­ics.

It in­evitably takes its toll to step in un­der such cir­cum­stances, though. Given our own ex­pe­ri­ences and the his­tory of the pro­ject, we un­der­stand why there is a gen­eral dis­trust of gov­er­nance in the com­mu­nity, and how that has en­cour­aged a com­bat­ive, zero‐sum ap­proach to dis­agree­ments. While those meth­ods may work to ef­fect change de­spite a lead­er­ship vac­uum or to be heard by un­re­spon­sive gov­er­nance, they con­tribute to burnout when lead­er­ship teams are try­ing to en­gage in good faith and fos­ter pro­duc­tive dis­cus­sion. That out­come only re­wards those who don’t care to lis­ten to the com­mu­nity or to pur­sue trust‐based con­sul­ta­tive lead­er­ship at all, fur­ther re­duces the small pool of ex­pe­ri­enced con­trib­u­tors with the time and de­sire to par­tic­i­pate in gov­er­nance, and risks lock­ing in the his­tor­i­cal sta­tus quo of de­ci­sion‐mak­ing by dead­lock and at­tri­tion.

We want to be clear that this de­ci­sion is not the re­sult of any one in­ci­dent, but the cul­mi­na­tion of long‐run­ning pat­terns. The mat­ters in our ju­ris­dic­tion are left with no di­rect owner at pre­sent, with the SC act­ing as the fi­nal back­stop as al­ways. We both plan to re­duce our Nixpkgs in­volve­ment and have no in­ten­tion of run­ning for SC. We still be­lieve in the prin­ci­ples the team was founded on — that clear, light­weight processes for de­ci­sion‐mak­ing and dis­pute res­o­lu­tion are crit­i­cal to strength­en­ing Nixpkgs and ad­dress­ing the prob­lems we’ve seen as con­trib­u­tors — and hope that a gen­uine del­e­ga­tion of en­gaged, tech­ni­cally‐fo­cused, col­lab­o­ra­tive Nixpkgs lead­er­ship by top‐level gov­er­nance will be pos­si­ble in the fu­ture.

We’d like to thank every­one who has sup­ported our work, and re­gret that the team has­n’t been in a po­si­tion to solve these is­sues more com­pre­hen­sively and sus­tain­ably.

On be­half of the Nixpkgs core team:

@alyssais

@emilazy

I use Strava for the ob­vi­ous stuff, like runs, HIIT classes, and the oc­ca­sional com­mute that goes full work­out when I’m des­per­ate to get my steps in. I’m not a pet owner, but I can un­der­stand a dog walk mak­ing it on there, too. The dog may be in­volved, but at least you’re still the one do­ing the walk­ing.

But work­outs up­loaded from a ham­ster wheel? That feels like new ter­ri­tory.

Thijs de Buck, an MRI physi­cist based in Utrecht, the Netherlands, re­cently posted on Reddit that he built a speed and dis­tance tracker for his ham­ster’s wheel, with the data au­to­mat­i­cally up­loaded to Mollie’s own Strava ac­count. Mollie, his 10-month-old ham­ster, is now com­mit­ted to log­ging nightly runs with dis­tance, pace, and time.

One re­cent ac­tiv­ity showed 6.06 miles in 4 hours and 37 min­utes. The next night, Mollie logged 5.55 miles in 3 hours and 56 min­utes.

At first, de Buck just wanted to know how much dis­tance Mollie was cov­er­ing af­ter dark.

“I bought a very cheap bi­cy­cle com­puter pretty much right away,” he told Runner’s World.

That worked at first, be­cause the bike com­puter also used a mag­net and sen­sor. But there was one very ham­ster-spe­cific prob­lem to deal with, as the sen­sor would shift into standby mode once Mollie stopped run­ning for more than five min­utes.

“So if Mollie would take a lunch break at 1 a.m., we’d have no idea how far he’d have run af­ter that,” de Buck said.

The bike com­puter also only gave him to­tal dis­tance, and that just was­n’t go­ing to cut it. De Buck wanted the full Strava treat­ment be­cause ap­par­ently even ham­sters de­serve splits, up­loads, and post-run analy­sis.

The build it­self is clever, but the ba­sic idea is sim­ple. As de Buck ex­plains it, a mag­net on the wheel passes a hall sen­sor, which de­tects each ro­ta­tion. An ESP32—basically a tiny pro­gram­ma­ble com­puter—keeps track of the data overnight. In the morn­ing, he says a script on his lap­top col­lects the in­for­ma­tion, turns it into a Strava-compatible .FIT file, and up­loads the ac­tiv­ity through the Strava API.

“All that re­mains is for me to man­u­ally add a photo of Mollie, and for Mollie to do the ac­tual hard work dur­ing the night,” de Buck said.

De Buck could have stopped once the runs were up­load­ing, but a ham­ster Strava ac­count needed all the ex­tra fea­tures. There’s a tiny or­ganic light-emit­ting diode (OLED) dis­play to show Mollie’s live speed, a code that helps for au­to­mated per­sonal-best track­ing, and more than 100 pos­si­ble run ti­tles, in­clud­ing “The Fast and the Furriest” and “No Rest for the Whiskered,” nat­u­rally.

The one thing he did­n’t plan for was that auto-up­load­ing the files this way re­quired a paid ac­count.

“There was re­ally only one rea­son­able so­lu­tion: my ham­ster now has Strava Premium,” de Buck said.

A ham­ster with this much per­for­mance data was al­ways go­ing to find an au­di­ence. De Buck said the ac­count picked up thou­sands of likes, more than 1,200 ku­dos, and more than 600 fol­low­ers within a week. He also signed Mollie up for Strava’s August 400-minute chal­lenge, and Mollie com­pleted it on Day 2—a wake-up call for any­one still ig­nor­ing their own monthly chal­lenges.

Mollie has been with de Buck since Christmas, and his life out­side train­ing sounds, quite frankly, pretty fo­cused. De Buck de­scribed it as “eat-sleep-run-repeat,” with Mollie spend­ing much of the day hid­den un­der­ground be­fore wak­ing up and al­ter­nat­ing be­tween food and wheel time.

De Buck and Mollie dur­ing a re­cent train­ing ses­sion.

And the lit­tle guy’s not ex­actly phon­ing it in. De Buck said Mollie is av­er­ag­ing al­most 10 kilo­me­ters per night, with a cur­rent record of 10.8 kilo­me­ters af­ter the first week of track­ing.

“I re­ally be­lieve he’ll be able to ex­ceed that soon,” he said.

Mollie also has a weirdly con­sis­tent sched­ule for a ham­ster. Over one seven-day stretch, he started within the same 10-minute win­dow on five nights, be­tween 9:54 and 10:04 p.m. He tends to run in short bursts, some­times reach­ing about 4 to 5 kilo­me­ters per hour on the live mon­i­tor, then hops off for wa­ter.

“Even elite ath­letes need to stay hy­drated,” de Buck joked.

De Buck is a run­ner him­self, which helps ex­plain why the pro­ject ended up with this level of data. He said he loves “tracking every pos­si­ble stat” dur­ing marathon train­ing, so want­ing more in­for­ma­tion about Mollie’s nightly mileage felt nat­ural. He is also deal­ing with a mi­nor in­jury at the mo­ment, which gave him more time to work on the setup.

“When I get back, I think it’ll be a nice chal­lenge to try to match Mollie’s weekly run­ning dis­tance,” he said. “I don’t nor­mally hit 70km a week!”

The next mile­stone is Mollie’s 20th run, when Strava should start giv­ing race pre­dic­tions.

“I can’t wait to see his es­ti­mated 5K and marathon times,” de Buck said, “and whether he’ll man­age to im­prove those pre­dic­tions over time! Although I’m a bit wor­ried he’ll have a bet­ter marathon time than me.”

Sean Abrams was the Senior Editor, Growth and Engagement at Men’s Health. He’s a for­mer hip hop dancer who likes long walks on the beach and large glasses of tequila. You can find his pre­vi­ous work at Maxim, Elite Daily, and AskMen.

Terry Godier, “Browsers Have Standards, the App Store Has Judgment”:

A while ago I tried to sub­mit an iOS app for Dark Hours, my as­tron­omy web­site for nor­mal peo­ple. It was re­jected on the grounds that it was as­trol­ogy.

It has no tarot func­tion, no horo­scopes, and noth­ing that I, or any­one else I’ve asked, would as­so­ci­ate with as­trol­ogy.

A while ago I tried to sub­mit an iOS app for Dark Hours, my as­tron­omy web­site for nor­mal peo­ple. It was re­jected on the grounds that it was as­trol­ogy.

It has no tarot func­tion, no horo­scopes, and noth­ing that I, or any­one else I’ve asked, would as­so­ci­ate with as­trol­ogy.

I penned a nice lit­tle rant two years ago ex­press­ing my fury over the way that kooks pro­mot­ing as­trol­ogy of­ten try to in­sin­u­ate that their voodoo pseu­do­science is even vaguely re­lated to the hard sci­ence of as­tron­omy. And it re­ally is an un­for­tu­nate fluke of the English lan­guage that two sub­jects with a con­tentious re­la­tion­ship are dif­fer­en­ti­ated as words by two let­ters. Even if you know the dif­fer­ence be­tween the two, and care, if you’re read­ing quickly your eyes might con­flate one word with the other.

But if you ac­tu­ally look at Godier’s Dark Hours, for even just a few sec­onds, it is in­stantly ob­vi­ous that it per­tains to the sci­ence of as­tron­omy and has ab­solutely noth­ing — zero, zilch, nada — to do with as­trol­ogy. So even if Apple’s App Store re­viewer mis­read the sub­mis­sion’s de­scrip­tion, and wrongly as­sumed it was yet an­other quack as­trol­ogy app, if they launched it and spent just a few sec­onds pok­ing around, they should have in­stantly rec­og­nized their in­cor­rect as­sump­tion. But that’s not what hap­pened. They re­jected the app on the ut­terly in­cor­rect grounds that it per­tained to as­trol­ogy. If this was an hon­est mis­take from a rea­son­able ju­di­cial board, you’d ex­pect the in­ter­ac­tion with Godier, the de­vel­oper, to have gone some­thing like this:

App Review: REJECTED: Astrology. Developer: No, it’s as­troN­oMy not as­troL­oGy. App Review: Oh, sorry! Carry on, APPROVED.

But that’s not what hap­pened at all. Godier pro­ceeded through a se­ries of es­ca­la­tions up to the App Review Board and the Review Board re­sponded that they de­ter­mined the orig­i­nal re­jec­tion was valid be­cause, I shit you not, “We un­der­stand that the app in­cludes a live tarot read­ing fea­ture.” Which is­n’t even about as­trol­ogy. It’s straight out of Kafka.

Dark Hours is not just merely un­re­lated to as­trol­ogy (let alone tarot-card read­ing). It’s ac­tu­ally ex­quis­itely well-de­signed and painstak­ingly crafted. It’s ex­actly the sort of app that the App Store ought to cel­e­brate and high­light. It does­n’t just be­long in the cat­e­gory of as­tron­omy apps in the App Store, it will raise the qual­ity bar for as­tron­omy apps in the App Store. iOS-ex­clu­sive, na­tive Liquid Glass UI, smooth scrolling, beau­ti­ful ty­pog­ra­phy and lay­out, and way more use­ful as a na­tive mo­bile app than as a web­site. Go check out the web­site and I’m sure you’ll agree that it’s the sort of thing that would be even cooler as an app. But it is an app, and the app is bet­ter and more use­ful than the web­site ver­sion, and Godier has fought to get it ap­proved. But Apple’s App Review Board said no, on fal­la­cious eas­ily-re­futed grounds. This is­n’t just con­trary to the ben­e­fit of de­vel­op­ers, like Godier. It’s ob­vi­ously con­trary to the ben­e­fit of Apple it­self, which should not just ac­cept an app like Dark Hours, but cel­e­brate it as an ex­em­plar of the plat­form.

Mistakes hap­pen. But in a func­tion­ing sys­tem mis­takes get cor­rected, and mis­takes as ob­vi­ous as this one get cor­rected al­most in­stantly and in­clude a quick apol­ogy for the con­fla­tion. The App Store is not a func­tion­ing sys­tem.

NASA just made an in­ter­stel­lar tweak to the Voyager 2 space­craft, known as the “Big Bang”, to keep its re­main­ing 50-year-old sci­ence in­stru­ments run­ning a lit­tle longer.

Voyager 2 and its twin launched in 1977, called Voyager 1, rely on a form of nu­clear bat­tery known as a ra­dioiso­tope ther­mo­elec­tric gen­er­a­tor that uses the heat pro­duced by the de­cay of plu­to­nium. But the sup­ply of plu­to­nium on each probe drops at about four watts a year on each space­craft.

To keep the probe run­ning on this dwin­dling power sup­ply, en­gi­neers re­cently re­duced Voyager 2′s power re­quire­ments by turn­ing off a few non-sci­ence de­vices and us­ing “lower-power al­ter­na­tives” that are still ef­fec­tive enough to keep the space­craft warm while it’s so far from the sun, NASA of­fi­cials said in a state­ment. “The space­craft power mar­gins have grown ra­zor thin, re­quir­ing the team to con­serve en­ergy by shut­ting off non-es­sen­tial de­vices and sys­tems,” NASA of­fi­cials wrote of the mis­sion, which is man­aged by the agen­cy’s Jet Propulsion Laboratory.

The drop in power is hav­ing a mea­sur­able sci­ence im­pact on both space­craft — each has turned off two of their sci­ence in­stru­ments since 2024 alone. While some of these in­stru­ments were shut off af­ter the space­craft fin­ished their his­toric plan­e­tary fly­bys decades ago, oth­ers were turned off due to power re­quire­ments.

Each space­craft ini­tially launched with 10 in­stru­ments, and Voyager 2 is now down to only three in­stru­ments. At first it looked as though Voyager 2 would have to shut down an­other of these in­stru­ments later this year, but luck­ily, the new power shifts will al­low all three to op­er­ate “for at least an­other year,” NASA said.

Voyager 1 will be tasked to do the same “Big Bang” power change “in the com­ing months.” A sig­nal to each space­craft takes nearly 24 hours (or one light-day) to make a one-way jour­ney, and of­fi­cials noted Voyager 1 is fur­ther from Earth than its twin. (Voyager 2 is at about 142 as­tro­nom­i­cal units or sun-Earth dis­tances, while Voyager 1 is near­ing 171 AU.)

The two space­craft ini­tially launched to take ad­van­tage of a rare align­ment be­tween the outer so­lar sys­tem gas gi­ant plan­ets, which in or­der of dis­tance from the sun are Jupiter, Saturn, Uranus and Neptune. Each Voyager space­craft first flew past Jupiter and Saturn, tak­ing un­prece­dented im­agery of the plan­ets and their moons.

Next, Voyager 1 was di­rected to fly above the plane of the so­lar sys­tem (also known as the eclip­tic) while Voyager 2 con­tin­ued fly­ing past Uranus and Neptune, be­com­ing the first space­craft to see these worlds and their moons. Voyager 2′s last plan­e­tary flyby was in 1989.

The two space­craft con­tinue to send sci­en­tific data from in­ter­stel­lar space; Voyager 1 passed into that re­gion in 2012, while Voyager 2 did so in 2018. Voyager 1 is Earth’s most dis­tant space­craft, cur­rently around 15.9 bil­lion miles (25.5 bil­lion kilo­me­ters) away from us, ac­cord­ing to NASA.

Elizabeth Howell (she/her), Ph.D., was a staff writer in the space­flight chan­nel be­tween 2022 and 2024 spe­cial­iz­ing in Canadian space news. She was con­tribut­ing writer for Space.com for 10 years from 2012 to 2024. Elizabeth’s re­port­ing in­cludes mul­ti­ple ex­clu­sives with the White House, lead­ing world cov­er­age about a lost-and-found space tomato on the International Space Station, wit­ness­ing five hu­man space­flight launches on two con­ti­nents, fly­ing par­a­bolic, work­ing in­side a space­suit, and par­tic­i­pat­ing in a sim­u­lated Mars mis­sion. Her lat­est book, “Why Am I Taller?” (ECW Press, 2022) is co-writ­ten with as­tro­naut Dave Williams.

AI cod­ing tools de­liver im­mense value: at Databricks, agen­tic cod­ing has mea­sur­ably im­proved every ve­loc­ity met­ric we track and, in some teams, dri­ven an or­der-of-mag­ni­tude gains in out­put. But nearly every com­pany de­ploy­ing AI tools at scale has hit the same wall: ex­po­nen­tially grow­ing costs. That curve is un­sus­tain­able - left unchecked it will even­tu­ally over­take rev­enue. The spend ex­plo­sion has left en­ter­prises in a para­dox­i­cal sit­u­a­tion: on the one hand, de­sir­ing to max­i­mally push AI trans­for­ma­tion and put pow­er­ful tools in the hands of em­ploy­ees, and on the other hand, hav­ing to rec­on­cile with an ag­gre­gate cost pro­file that threat­ens to un­der­mine or even re­verse the very ef­fi­ciency gains AI pro­vides.

Fortunately, sev­eral of the ear­li­est large-scale adopters have con­verged on a set of ap­proaches that solve this puz­zle, achiev­ing a “dual man­date”: (a) pro­vid­ing broad ac­cess to AI tool­ing, with min­i­mal fric­tion, and (b) keep­ing ag­gre­gate costs in­side of a roughly fixed en­ve­lope per user. This post out­lines proven cost man­age­ment tech­niques, based on our ex­pe­ri­ence at Databricks and con­ver­sa­tions with sev­eral other dig­i­tal-na­tive com­pa­nies, in­clud­ing Stripe, Coinbase, Uber, and Ramp. The table be­low sum­ma­rizes cur­rent tech­niques and as­so­ci­ated sav­ings; the num­bers are di­rec­tional, based on an in­for­mal sur­vey of de­vel­op­ment teams:

Some of these tech­niques can be eas­ily im­ple­mented with soft­ware many com­pa­nies al­ready use. Others re­quire new in­fra­struc­ture, par­tic­u­larly tech­niques that mod­ify end-user clients or shift traf­fic across mod­els. At Databricks, we’ve open sourced or made freely avail­able our key in­fra­struc­ture com­po­nents: an end user meta-har­ness (Omnigent) and our AI Gateway (Unity AI Gateway). For com­plete­ness, this post also cov­ers soft­ware used by other com­pa­nies we spoke with.

The “Efficiency Frontier” for Coding Models

The sin­gle great­est cost lever in mov­ing cod­ing spend to more ef­fi­cient mod­els as they are re­leased. This point bears some dis­cus­sion, as the sim­ple ex­pla­na­tion of “cheaper mod­els” in fact hides a nu­anced re­la­tion­ship be­tween model cost and qual­ity.

Colloquially, the term fron­tier model means “the high­est in­tel­li­gence model,” and fron­tier labs largely fo­cus on ad­vanc­ing peak in­tel­li­gence. Frontier mod­els can now solve novel prob­lems in math or cy­ber­se­cu­rity. But when AI is de­ployed at scale, a dif­fer­ent type of fron­tier mat­ters more: the ef­fi­ciency fron­tier. The ef­fi­ciency fron­tier is de­fined by the set of mod­els that have the best price point for a given level of in­tel­li­gence. Most day-to-day cod­ing does­n’t re­quire math­e­mat­i­cal proofs or novel se­cu­rity in­sights, so what mat­ters in ag­gre­gate is the cost of mod­els that meet the qual­ity bar for typ­i­cal soft­ware en­gi­neer­ing work. This “efficiency fron­tier” is ad­vanc­ing far faster than the in­tel­li­gence fron­tier, with new mod­els be­ing re­leased al­most weekly that pre­sent bet­ter in­tel­li­gence-per-unit-price than prior mod­els.

Cost Lever #1: Moving to open source and lower cost mod­els

Rapidly adopt­ing newer, more ef­fi­cient mod­els de­liv­ers the largest cost wins of any tech­nique. But to cap­ture those gains, a com­pany first needs to know which mod­els ac­tu­ally beat its in­cum­bents. This can be dif­fi­cult be­cause pub­lic bench­marks do a poor job of in­di­cat­ing real-world per­for­mance on cod­ing tasks. To size up new mod­els, many com­pa­nies have built au­to­mated eval­u­a­tions that they be­lieve are more rep­re­sen­ta­tive of their in­ter­nal de­vel­op­ment mix. Databricks re­cently pub­lished an ex­am­ple of such a bench­mark, in which we ob­served highly com­pet­i­tive price/​per­for­mance for GLM mod­els. That bench­mark led us to roll GLM out to de­vel­op­ers in­ter­nally. Often, new mod­els do not ad­vance the ef­fi­ciency fron­tier,and eval­u­a­tions fre­quently pro­duce neg­a­tive re­sults: Stripe found that Opus 4.7 did not mean­ing­fully im­prove qual­ity over Opus 4.6, while in­creas­ing cost. They there­fore de­clined to make Opus 4.7 avail­able in­ter­nally. Databricks saw sim­i­lar cost re­gres­sions when com­par­ing Opus 5.0 to 4.8.

Harness and Model Flexibility

Since the biggest wins come from switch­ing to new mod­els, adopt­ing end user tool­ing that al­lows for model flex­i­bil­ity is be­com­ing a crit­i­cal com­po­nent of keep­ing costs down. The tool most com­monly used in con­cern with a par­tic­u­lar model is called har­ness. Proprietary fron­tier mod­els are in­creas­ingly co-de­signed to work well with spe­cific har­nesses, mean­ing cer­tain har­nesses “work bet­ter” with cer­tain mod­els. If a com­pany wants to pre­serve model in­de­pen­dence there are roughly two ap­proaches:

Ask users to switch har­nesses. One ap­proach is to pro­vide de­vel­op­ers with a set of har­nesses (Claude Code, Codex, or Cursor) and then ask them to switch be­tween har­nesses when a com­pany wants to mi­grate spend to lower cost mod­els. This lets users work in their pre­ferred har­ness when pos­si­ble, but the down­side of this ap­proach is that switch­ing costs for an in­di­vid­ual de­vel­oper can be high. If switch­ing costs be­come too high, the har­ness it­self be­comes a de facto lock-in to a model fam­ily, lim­it­ing the abil­ity to move spend to more com­pet­i­tive mod­els.

Use a meta-har­ness. A new and in­creas­ingly pop­u­lar ap­proach is to use a meta-har­ness that sur­faces a com­mon user ex­pe­ri­ence to de­vel­op­ers while dis­patch­ing re­quests to un­der­ly­ing har­nesses (both pro­pri­etary and open source). This ap­proach al­lows both model/​har­ness in­de­pen­dence while also re­duc­ing de­vel­oper switch­ing costs. At Databricks, this is the de­fault mode for de­vel­op­ers who lever­age Omnigent. Some com­pa­nies we talked to have built cus­tom in­ter­nal meta-har­nesses that in­te­grate with their de­vel­op­ment tool­chain.

Cost Lever #2: Dynamic Request and Task Routing

Instead of ask­ing users to choose task-ap­pro­pri­ate mod­els them­selves, a grow­ing body of re­search sug­gests that au­to­matic model and tool se­lec­tion may fur­ther squeeze ef­fi­ciency out of agen­tic cod­ing work­flows. Routing ap­proaches roughly fall into three cat­e­gories:

Request Level Routing: A state­ful proxy sits in be­tween a client (such as a cod­ing har­ness) and the un­der­ly­ing foun­da­tion mod­els. The proxy at­tempts to route re­quests to the low­est-cost model ca­pa­ble of an­swer­ing each in­fer­ence re­quest. Routing for agen­tic use cases also needs to ac­count for server-side caching, since a cold cache hit has a very high cost for large con­text work­loads. A new wave of prod­ucts is show­ing early, promis­ing re­sults for rout­ing. Examples are: Cursor Router, OpenRouter’s AutoRouter, Ramps Router fea­ture and Databricks own Smart Routing fea­ture in Unity AI Gateway.

Task Level Routing (Meta Harness): A client-side process dis­patches user tasks to dif­fer­ent har­nesses based on the com­plex­ity of the task. A user task might be “rename this com­po­nent from X to Y” (a sim­ple task) or an open-ended task like “Explore de­sign con­sid­er­a­tions that would re­duce la­tency” (a com­plex task). The dis­patcher, of­ten called a Meta Harness, ex­am­ines which level of un­der­ly­ing model is re­quired for a task and then del­e­gates that en­tire end-to-end task to the model. Omnigent is an ex­am­ple of a Meta Harness that sup­ports this pat­tern.

Escalation/Delegation Patterns: A sin­gle har­ness pairs two mod­els (an ex­pen­sive, high-in­tel­li­gence model and a cheap worker model). In some ap­proaches, such as Claude’s Advisor Tool, the cheaper model runs the show and es­ca­lates when it thinks a task re­quires more horse­power. The in­verse pat­tern also ex­ists: In Cognition’s Devin Fusion, the higher cost model is the main loop, and it se­lec­tively out­sources work to a cheaper model.In­ter­nal re­sults at Databricks sug­gest that our AI Gateway Smart Router is able to con­sis­tently re­duce av­er­age task cost by more than 30%, while roughly match­ing the qual­ity of the most ex­pen­sive model in the work­ing set. Other com­pa­nies we spoke with have seen sim­i­lar re­sults.

Cost Lever #3: Giving de­vel­op­ers vis­i­bil­ity, trip­wires, and bud­gets

It may be sur­pris­ing that this en­tire ar­ti­cle did not start and end with “Give users a monthly bud­get and be done with it.” Hard bud­gets, where us­age is en­tirely cut off at a spe­cific spend thresh­old, are of­ten used only as a last re­sort op­tion in every com­pany we spoke with. There are two rea­sons that hard to­ken bud­gets are not par­tic­u­larly ef­fec­tive for AI spend man­age­ment: First, if a de­vel­oper hits their bud­get ceil­ing, cut­ting off fur­ther ac­cess to AI tools would be de­bil­i­tat­ing to pro­duc­tiv­ity. Neither the com­pany or em­ployee ac­tu­ally wants that out­come. Second, at least some of the “high spend­ing” users are in fact those who have achieved mon­u­men­tal ef­fi­ciency gains with AI and are pro­duc­ing im­mense out­put. Discouraging those users is self-de­feat­ing.

Instead of a hard user spend­ing cap, most com­pa­nies are adopt­ing a more nu­anced and pro­gres­sive ap­proach that fo­cuses on vis­i­bil­ity for end users and in­creased de­grees of fric­tion as spend in­creases.

Visibility: Every com­pany we spoke with had a mech­a­nism to pro­vide near-in­stan­ta­neous feed­back to users on their on­go­ing spend, with many also of­fer­ing spe­cific tips or in­sights on how to re­duce spend by us­ing less ex­pen­sive mod­els. It is im­por­tant that users be able to see their spend across all tools, since they may want to in­flu­ence their choice of tool where they get the high­est ROI.A de­vel­oper dash­board at Databricks show­ing ac­tive spend

Visibility: Every com­pany we spoke with had a mech­a­nism to pro­vide near-in­stan­ta­neous feed­back to users on their on­go­ing spend, with many also of­fer­ing spe­cific tips or in­sights on how to re­duce spend by us­ing less ex­pen­sive mod­els. It is im­por­tant that users be able to see their spend across all tools, since they may want to in­flu­ence their choice of tool where they get the high­est ROI.

A de­vel­oper dash­board at Databricks show­ing ac­tive spend

Spend Gates: Developers can be asked to take ac­tions or seek ap­provals at in­creas­ing lev­els of spend. The sim­plest form of spend gate is one that can be self-cleared and serves as a warn­ing that the spend rate is in­creas­ing above some thresh­old. At Databricks, we’ve found self-clear­ing gates a use­ful mech­a­nism for pre­vent­ing ac­ci­den­tal or un­in­ten­tional spend. Further gates can be in­tro­duced that re­quire ex­plicit bud­get ap­proval (often through a man­age­ment chain).

Downshifting: If a de­vel­oper has hit a spend gate, they can be down­shifted to a lower-cost model rather than be­ing en­tirely sus­pended from to­ken ac­cess. Since the low­est-cost mod­els are dras­ti­cally less ex­pen­sive than fron­tier-in­tel­li­gence mod­els, this tech­nique al­lows de­vel­op­ers to con­tinue get­ting work done with­out in­cur­ring mas­sive on­go­ing spend.

Suspension: In the limit case, most sys­tems do re­tain the abil­ity to fully sus­pend users from all to­ken ac­cess. As stated above, this is of­ten a tem­po­rary mea­sure only and the start­ing point for a con­ver­sa­tion about how to ef­fi­ciently lever­age AI.

Cost Lever #4: Reducing Token Overhead

When a user types a rel­a­tively sim­ple re­quest into an AI cod­ing agent (such as “Please in­ves­ti­gate and fix this bug.”), that agent sub­se­quently gath­ers mas­sive amounts of rel­e­vant con­text, in­vokes a large num­ber of tools, searches through the code­base, and in­te­grates skills or sys­tem in­for­ma­tion pro­vided by the com­pany. By the time costly LLM in­fer­ence oc­curs, the user’s ini­tial state­ment ac­counts for only a neg­li­gi­ble frac­tion of the data fed into the AI sys­tem, mean­ing costs are dom­i­nated by con­text the user did not ex­plic­itly in­clude. Techniques in re­duc­ing con­text bloat are still new, but sev­eral promis­ing ap­proaches are be­ing ex­plored, such as:

Coercing more fre­quent com­paction (compression) of the ac­tive con­text.

Using har­nesses that are “less chatty” (more to­ken ef­fi­cient), or tun­ing ex­ist­ing har­nesses to gen­er­ate less to­ken over­head.

Auditing pop­u­lar tools and de­creas­ing their ver­bosity.

Encouraging de­vel­op­ers to break tasks into smaller in­di­vid­ual units of work, de­creas­ing con­text scope.

When con­texts get large, prompt caching also plays a mean­ing­ful role in over­all per­for­mance. Both pro­pri­etary and open source LLMs have set­tings that al­low you to en­able prompt caching and tune how long the cache is stored. Cache writes cost money, but cached reads can dras­ti­cally re­duce per-in­fer­ence cost. This trade-off is de­pen­dent on a com­pa­ny’s spe­cific work­load, so hand-tun­ing of de­fault cache set­tings to in­crease over­all cache hit rate can have dras­tic im­prove­ments to over­all cost.

At Databricks, rel­a­tively sim­ple tun­ing of our har­ness and caching set­tings led to an al­most 50% re­duc­tion in the num­ber of gen­er­ated to­kens and as­so­ci­ated costs, with no ob­served qual­ity degra­da­tion for de­vel­op­ers. We con­tinue to ex­plore tech­niques in this area and think mean­ing­ful ad­di­tional op­ti­miza­tion re­mains pos­si­ble.

A dras­tic re­duc­tion in to­kens per ses­sion by elim­i­nat­ing ex­tra­ne­ous in­fer­ence calls and re­duc­ing cache writes.

The AI Gateway de­sign pat­tern

The tech­niques above had many im­plicit tech­ni­cal re­quire­ments: To rapidly take ad­van­tage of new mod­els, com­pa­nies must have a cen­tral lo­ca­tion where the “model menu” is man­aged, and end-users must have a tool­chain that sup­ports model mix­ing. To pro­vide bud­get vis­i­bil­ity across mul­ti­ple AI tools, a uni­fied cost ob­serv­abil­ity ca­pa­bil­ity must ex­ist. To man­age con­text bloat, com­pa­nies need a way to ob­serve typ­i­cal tool­call out­puts and en­force com­pres­sion or com­paction. These needs are col­lec­tively be­ing solved by a new class of in­fra­struc­ture soft­ware, best de­scribed as an AI Gateway. An AI gate­way is a cen­tral lo­ca­tion where all of the fol­low­ing oc­cur:

Capacity man­age­ment and prox­y­ing of ac­cess to un­der­ly­ing mod­els (both pro­pri­etary and OSS mod­els).

Budget track­ing and en­force­ment, in­clud­ing com­plex bud­get poli­cies such as pro­gres­sive fric­tion lev­els and model down­shift­ing.

Configuration man­age­ment for end-user tools, to en­force model al­low-lists, com­paction set­tings, and other lo­cally me­di­ated as­pects.

Logging of cod­ing ses­sion traces for down­stream ef­fi­ciency analy­sis and bench­mark.

At Databricks, we rely heav­ily on Unity AI Gateway for all of these ca­pa­bil­i­ties.

Putting it all to­gether

The ex­po­nen­tial growth of AI cod­ing costs is not an in­evitabil­ity, it’s a solv­able en­gi­neer­ing and gov­er­nance prob­lem. Companies that have tamed it share a com­mon play­book: re­lent­lessly chase the ef­fi­ciency fron­tier rather than the in­tel­li­gence fron­tier, adopt tool­ing that pre­serves model flex­i­bil­ity, route work in­tel­li­gently to the cheap­est ca­pa­ble model, re­place hard bud­gets with vis­i­bil­ity and pro­gres­sive fric­tion, and cut the to­ken over­head that dom­i­nates real-world spend. None of these tech­niques re­quires sac­ri­fic­ing the pro­duc­tiv­ity gains that made AI adop­tion worth­while in the first place; to­gether, they let or­ga­ni­za­tions sat­isfy the dual man­date of broad, low-fric­tion ac­cess within a pre­dictable cost en­ve­lope.

A set of new in­fra­struc­ture ab­strac­tions is emerg­ing to give com­pa­nies the tools to man­age their costs. At Databricks, we’ve re­leased the key com­po­nents in our cost man­age­ment stack as open source or free soft­ware prod­ucts: Our Unity AI Gateway for cen­tral man­age­ment and Omnigent for de­vel­oper tool­ing. Thousands of com­pa­nies use these com­po­nents every day. We in­vite more com­pa­nies to share find­ings and com­pare tech­niques as this tech­nol­ogy land­scape rapidly evolves.

Acknowledgements: Thank you to in­fra­struc­ture lead­ers at Uber, Stripe, Coinbase, and Ramp who pro­vided com­men­tary and re­views of this ar­ti­cle. Thank you to Thrive Capital for feed­back on an early draft of this ar­ti­cle.

pro­ject:rosen­bridge

: hard­ware back­doors in x86 CPUs

github.com/​xore­ax­eax­eax/​rosen­bridge // do­mas // @xoreaxeaxeax

Overview

pro­ject:rosen­bridge re­veals a hard­ware back­door in some desk­top, lap­top, and em­bed­ded x86 proces­sors.

The back­door al­lows ring 3 (userland) code to cir­cum­vent proces­sor pro­tec­tions to freely read and write ring 0 (kernel) data. While the back­door is typ­i­cally dis­abled (requiring ring 0 ex­e­cu­tion to en­able it), we have found that it is en­abled by de­fault on some sys­tems.

This repos­i­tory con­tains util­i­ties to check if your proces­sor is af­fected, close the back­door if it is pre­sent, and the re­search and tools used to dis­cover and an­a­lyze the back­door.

The Backdoor

The rosen­bridge back­door is a small, non-x86 core em­bed­ded along­side the main x86 core in the CPU. It is en­abled by a model-spe­cific-reg­is­ter con­trol bit, and then tog­gled with a launch-in­struc­tion. The em­bed­ded core is then fed com­mands, wrapped in a spe­cially for­mat­ted x86 in­struc­tion. The core ex­e­cutes these com­mands (which we call the ‘deeply em­bed­ded in­struc­tion set’), by­pass­ing all mem­ory pro­tec­tions and priv­i­lege checks.

While the back­door should re­quire ker­nel level ac­cess to ac­ti­vate, it has been ob­served to be en­abled by de­fault on some sys­tems, al­low­ing any un­priv­i­leged code to mod­ify the ker­nel.

The rosen­bridge back­door is en­tirely dis­tinct from other pub­licly known co­proces­sors on x86 CPUs, such as the Management Engine or Platform Security Processor; it is more deeply em­bed­ded than any known co­proces­sor, hav­ing ac­cess to not only all of the CPU’s mem­ory, but its reg­is­ter file and ex­e­cu­tion pipeline as well.

Affected Systems

It is thought that only VIA C3 CPUs are af­fected by this is­sue. The C-series proces­sors are mar­keted to­wards in­dus­trial au­toma­tion, point-of-sale, ATM, and health­care hard­ware, as well as a va­ri­ety of con­sumer desk­top and lap­top com­put­ers.

Looking Forward

The scope of this vul­ner­a­bil­ity is lim­ited; gen­er­a­tions of CPUs af­ter the C3 no longer con­tain this fea­ture.

This work is re­leased as a case study and thought ex­per­i­ment, il­lus­trat­ing how back­doors might arise in in­creas­ingly com­plex proces­sors, and how re­searchers and end-users might iden­tify such fea­tures. The tools and re­search of­fered here pro­vide the start­ing point for ever-deeper proces­sor vul­ner­a­bil­ity re­search.

Checking your CPU

To check if your CPU is af­fected:

git clone https://​github.com/​xore­ax­eax­eax/​rosen­bridge cd rosen­bridge/​util make sudo mod­probe msr sudo ./bin/check

The pro­vided util­ity must be run on baremetal (not in a vir­tual-ma­chine), and is in an al­pha state. It may crash, panic, or hang sys­tems not con­tain­ing the back­door.

The util­i­ties pro­vided here are de­signed around a spe­cific proces­sor fam­ily and core; un­for­tu­nately, the tools will miss the back­door if it has been even slightly mod­i­fied from the re­searched form.

Closing the Backdoor

Some sys­tems have the back­door en­abled by de­fault, al­low­ing un­priv­i­leged code to gain ker­nel level ac­cess with­out per­mis­sion. If the steps in ‘Checking your CPU’ in­di­cate that your CPU is vul­ner­a­ble, you can in­stall a script to close the back­door early in the boot process:

cd fix make sudo make in­stall re­boot

Note that, even with this, an at­tacker with ker­nel level ac­cess can still re-en­able the back­door. This script is pro­vided as an out­line for cor­rect­ing the is­sue dur­ing the boot process, but will re­quire adap­ta­tion for dif­fer­ent sys­tems.

Tools and Techniques

The sand­sifter util­ity is used ex­ten­sively in this re­search for un­cov­er­ing un­known in­struc­tions.

asm An as­sem­bler for the Deeply Embedded Instruction Set (DEIS). It con­verts pro­grams writ­ten in the cus­tom rosen­bridge as­sem­bly into x86 in­struc­tions, which, when ex­e­cuted fol­low­ing the launch-in­struc­tion, will send the com­mands to the hid­den CPU core.

asm

An as­sem­bler for the Deeply Embedded Instruction Set (DEIS). It con­verts pro­grams writ­ten in the cus­tom rosen­bridge as­sem­bly into x86 in­struc­tions, which, when ex­e­cuted fol­low­ing the launch-in­struc­tion, will send the com­mands to the hid­den CPU core.

esc A proof-of-con­cept of us­ing the rosen­bridge back­door for priv­i­lege es­ca­la­tion.

esc

A proof-of-con­cept of us­ing the rosen­bridge back­door for priv­i­lege es­ca­la­tion.

fix A rough out­line for clos­ing the vul­ner­a­bil­ity on af­fected sys­tems, to the ex­tent pos­si­ble through model-spe­cific-reg­is­ter up­dates.

fix

A rough out­line for clos­ing the vul­ner­a­bil­ity on af­fected sys­tems, to the ex­tent pos­si­ble through model-spe­cific-reg­is­ter up­dates.

fuzz A col­lec­tion of util­i­ties used to fuzz both the x86 and rosen­bridge cores, in or­der to iso­late the un­known launch-in­struc­tion and bridge-in­struc­tion, and re­solve the in­struc­tion for­mat of the rosen­bridge core.

deis The fuzzer used to ex­plore the ef­fects and ca­pa­bil­i­ties of the hid­den CPU core.

exit It is thought that, on some proces­sors, an exit se­quence is needed to switch back to the x86 core at the end of a DEIS se­quence. This di­rec­tory con­tains the util­i­ties used to search for the exit se­quence in early stages of the re­search, but was aban­doned when a proces­sor was found not re­quir­ing any such se­quence.

man­ager A col­lec­tion of python util­i­ties de­signed to mon­i­tor and man­age fuzzing tasks dis­trib­uted across a net­work of work­ers.

wrap A stripped down ver­sion of the sand­sifter fuzzer, used to iden­tify the bridge-in­struc­tion that will send com­mands from the x86 core to the hid­den rosen­bridge core.

fuzz

A col­lec­tion of util­i­ties used to fuzz both the x86 and rosen­bridge cores, in or­der to iso­late the un­known launch-in­struc­tion and bridge-in­struc­tion, and re­solve the in­struc­tion for­mat of the rosen­bridge core.

deis The fuzzer used to ex­plore the ef­fects and ca­pa­bil­i­ties of the hid­den CPU core.

deis

The fuzzer used to ex­plore the ef­fects and ca­pa­bil­i­ties of the hid­den CPU core.

exit It is thought that, on some proces­sors, an exit se­quence is needed to switch back to the x86 core at the end of a DEIS se­quence. This di­rec­tory con­tains the util­i­ties used to search for the exit se­quence in early stages of the re­search, but was aban­doned when a proces­sor was found not re­quir­ing any such se­quence.

exit

It is thought that, on some proces­sors, an exit se­quence is needed to switch back to the x86 core at the end of a DEIS se­quence. This di­rec­tory con­tains the util­i­ties used to search for the exit se­quence in early stages of the re­search, but was aban­doned when a proces­sor was found not re­quir­ing any such se­quence.

man­ager A col­lec­tion of python util­i­ties de­signed to mon­i­tor and man­age fuzzing tasks dis­trib­uted across a net­work of work­ers.

man­ager

A col­lec­tion of python util­i­ties de­signed to mon­i­tor and man­age fuzzing tasks dis­trib­uted across a net­work of work­ers.

wrap A stripped down ver­sion of the sand­sifter fuzzer, used to iden­tify the bridge-in­struc­tion that will send com­mands from the x86 core to the hid­den rosen­bridge core.

wrap

A stripped down ver­sion of the sand­sifter fuzzer, used to iden­tify the bridge-in­struc­tion that will send com­mands from the x86 core to the hid­den rosen­bridge core.

kern A col­lec­tion of helper util­i­ties used to mon­i­tor ker­nel mem­ory and reg­is­ters for changes caused by fuzzed DEIS in­struc­tions.

kern

A col­lec­tion of helper util­i­ties used to mon­i­tor ker­nel mem­ory and reg­is­ters for changes caused by fuzzed DEIS in­struc­tions.

lock Utilities to lock or un­lock the rosen­bridge back­door.

lock

Utilities to lock or un­lock the rosen­bridge back­door.

proc A tool to iden­tify pat­terns from the fuzzing logs to iden­tify classes of DEIS in­struc­tion be­hav­iors.

proc

A tool to iden­tify pat­terns from the fuzzing logs to iden­tify classes of DEIS in­struc­tion be­hav­iors.

test A tool used early in the re­search, to at­tempt to iden­tify the hid­den core’s ar­chi­tec­ture by ex­e­cut­ing known RISC in­struc­tions.

test

A tool used early in the re­search, to at­tempt to iden­tify the hid­den core’s ar­chi­tec­ture by ex­e­cut­ing known RISC in­struc­tions.

util An al­pha-state tool to de­tect whether or not a proces­sor is af­fected by rosen­bridge.

util

An al­pha-state tool to de­tect whether or not a proces­sor is af­fected by rosen­bridge.

References

(TODO: link to whitepa­per)

(TODO: link to slides)

Disclaimer

The de­tails and im­pli­ca­tions pre­sented in this work are the au­thors’ in­fer­ences and opin­ions, de­rived from the re­search de­scribed. The re­search is per­formed and pro­vided with the goal of iden­ti­fy­ing and fix­ing a per­ceived se­cu­rity vul­ner­a­bil­ity on the de­scribed CPUs. VIA proces­sors are renowned for their low power us­age and ex­cel­lence in em­bed­ded de­signs; we be­lieve that the func­tion­al­ity de­scribed was cre­ated in good faith as a use­ful fea­ture for the em­bed­ded mar­ket, and was un­in­ten­tion­ally left en­abled on some early gen­er­a­tions of the proces­sor. No ma­li­cious in­tent is im­plied.

Author

pro­ject:rosen­bridge is a re­search ef­fort from Christopher Domas (@xoreaxeaxeax).