Hoe is een debug functie direct een beveiligingslek?

Omdat je vanuit de debuginstructies (en dus vanuit een vm) je de hypervisor kunt passeren. Dank u, dag beveiliging.

Misschien een ontwerpfout bij AMD,maar in welke procesoren zit deze mode dan?.
Ik bedoel in welke serie?.

Voldoende reden om AMD voorlopig niet te gebruiken

@anoniem23:25: FTA: "Summary AMD processors Athlon XP and better "

@anoniem22:08: denk je dat soortgelijke rommel niet in intel spul zit? :(

Nonsens.
Deze uitbreidingen op de bekende debug registers zijn alleen door code die in ring 0 draait te gebruiken, net als de bekende debug registers.

Niet dus door VMs, want die draaien niet in ring 0.

News at 11 : wie dezelfde rechten heeft als de hypervisor kan vm's manipuleren.

Dat is geen speculatie, debug mogelijkheden zijn gewoon gedefinieerd in de X86 architectuur, inclusief security eisen (alleen toegankelijk vanaf ring 0).
AMD heeft specifieke extra mogelijkheden (tot nu toe niet publiek bekend/gedocumenteerd) hieraan toegevoegd.

De tot nu toe gereverse-engineerde functionaliteit bestaat uit adres/data maskers voor breakpoints.
Wellicht heeft Intel ook niet gedocumenteerde uitbreidingen.

Je kunt een hoop speculeren over waarom deze extra (en naar ik lees best handige) mogelijkheden geheim gehouden zijn.
Persoonlijk geloof ik niet zo in grote samenzweringen, en denk ik dat de hoofdreden waarschijnlijk een combinatie van financieen en bedrijfs-interne politiek is.
Een feature 'officieel' maken kost altijd geld; Het moet gedocumenteerd worden, er volgt een commitment uit op support (toekomstige chips die backwards compatibel moeten zijn), support engineers/helpdesk moeten ermee bekend zijn, bugs moeten gefixed worden in volgende masker releases etc.
Ik kan me ook levendig indenken dat er verschil van inzicht bestaat tussen een processor architect / hardware developer die dit een nuttige en nodige feature vindt en een 'product manager' die met een business blik kijkt naar welke features een processor moet hebben en welke klanten vragen naar welke functies.
Dat kun je in elk geval horen als je praat over wensen met techneuten van een (sw) vendor, die snappen precies wat nodig is, maar zeggen dat de vraag veel harder binnenkomt wanneer het door een (liefst grote) klant aan een account manager gevraagd wordt.
Ik stel me voor dat het op dat vlak niet anders werkt bij een processor vendor.

Toegang vanaf ring 0 betekent bij VM's (ESX(i), xen, virtualbox) dat ieder vm er gewoon bij kan. En dus ieder ander vm plat kunnen leggen. VM's draaien op hypervisors gewoon in ring 0. Hypervisors hebben bijzondere rechten, die draaien in ring -1.

Dat volgt niet helemaal.
Bij CPU's met hardware support voor virtualisatie (AMD-V, Intel HyperV) is er een mode gemaakt waarbij het guest OS (de VM) kan menen in Ring 0 te draaien, maar waarbij bepaalde instructies en toegang nog steeds via de hypervisor lopen.

Dat is wel efficienter dan wat virtualisatie voorheen moest doen op x86 CPU's om guests een pseudo-ring 0 te geven, en heeft niet de nadelen van partavirtualisatie (guest draait bewust in ring1 en moet hiermee bekend zijn, dit is wat Xen deed)

De ring-1 (ook wel root-mode) niet letterlijk een ring, maar meer een extra mode met in beide toestanden de bestaande rings.
Ring 0 in non-root mode en Ring 0 in root-mode geven alleen niet dezelfde mogelijkheden.
Deze uitgebreidere debug optie (nu ook met maskers voor de hardware breakpoints) verloopt via de gedocumenteerde breakpoint registers (DRx).
Ik zie dus niet wat deze extra opties qua security toe of afdoen aan de 'normale' debug mogelijkheden waar een VMM ook al mee moest omgaan, en Czerno's commentaar daarover lijkt me dus correct.

Als je je nu zorgen wilt maken over obscure VM risico's is 'Ring -2' (System Management Mode - SMM), een soort uitgebreide real mode die overal doorheen mag nog wat relevanter.
Je komt alleen in die mode via een SMI (System Mode Interrupt), en normaal gesproken is de code die daar staat door het BIOS geplaatst en niet (later) door een OS te updaten.

Ik hou het kort en simpel.
Ga er maar (by default) vanuit dat ALLE CHIPS uitgerust zijn met (verborgen) debug (en dus ook backdoor) mogelijkheden.
Het is slechts een kwestie van energie en tijd, voordat deze mogelijkheden worden blootgelegd voor het gewone publiek.

Of dacht je nu echt dat (hardware)chip-fabrikanten je - per ontwerp - enige vorm van privacy gunnen?
Think again :-P and wake up in The Matrix