[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 32 => 64 Bit: Aktueller Stand



Am 12.01.2018 um 18:00 schrieb Martin Steigerwald:

> Angesichts der Meltdown/Spectre-Geschichten habe ich mal wieder daran
> gedacht, meinen letzten 32-bittigen Debian Stretch-Server auf 64-Bit zu
> migrieren.

> Was ist denn da der letzte Stand zu? Offiziell unterstützt ist das
> wahrscheinlich immer noch nicht. Aber was ist die beste,
> erfolgsversprechendste Anleitung dazu?

Grundsätzlich diese Seite aus dem Debian-Wiki:
<https://wiki.debian.org/CrossGrading>
(<https://wiki.debian.org/Migrate32To64Bit> ist veraltet, weist aber
auch im Header auf die neuere Seite hin)

Ich habe das neulich in einer VM durchgezogen, die bislang nur 32-Bit
war. Natürlich vorher einen Snapshot gemacht.
Es war ziemlich haarig und hätte jederzeit schiefgehen können. Deswegen
wirklich nur machen, wenn VM+Snapshot, oder komplettes, getestetes
Offline-Backup vorhanden.

Anfangs lief es wie in der Anleitung beschrieben, irgendwann verhakte
sich dann aber apt-get.

Es artete dann dahingehend aus, dass ich mir per dpkg -l eine Liste
aller Pakete ausgeben ließ, diese auf "^ii" und "i386" filterte, und die
Pakete dann einzeln bzw. in zusammenhängenden Gruppen durch ihr
amd64-Paket ersetzen ließ (mit "apt-get install paketname:amd64").
Dabei kam es des öfteren zu Warnungen, die nur mit "Yes, do as I say!"
zu umgehen waren - aber es ging.
Scheinbar erkennt apt-get nicht, dass man ein essentielles Paket zwar
deinstallieren, aber umgehend durch sein 64-Bit-Pendant ersetzen will,
und gibt daher die Warnungen aus.


> Ich kann natürlich abwarten, inwiefern es für 32-Bit-Fixes gibt. Mir ist
> auch nicht klar, inwieweit der Hypervisor, in diesem Fall ein VMware ESX
> das vielleicht auf Host-Ebene für alle VMs abfangen kann. Wahrscheinlich
> sind dessen Möglichkeiten begrenzt.

Aussage von den QEMU-Entwicklern hierzu war, ist der Host gefixt, können
Gäste nicht mehr Amok laufen und Daten aus dem Host/aus anderen Gästen
lesen. Innerhalb eines Gastes kann natürlich immer noch Mist passieren
(wenn dort z.B. ein Browser läuft und ein JavaScript mit Exploit-Code
startet, kann das zwar keinen anderen Hast und auch nicht den Host
auslesen, wenn der Host gepatcht ist, aber andere Prozesse des
Gastsystems, in dem es läuft, inklusive dessen Kernel-Memory).
Ich würde vermuten, dass das für ESX(i) genauso gilt.

Gruß
Stefan


Reply to: