News Epic Games: Fortnite kommt für Linux, Easy Anti-Cheat wird überarbeitet

Na hoffentlich lassen sich nicht zu viele Hersteller auf den neuen Anticheat ein.
Proprietäre Software ausserhalb der Sandbox, dann auch noch mit Root-Rechten und am besten auch noch als Kernelmodul? Ne danke, den Dreck können sie behalten...

Auch wenn es schön ist, dass Epic hier endlich etwas zur Vernunft kommt, so ist die Umsetzung leider katastrophal und schadet imho mehr, als dass sie nützt -.-
 
Termy schrieb:
Na hoffentlich lassen sich nicht zu viele Hersteller auf den neuen Anticheat ein.
Proprietäre Software ausserhalb der Sandbox, dann auch noch mit Root-Rechten und am besten auch noch als Kernelmodul? Ne danke, den Dreck können sie behalten...
Root-Kits aka Anti-Cheat bedeutet stumpf die Kontrolle über seinen Computer zu verlieren.
 
  • Gefällt mir
Reaktionen: Termy
flaphoschi schrieb:
Dual-Boot? Wie viele Schritte zurück soll das Opfer machen?
Es ist kein Dual-Boot in dem Sinne, da es sich um ein und die selbe Linux-Installation handelt, nur mit zwei unterschiedlich konfigurierten Einträgen in der Bootauswahl.

So ungewöhnlich ist die Konstellation bei Linux auch gar nicht. Arch Linux bzw. arch-basierte Distributionen haben in der Regel schon standardmäßig zwei Booteinträge (den normalen und einen "Fallback"). Wer Linux mit Btrfs nutzt, hat mitunter auch bewusst mehrere Booteinträge für Btrfs-Snapshots, um bei einem Problem nach einen Systemupdate einfach in einen älteren Snapshot/Systemzustand booten zu können (glaube Fedora macht das ab Werk bei Systemupdates). Und wer seinen Kernel sogar selber kompiliert hat in der Regel auch mindestens zwei Booteinträge - einer für den neuen und einen für den alten Kernel.

Kommt halt jetzt wahlweise ein weitere Booteintrag für die eigene Linux-Installation hinzu, die das System bei Bedarf EAC-konform bootet.
 
  • Gefällt mir
Reaktionen: Deinorius
ebird schrieb:
Und drittens. Unter Linux ist AMD die Wahl. Mein Notebook Starte ich nur einmal im Monat neu. Mit NVidia absolut undenkbar, da stützt es nach spätestens dem drittem Syspend ab.

https://www.phoronix.com/news/NVIDIA-Ubuntu-2025-SnR

https://registry.khronos.org/OpenGL/extensions/NV/NV_robustness_video_memory_purge.txt


Nvidia verliert seit 2016 offiziell den Framebuffer bei VT-Switch, Suspend/Resume und Mode-Switching. Also Standardoperationen. Sie haben die Fehler als Feature definiert und erwarten, dass alle andern Kenntnis davon habe und drum herum programmieren. Sobald der Fehler behoben ist, wird die Extension entfernt.

Es ist 2026! Die Extension ist noch da. Das ist das Qualitätslevel von Nvidia.

PS: Kauft bloß nichts von der Bude. Das ist die Spitze des Eisbergs. Und die weigern sich bis heute Code in Linux und Mesa zu integrieren. Stattdessen eigene Repos mit eigenen Installern. AMD, Intel oder wohl inzwischen auch Qualcomm sind eure Freunde.
Ergänzung ()

mibbio schrieb:
Es ist kein Dual-Boot in dem Sinne, da es sich um ein und die selbe Linux-Installation handelt, nur mit zwei unterschiedlich konfigurierten Einträgen in der Bootauswahl.


Kǒnne wir gleichzeitig den neuen Fix für das WiFi verwenden und per WiFi spielen?

Die Antwort ist wohl negativ? Das wir den Quellcode des Systems anpassen können, ist die Grundidee von Linux.
 
flaphoschi schrieb:
Die Antwort ist wohl negativ? Das wir den Quellcode des Systems anpassen können, ist die Grundidee von Linux.
Dir nimmt doch auch keiner die Freiheit von Linux, wenn du da Wert drauf legst. Niemand zwingt dich, dein Linux EAC-konform zu betreiben, wenn du es nicht willst. Wenn du nichts mit EAC v2 unter Linux spielen willst, ändert sich doch für dich gar nichts und kannst deine Linux-Installation genauso weiterbetreiben, wie bisher.

Für Leute, die Fortnite oder andere Spiele mit EAC unter Linux spielen wollen, gibt es jetzt halt zumindest zusätzlich diese Option dazu.
 
  • Gefällt mir
Reaktionen: HolySkillet
flaphoschi schrieb:
Secure Boot?

Ich glaube die haben nicht mehr alle Latten am Zaun. Signierte Kernel? Das Prinzip von Linux ist, dass ich selbst kompilieren kann!
Heul leise, Stallman, keiner zwingt Dich, Fortnite zu spielen, oder den EGL zu verwenden.

Mache ich genauso wenig, wobei ich sicherlich eine Zweit-SSD zum testen mal dafür herhalten werde, wenn es da ist.
Dafür bin ich doch zu neugierig.

Für mich ist der relevante Teil an der Meldung, dass der Launcher mit seinem Aushängeschild nun endlich Linux erreicht und vor allem, dass es keine komischen extra Sachen braucht, sondern EPIC bewusst das Zeug verwendet, was der Kernel bereits mitbringt.
 
  • Gefällt mir
Reaktionen: Deinorius, sikarr, HolySkillet und eine weitere Person
cbforum.scooter schrieb:
Ich denke, nur wenige Linux-User werden so etwas in ihr System lassen
Wer bisher schon auf Linux ist, kann ja auch offensichtlich darauf verzichten. :) Aber vielleicht ist das der fehlende Tropfen für paar Windows User, doch zu Linux zu wechseln. Die werden mit der Anti-Cheat Lösung dann auch kein Problem haben. Haben sie ja mit Windows jetzt auch nicht.
 
  • Gefällt mir
Reaktionen: Creekground
fortnite.. das war vor fast 10 jahren mal cool :)
 
mibbio schrieb:
Niemand zwingt dich, dein Linux EAC-konform zu betreiben, wenn du es nicht willst.
Das nicht - es steht aber eben zu befürchten, dass viele bislang wunderbar auf Linux funktionierende Spiele auf diesen Bullshit aufsteigen und die Gesamtsituation somit auch für nicht-Fortnitespieler deutlich schlechter als jetzt wird.

Aber Enshittyfication ist ja leider total in... -.-
 
  • Gefällt mir
Reaktionen: HolySkillet und cbmik
Scheiß auf Fortnite an sich, aber das sind gute Nachrichten für die Linux Welt. Vielleicht ziehen weitere Publisher mit :cool_alt:
 
  • Gefällt mir
Reaktionen: Randnotiz und Chrissssss
Ich finde jetzt TPM und SecureBoot nicht tragisch per se.
Man hat die Option seine eigenen Schlüssel zu verwenden und muss auch kein Fortnite spielen.
Mir ist auch lieber wenn ich mich mit Measured Boot darauf verlassen kann dass mein System nicht manipuliert wurde in meiner Abwesenheit und ich meine Schlüssel sicher im TPM abspeichern kann.
 
  • Gefällt mir
Reaktionen: sikarr und compu
mibbio schrieb:
Dir nimmt doch auch keiner die Freiheit von Linux, wenn du da Wert drauf legst. Niemand zwingt dich, dein Linux EAC-konform zu betreiben, wenn du es nicht willst. Wenn du nichts mit EAC v2 unter Linux spielen willst, ändert sich doch für dich gar nichts und kannst deine Linux-Installation genauso weiterbetreiben, wie bisher.

Für Leute, die Fortnite oder andere Spiele mit EAC unter Linux spielen wollen, gibt es jetzt halt zumindest zusätzlich diese Option dazu.
Mit Sicherheit nicht. Ich kann keine eigenen Kernel Module mehr signieren, da ich die Schlüssel einfach nicht habe. Damit kann ich beispielsweise nicht mehr VirtualBox benutzen.

Eigene Kernel sind dadurch auch ausgeschlossen, da die entsprechenden Module von den Distros bereitgestellt und signiert sein werden.

Alles andere würde den Prozess und SecureBoot ad absurdum führen, wenn der Nutzer sowieso alles machen darf.
 
  • Gefällt mir
Reaktionen: Termy
ebird schrieb:
Alles andere würde den Prozess und SecureBoot ad absurdum führen, wenn der Nutzer sowieso alles machen darf.
Es schützt den Nutzer vor Manipulationen seines Systems von aussen. Das ist immer noch der angestrebte Mehrwert.
 
  • Gefällt mir
Reaktionen: HolySkillet
SavageSkull schrieb:
Da ich mich nicht in den rabbit hole von competitiven online spielen aufhalte, könnt ihr mit kurz erklären, warum ein signierter und geschützter Kernel gegen Cheating hilft?
Cheats zielen alle letztendlich darauf ab, Software zur Laufzeit zu beeinflussen. Das tut man, indem man direkten Einfluss auf den Speicher nimmt, in dem die Software gerade läuft. Dazu kann man entweder die Softwarekomponenten oder Libaries, die die Software zur Laufzeit einbindet, vorab manipulieren, wovor sie sich in aller Regel selbst schützt, oder von außen versuchen, die Speicheradressen direkt zu manipulieren.

Die Absolute Hoheit im System über alles hat der Kernel. Er ist der Herr über die Speicheradressen. Im Gegensatz zu anderen Systemen, ist in Linux der Kernel in aller Regel nicht gesondert geschützt. Das heißt der Kernel selbst kann jederzeit beliebig verändert und neugebaut werden, oder man baut dafür Module, so wie das ja auch bei einigen Treibern gemacht wird, die der Kernel zur Laufzeit einbindet.

Damit hat man als User stets volle Kontrolle über die zentrale Instanz im System. Das ist einerseits natürlich etwas Gutes, denn diesen Grad an Souveränität bieten dir proprietäre Systeme nicht, andererseits ist dadurch eben der Systemkern stets vollständig manipulierbar. Cheating auf Kernelebene wäre durch die offene Natur des Systems einfach möglich. Du kannst ja auch jederzeit zwischen den Kerneln wechseln.

Wenn der Kernel aber signiert wird, so beglaubigt jemand dessen Zustand, so wie er ist. Du kannst dir das so vorstellen, als wäre der Kernel eine Zahl und du berechnest daraus die Quersumme. Und danach beglaubigst du eben jene Quersumme durch eine Unterschrift, wieder eine Zahl, und beide werden in bestimmter Weise zusammengerechnet. Jede Veränderung daran würde diese Quersumme verändern, eine entsprechende Prüfung würde also fehlschlagen, weil ein anderes Ergebnis bei der Verrechnung von Signatur und Prüfsumme herauskommt. Das Gleiche kannst du mit Modulen machen. Dadurch kannst du sicherstellen, dass alles in einem vorher abgemachten Zustand ist.

Damit kannst du effektiv Cheating auf Kernel-Ebene entgegenwirken. Wenn die Signaturprüfung Teil des Bootprozesses wird, booten auch andere modifizierte Kernel nicht mehr. Wie weit sowas aber gehen sollte oder muss, ist eine Detail- und Umsetzungsfrage und nicht zum Schluss auch eine Akzeptanzfrage.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: petepow, HolySkillet, jo0 und eine weitere Person
ebird schrieb:
Eigene Kernel sind dadurch auch ausgeschlossen, da die entsprechenden Module von den Distros bereitgestellt und signiert sein werden.
Du kannst auch weiterhin eigene, unsignierte Kernel & Kernelmodule bei deiner Linux-Installation verwenden und parallel dazu eine abgesicherte Bootkonfiguration für EAC-Spiele.

Denn bei Linux kannst du beliebig viele Kernel installiert haben und über entsprechend angelegt Booteinträge auswählen. Wenn du irgendwas mit EAC (oder in Zukunft evtl. auch anderen Anti-Cheats) unter Linux zocken willst, bootest du halt in die abgesicherte Konfiguration mit signiertem Kernel und andernfalls in deine komplett offene Konfiguration.

Dazu brauchst du nicht mehrer Linux-Installationen, zwischen denen man wechselt, sondern nur eine Installation mit zwei verschiedenen Kerneln und Bootkonfigurationen, zwischen denen man dann je nach Bedarf wechseln kann.
 
  • Gefällt mir
Reaktionen: sikarr
mibbio schrieb:
Du kannst auch weiterhin eigene, unsignierte Kernel & Kernelmodule bei deiner Linux-Installation verwenden und parallel dazu eine abgesicherte Bootkonfiguration für EAC-Spiele.
Ich kann mir vorstellen, dass der EGL nochmal mehr Leute nach Linux zieht, wenn jetzt doch Fortnite bald da ist.

Wäre dann vielleicht auch ein interessanter Artikel, den Leuten einen Guide zu geben, wie sie zwei solcher Konfigurationen einfach anlegen können @Kaito Kariheddo 👀
 
Kuristina schrieb:
Bei mir funktionierte zwar auch der Windows Client über Proton, aber nativ ist natürlich besser. :) Auch wenn die Spiele selber nicht nativ sind.

Man muss ja auch als Linux- oder Macuser realistisch sein. "Windows first" ist natürlich bei den meisten Games die Devise. Linux hat es da aber mittlerweile sehr gut mit Proton und auch Wine (was mMn in diesem Zusammenhang oft zu kurz gerät) da ging es einfach extrem voran. Manchmal laufen Dinge damit sogar besser als nativ auf Windows. Unreal-Engine Games z.B. laufen bei mir durchweg "sauberer". Diese komischen Nachladeruckler sind für mich auf Linux im Grunde kein Thema.
Oder auch einfach "praktische" Probleme die man schnell lösen kann. Ein albernes Beispiel: Das Spiel Sifu... das fror bei mir gelegentlich im "Levelscreen" unter Windows einfach ein. Das Problem war auch irgendwie bekannt.. eine echte Lösung gab es nicht. Vermutlich irgendein Windowsupdate oder Setting... Auch auf Proton war das der Fall. Da konnte man es dann aber ganz einfach lösen indem man einfach eine andere Protonversion wählte - 2 Klicks. Von daher ob nativ oder nicht.. juckt im Grunde nur noch selten. Nativ hat halt das Problem, dass es stark am Entwickler liegt wie sehr er seine Spiele betreut und wie sehr er sie für die Zukunft "fit" macht. Wenn z.B. eine bestimmte Version für eine Dependencie/Runtime angegeben wird, reicht das schon, dass nach einem Update dieser Dependencie das Spiel nicht mehr läuft. Das Problem gibts mit Proton/Wine in der Regel eben nicht. Wobei ich finde Steam auch dahingehend nicht "dumm" reagiert hat und einfach Container in Form von "Linux Runtimes" nutzt um dem entgegenzuwirken. Es wäre wünschenswert wenn Software wie Heroic/Bottles/Lutris da auch für Native Spiele solche "Runner/Container" anbieten würden statt dahingehend nur auf unterschiedliche Winerunner zu setzen.

Was den Launcher selbst angeht... sehe keinen Grund Epic-Nativ zu nutzen bei dem hervorragenden/besseren Heroic-Launcher. Überhaupt ist meine Geschichte mit Windows wohl zu Ende erzählt. Für mich ist es nur noch da weil ich den Speicher bisher nicht brauchte. Verwendet wird es seit meinem Wechsel auf Linux praktisch gar nicht mehr. Und ich habe.. so albern das klingt einfach seit dem Wechsel wieder richtig "Spaß" am PC. Irgendwie kam das einer Befreiung gleich. Und das soll jetzt wirklich kein Windowsbashing sein.
 
Randnotiz schrieb:
Wäre dann vielleicht auch ein interessanter Artikel, den Leuten einen Guide zu geben, wie sie zwei solcher Konfigurationen einfach anlegen können
Kann mir auch vorstellen, dass gerade "Gaming-Distributionen" wie CachyOS oder Bazzite eine solche duale Konfiguration in Zukunft sogar voreinrichten und/oder ein Tool bereitstellen, um diese mit wenigen Klicks automatisiert nachträglich bei Bestandsinstallation einzurichten.
 
  • Gefällt mir
Reaktionen: Randnotiz
riloka schrieb:
Es schützt den Nutzer vor Manipulationen seines Systems von aussen. Das ist immer noch der angestrebte Mehrwert.
LOL und Anti Cheat schützt Dich vor genau was bei eigenen Schlüsseln?
Ergänzung ()

mibbio schrieb:
Du kannst auch weiterhin eigene, unsignierte Kernel & Kernelmodule bei deiner Linux-Installation verwenden und parallel dazu eine abgesicherte Bootkonfiguration für EAC-Spiele.

Denn bei Linux kannst du beliebig viele Kernel installiert haben und über entsprechend angelegt Booteinträge auswählen. Wenn du irgendwas mit EAC (oder in Zukunft evtl. auch anderen Anti-Cheats) unter Linux zocken willst, bootest du halt in die abgesicherte Konfiguration mit signiertem Kernel und andernfalls in deine komplett offene Konfiguration.

Dazu brauchst du nicht mehrer Linux-Installationen, zwischen denen man wechselt, sondern nur eine Installation mit zwei verschiedenen Kerneln und Bootkonfigurationen, zwischen denen man dann je nach Bedarf wechseln kann.
LOL. Dann kann ich auch weiterhin den Spiele Bootloader Windows nutzen. Wenn ich ein fremdsystem installieren muss, das einzig dazu dient den Nutzer auszuspionieren, damit man Cheating erkennt, das ist genau das Gegenteil des Sinn und Zwecks von Linux Systemen.

Da nutze ich lieber PCI Pass Throught und starte die Spiele in einer Abgesicherten Umgebung. Performanceverlust ist dann geringer als das Spielen unter Linux - bei unter 3%. Und von den Vorteilen wollen wir gar nicht sprechen
 
Zuletzt bearbeitet:
Zurück
Oben