Missa inte! Fyndchans i Månadens Drop

HDMI Forum förbjuder AMD att dela källkoden till HDMI 2.1-drivrutin

Permalänk
Medlem

Har det med HDCP att göra ?

HDCP stands for High-bandwidth Digital Content Protection. The purpose of HDCP is to protect digital copyrighted content as it travels from a device to your TV

Permalänk
Medlem
Skrivet av dlq84:

Nej, tvärt om, security by obscurity funkar inte.

Upplevd säkerhet och riktig säkerhet är olika saker, anar att det är det förstnämnda här.

Finns exploits och bugs i allt software, skilladen är att risken för exploits är större i software med publik kod samt avsaknaden av legalt ansvar för åtgärd och ersättning.

Upplevd säkerhet, beror nog på om du frågar it juristen eller utvecklaren 😆

Permalänk
Medlem
Skrivet av OldComputer:

Vad är det DRM egentligen ska hemlighålla / skydda? Finns ingen upplevd skillnad mellan HDMI rakt igenom och annan källa.

Nu pratar vi inte om kopiering av media utan när man använder annan digital ljudkälla på förstärkaren.

Skrivet av str8forthakill:

Om jag förstår det rätt så är det för att försvåra att ta ut ljudströmmen och videoströmmen separat för just kopiering av okomprimerat material av bluray skivor och andra format. Men DRM skyddet är redan knäckt sedan länge, och det har som jag förstått det inte förbättrats nämnvärt.

De lever lite i det förflutna i sin egna lilla bubbla. Och därför DP är ett bättre val för nästan allt.

Skrivet av Pirum:

HDMI har varit krångligt sedan start. Angående DRM, finns det exempel på filmer eller TV-serier som räddats från piratkopering av just DRM? Skyddar väl möjligen mot privatkopiering, eller ens uppspelning i vissa upplösningar på vissa enheter.

HDMI ersätts väl inte förrän det kommer en bred och bra trådlös standard med backning från väldigt många eller stora tillverkare.

Först och främst misstänker ju jag att det främst är interaktionen DRM <-> DMCA som är viktig för rättighetsinnehavarna.
Dvs att det automatiskt blir olagligt att gå runt ett kopieringsskydd som finns på plats, inte att kopieringsskyddet behöver vara oknäckbart.

Men OM då detta handlar om något DRM-relaterat som AMD skulle behöva inkludera så kan det ju isf handla om hur långt man från officiellt håll (HDMI, dess partners som AMD) i vad man publicerar innan man tummat så mycket på det hela att det kanske slutar räknas.

Och jag antar att själva problemet egentligen snarast är alla de rättighetsrelaterade avtal som kräver att detta DRM finns hela vägen till uppspelande komponent. HDMI är förmodligen "too big to fail" snarare än att de inte öht förstår hur verkligheten ser ut.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Skrivet av str8forthakill:

@lhugo du tappar mig för att du verkar inte förstå vad copyright är.

Även om koden läcks får den inte användas. Skulle Linux lägga till stödet för HDMI 2.1 i sin kernel skulle Linux stämmas för miljardbelopp och få böter tills Linux läggs ned. Detta gäller även "öppna implementationer". Cease and desist, alla som rör koden eller på något sätt släpper stöd, eller ens hostar kod med stödet kommer att stämmas och åka i fängelse.

Det du pratar om är piratkopering, att det på något sätt skulle vara acceptabelt att piratkopiera HDMI Forums källkod, det gäller även kod som baseras på den piratkopierade källkoden.

Jag tror tvärtom att du inte förstår vad copyright är, och vad som skyddas av copyright, patent eller inte skyddas alls.
https://en.wikipedia.org/wiki/Clean_room_design

Permalänk
Medlem
Skrivet av str8forthakill:

@lhugo du tappar mig för att du verkar inte förstå vad copyright är.

Även om koden läcks får den inte användas. Skulle Linux lägga till stödet för HDMI 2.1 i sin kernel skulle Linux stämmas för miljardbelopp och få böter tills Linux läggs ned. Detta gäller även "öppna implementationer". Cease and desist, alla som rör koden eller på något sätt släpper stöd, eller ens hostar kod med stödet kommer att stämmas och åka i fängelse.

Det du pratar om är piratkopering, att det på något sätt skulle vara acceptabelt att piratkopiera HDMI Forums källkod, det gäller även kod som baseras på den piratkopierade källkoden.

Håller du med om att det finns gott om exempel på öppna implenentationer av proprietära protokoll/standarder osv där de tagits fram genom reverse engineering? SAMBA i Linux/MacOS, LibreOffice och LAME är några exempel. Är dessa olagliga?

Om källkoden för AMD:s HDMI 2.1-kod skulle läckas skulle det definitivt underlätta reverse engineering av standarden. Nu är antagligen få här jurister och man skulle kunna argumentera att den som sett den läckta källkoden inte kan göra reverse engineering då den har förkunskap om specen. Min gissning är att detta inte håller rättsligt i praktiken. Den tänkta kod jag syftar på är en helt ny implementation utifrån utvecklarens förståelse av HDMI 2.1-standarden.

Sen en detalj. Källkoden tillhör AMD, specifikationen tillhör HDMI Forum.

Och en fråga - menar du att det är omöjligt att skriva en FOSS drivrutin av HDMI 2.1 oavsett hur den tagits fram eller är det just en kopia av AMD:s kod du syftar på?

Permalänk
Medlem
Skrivet av Kml:

Finns exploits och bugs i allt software, skilladen är att risken för exploits är större i software med publik kod samt avsaknaden av legalt ansvar för åtgärd och ersättning.

Upplevd säkerhet, beror nog på om du frågar it juristen eller utvecklaren 😆

Vad är det du lutar dig mot när du kommer med detta påstående? På samma sätt du argumenterar för att öppen källkod skulle vara mer sårbar på grund av mängden ögon på koden kan man vända på det. Öppen källkod kan lättare granskas avseende eventuella brister än ett slutet dito och bårde på så vis vara säkrare.

Min uppfattning är att detta är en evig fråga inom IT. Det finns starka ekonomiska incitament bakom de som menar att sluten källkod är bättre. Ssmtidigt är det allmänt vedertaget att security by obscurity är dålig design. Vi har även Kerckhoffs princip som relaterar till det förra begreppet. Principen kan sammanfattas med att ett korrekt implementerat kryptografiskt system ska vara lika säkert även om all information om det blir känt sånär som på nyckeln. Detta formulerades om av den amerikanske professorn Steven M. Bellovin som:

In other words — design your system assuming that your opponents know it in detail. (A former official at NSA's National Computer Security Center told me that the standard assumption there was that serial number 1 of any new device was delivered to the Kremlin.)

Permalänk
Medlem
Skrivet av ajn:

Jag tror tvärtom att du inte förstår vad copyright är, och vad som skyddas av copyright, patent eller inte skyddas alls.
https://en.wikipedia.org/wiki/Clean_room_design

Ja Clean room design är termen jag söker i detta fall. Saxat från wikipediaartikeln:

"Typically, a clean-room design is done by having someone examine the system to be reimplemented and having this person write a specification. This specification is then reviewed by a lawyer to ensure that no copyrighted material is included. The specification is then implemented by a team with no connection to the original examiners."

Detta är rätt nära vad som skulle kunna hända vid en hypotetisk läcka av AMD:s kod/reverse engineering. Specen blir känd -> ny kod kan skrivas utifrån denna.

Permalänk
Medlem
Skrivet av Kml:

Finns exploits och bugs i allt software, skilladen är att risken för exploits är större i software med publik kod samt avsaknaden av legalt ansvar för åtgärd och ersättning.

Upplevd säkerhet, beror nog på om du frågar it juristen eller utvecklaren 😆

Skulle vilja se dina belägg för detta för det strider mot all praxis, erfarenhet och kunskap inom it-säkerhet.

Citat:

The investigation reveals that (a) the mean time between vulnerability disclosures was lower for open source software in half of the cases, while the other cases showed no differences, (b) 14 out of 17 software packages showed a significant linear or piecewise linear correlation between the time and the number of published vulnerabilities, and (c) no significant differences in the severity of vulnerabilities were found between open source and closed source software.

All mjukvara, gäller både stängd och öppen, innehåller total avskrivning av legalt ansvar så det är också en punkt du kan stryka helt. Den enda part som du kan hålla legalt ansvarig för är din leverantör och det gör du då via direkt kontrakt och då kvitter det stort om koden är öppen eller stängd.

Skrivet av Swedishchef_90:

Absolut med dsc är en stor risk för artefakter

Stor risk? DSC är visuellt lossless och då få fall med artefakter som man kan googla sig till handlar om dåliga kablar.

Skrivet av GuessWho:

Har det med HDCP att göra ?

HDCP stands for High-bandwidth Digital Content Protection. The purpose of HDCP is to protect digital copyrighted content as it travels from a device to your TV

Nej för HDCP har de redan stöd för i HDMI2.0 som fungerar utan problem med AMD:s drivrutiner, det är enbart 2.1 stödet som HDMI inte tillåter. Så det har inget med DRM eller med kopieringsskydd att göra utan att HDMI IF inte vill att den dyra specifikationen för 2.1 ska kunna publiceras på minsta vis.

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 2400MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 23.10|

Permalänk
Medlem
Skrivet av Kwirek:

Borde vara svårt att inkludera stulen kod? Känns som ett öppet mål att dra inför domstol.

Om det finns kloka människor ( och de finns), kan de genom att titta på den ursprungliga/originala koden bygga sin egen. (Till och med förbättra den.)
Man behöver blind copy-paste. Man behöver uppfattningen om hur den fungerar, för att kunna bygga alternativa mjukvarolösningar.

Permalänk
Medlem
Skrivet av Pirum:

HDMI har varit krångligt sedan start. Angående DRM, finns det exempel på filmer eller TV-serier som räddats från piratkopering av just DRM? Skyddar väl möjligen mot privatkopiering, eller ens uppspelning i vissa upplösningar på vissa enheter.

HDMI ersätts väl inte förrän det kommer en bred och bra trådlös standard med backning från väldigt många eller stora tillverkare.

Beror på vem du frågar

Men min åsikt är förmodligen inte.
HDCP går att kringgå, och är inte särskilt komplicerat.
Det här är något som alla som någonsin försökt spela in eller streama Playstation 3 spel har behövt göra.

Visa signatur

Stationär: Core i9 13900k | Asus X790 ROG Strix Gaming-F | 32GB DDR5 | RX 7900 XT | Lian Li PC-O11 dynamic evo
Laptop: Macbook Air | Apple M1

Permalänk

Tur att vi har displayport.

Permalänk
Medlem
Skrivet av lhugo:

Håller du med om att det finns gott om exempel på öppna implenentationer av proprietära protokoll/standarder osv där de tagits fram genom reverse engineering? SAMBA i Linux/MacOS, LibreOffice och LAME är några exempel. Är dessa olagliga?

Om källkoden för AMD:s HDMI 2.1-kod skulle läckas skulle det definitivt underlätta reverse engineering av standarden. Nu är antagligen få här jurister och man skulle kunna argumentera att den som sett den läckta källkoden inte kan göra reverse engineering då den har förkunskap om specen. Min gissning är att detta inte håller rättsligt i praktiken. Den tänkta kod jag syftar på är en helt ny implementation utifrån utvecklarens förståelse av HDMI 2.1-standarden.

Sen en detalj. Källkoden tillhör AMD, specifikationen tillhör HDMI Forum.

Och en fråga - menar du att det är omöjligt att skriva en FOSS drivrutin av HDMI 2.1 oavsett hur den tagits fram eller är det just en kopia av AMD:s kod du syftar på?

Det du pratar om har redan provats.

ReactOS behövde spendera väldigt lång tid (runt ett år om jag minns rätt) på att riva ut kod skriven av en utvecklare som visade sig ha läst läckt källkod av någon Windows-version. Allt som revs behövde skrivas om eftersom det var funktionalitet som användes och det satte käppar i hjulen för all annan utveckling som inte längre kunde testköras mot ett fungerande kodträd.

Kort sagt så skulle det inte hjälpa alls med läckt källkod, snarare tvärt om eftersom du måste hålla de som har läst den läckta koden borta. Det enda vi kan göra är att vänta och se om AMD kan implementera stödet i firmware istället, om inte på existerande kort så kanske på framtida.

Visa signatur

Mjölnir: Ryzen 9 3900X | X570-I | Ballistix Sport 32GB | Powercolor RX 5500XT 4GB ITX | Kolink Sattelite
Server: Ryzen 5 1400 | X470-F | Ballistix Sport 24GB | ASUS HD 7790 2GB | Sapphire RX 470 8GB ME | NZXT Switch 810

Permalänk
Medlem
Skrivet av Djhg2000:

Det du pratar om har redan provats.

ReactOS behövde spendera väldigt lång tid (runt ett år om jag minns rätt) på att riva ut kod skriven av en utvecklare som visade sig ha läst läckt källkod av någon Windows-version. Allt som revs behövde skrivas om eftersom det var funktionalitet som användes och det satte käppar i hjulen för all annan utveckling som inte längre kunde testköras mot ett fungerande kodträd.

Kort sagt så skulle det inte hjälpa alls med läckt källkod, snarare tvärt om eftersom du måste hålla de som har läst den läckta koden borta. Det enda vi kan göra är att vänta och se om AMD kan implementera stödet i firmware istället, om inte på existerande kort så kanske på framtida.

Man kan fortfarande tänka sig scenariot att man utifrån en läckt källkod formulerar en specifikation för standarden. Denna specifikation kan skickas till en annan grupp utvecklare. De kam sedan skrivan en helt egen implementation. Detta är ju i princip https://en.wikipedia.org/wiki/Clean_room_design och borde vara ok.

Permalänk
Hedersmedlem

Det här är ju så dåligt.

Det sätter ju Linux-användare i en tråkig rävsax.

Ska man välja AMD så att man får drivrutiner som är open source, men där HDMI 2.1-funktionaliteten saknas? Eller ska man välja Nvidia där drivrutinerna är stängda men (antar jag?) man får access till HDMI 2.1?

Det minst dåliga sättet för AMD att lösa detta vore att lägga in HDMI 2.1-stödet i en binär blobb som användarna får välja om de laddar eller ej. Men allra bästa är ju om HDMI Forum drar åt helvete med sin stängda källkod.

Permalänk
Medlem
Skrivet av lhugo:

Man kan fortfarande tänka sig scenariot att man utifrån en läckt källkod formulerar en specifikation för standarden. Denna specifikation kan skickas till en annan grupp utvecklare. De kam sedan skrivan en helt egen implementation. Detta är ju i princip https://en.wikipedia.org/wiki/Clean_room_design och borde vara ok.

Efter fiaskot med ReactOS så tror jag att få är villiga att ta den risken, även om det skulle gå att komma undan med i domstol. Typiskt har man juridisk rådgivning med sig om man ger sig in i något sådant och få privatpersoner kommer att betala för det.

För de som ändå vill ha en fungerande lösning så går det att använda en speciell modell av DP->HDMI-adapter som diskuteras i denna tråd: https://gitlab.freedesktop.org/drm/amd/-/issues/1417#note_221... . Om man vill ha VRR så finns det även en firmware till adaptern med stöd för det här: https://gitlab.freedesktop.org/drm/amd/-/issues/1417#note_226... .

Jag har inte testat lösningen själv och jag vet inte hur svårt det är att byta firmware på adaptern men lösningen finns.

Visa signatur

Mjölnir: Ryzen 9 3900X | X570-I | Ballistix Sport 32GB | Powercolor RX 5500XT 4GB ITX | Kolink Sattelite
Server: Ryzen 5 1400 | X470-F | Ballistix Sport 24GB | ASUS HD 7790 2GB | Sapphire RX 470 8GB ME | NZXT Switch 810

Permalänk
Medlem
Skrivet av Djhg2000:

Efter fiaskot med ReactOS så tror jag att få är villiga att ta den risken, även om det skulle gå att komma undan med i domstol. Typiskt har man juridisk rådgivning med sig om man ger sig in i något sådant och få privatpersoner kommer att betala för det.

För de som ändå vill ha en fungerande lösning så går det att använda en speciell modell av DP->HDMI-adapter som diskuteras i denna tråd: https://gitlab.freedesktop.org/drm/amd/-/issues/1417#note_221... . Om man vill ha VRR så finns det även en firmware till adaptern med stöd för det här: https://gitlab.freedesktop.org/drm/amd/-/issues/1417#note_226... .

Jag har inte testat lösningen själv och jag vet inte hur svårt det är att byta firmware på adaptern men lösningen finns.

Jag är ingen jurist och det finns ju många domstolar världen över. Svårt att veta. Jag tror dock att clean room design kommer att leva vidare. Egentligen är väl ReactOS i sin helhet exempel på det.

Permalänk
Medlem
Skrivet av lhugo:

Jag är ingen jurist och det finns ju många domstolar världen över. Svårt att veta. Jag tror dock att clean room design kommer att leva vidare. Egentligen är väl ReactOS i sin helhet exempel på det.

Det finns ju dock knappt några moderna exempel på det.
I Wikipedia är väl senaste Sony 1999?

Visa signatur

Intel i5 12600k OC 5.2GHz | Arctic Freezer II 240 | MSI Pro Z690 A | 2x 16Gb Corsair LPX 3200MHz | Asus Tuf 4070 Ti | Corsair Rm850x V3 | 2x 1Tb Samsung 980 m2 | 7x Noctua A14x25

Permalänk
Medlem
Skrivet av pv2b:

Det här är ju så dåligt.

Det sätter ju Linux-användare i en tråkig rävsax.

Ska man välja AMD så att man får drivrutiner som är open source, men där HDMI 2.1-funktionaliteten saknas? Eller ska man välja Nvidia där drivrutinerna är stängda men (antar jag?) man får access till HDMI 2.1?

Det minst dåliga sättet för AMD att lösa detta vore att lägga in HDMI 2.1-stödet i en binär blobb som användarna får välja om de laddar eller ej. Men allra bästa är ju om HDMI Forum drar åt helvete med sin stängda källkod.

Man väljer Intel 😎

Permalänk
Hedersmedlem
Skrivet av ajn:

Man väljer Intel 😎

Det löser väl inget i det här specifika fallet?

Permalänk
Medlem
Skrivet av pv2b:

Det löser väl inget i det här specifika fallet?

Både Intel och Nvidia har stöd för HDMI 2.1 med sina öppna Linux-drivrutiner, Intel genom att bara ha DP i GPUn och konvertera till HDMI med en extern krets och Nvidia genom att implementera de känsliga delarna i firmware.

Fast om man redan har ett AMD-kort och kommer på att man vill använda HDMI 2.1 så blir det problem förstås.

Permalänk
Medlem
Skrivet av perost:

Både Intel och Nvidia har stöd för HDMI 2.1 med sina öppna Linux-drivrutiner, Intel genom att bara ha DP i GPUn och konvertera till HDMI med en extern krets och Nvidia genom att implementera de känsliga delarna i firmware.

Fast om man redan har ett AMD-kort och kommer på att man vill använda HDMI 2.1 så blir det problem förstås.

Borde det inte vara möjligt för AMD att ta fram en firmware uppdatering som lägger till implementationen i firmware på befintliga kort? Vore nog den smidigaste för de få som har behovet om nu möjligt.

Visa signatur

Huvuddator: 7800X3D, 2x16GB G.Skill Flare X5 6000MHz CL30, Asus B650E-F, KFA2 RTX 4090 SG, 6TB NVMe/SATA SSD, 42" LG OLED C3 Evo

Never fade away...

Folda för Sweclockers! https://www.sweclockers.com/forum/trad/1348460-faq-kom-igang-...

Permalänk
Medlem
Skrivet av anders190:

Borde det inte vara möjligt för AMD att ta fram en firmware uppdatering som lägger till implementationen i firmware på befintliga kort? Vore nog den smidigaste för de få som har behovet om nu möjligt.

troligtvis inte för de har ingen krets att lägga det i, t.ex nVidia har en hel risc-v cpu (GSP) på kortet som hanterar sånt här, det har inte AMD.

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 2400MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 23.10|

Permalänk
Medlem
Skrivet av F.Ultra:

troligtvis inte för de har ingen krets att lägga det i, t.ex nVidia har en hel risc-v cpu (GSP) på kortet som hanterar sånt här, det har inte AMD.

Ah, låter krångligare då. :/

Visa signatur

Huvuddator: 7800X3D, 2x16GB G.Skill Flare X5 6000MHz CL30, Asus B650E-F, KFA2 RTX 4090 SG, 6TB NVMe/SATA SSD, 42" LG OLED C3 Evo

Never fade away...

Folda för Sweclockers! https://www.sweclockers.com/forum/trad/1348460-faq-kom-igang-...