gluch
07/06/12, 01:03:04
Fuente: http://forum.xda-developers.com/showpost.php?p=27074278&postcount=69
It would be beneficial to provide more information on the brick bug to avoid some people getting unnecessarily scared (such as most I9100 users).
This bug requires three things for you to be in danger, and ALL of these conditions must be met for danger:
1) A defective eMMC chip/fwrev that is unable to handle eMMC ERASE commands (command 38) properly. (I'll provide a link with more detail on the nature of the bug later) - This condition is the one Chainfire's new app checks for. By the way, M8G2FA fwrev 0x11 (seen on some Kindle Fires) is also suspected of being defective.
2) A recovery binary that attempts to erase partitions when formatting them. Most ICS recovery binaries fit in this category, most Gingerbread recoveries do not attempt to perform an erase operation so are safe. Note that also, an affected update-binary in a ZIP could be a cause of problems too. (e.g. flashing a firmware that has an ICS update-binary and formats the partition could cause a problem even with a "safe" recovery.) So a kernel can be repacked with a "safe" CWM (such as the most recent CF-Root releases) but it will still only be partially safe.
3) A kernel that allows attempts to erase a partition to actually happen. (as opposed to reporting "not supported" and doing nothing.) - A common way of rendering a kernel safe is to remove MMC_CAP_ERASE from the capability flags in drivers/mmc/mshci.c
As of June 6, 2012, this is what I know as far as kernels that meet condition 3:
All GT-I9100 ICS leaks and official releases are SAFE (MMC_CAP_ERASE not present)
All kernels based on GT-I9100 ICS Update4 sources are SAFE (MMC_CAP_ERASE not present) - This includes all CM9 nightlies for SGH-I777, GT-I9100, and GT-N7000
All GT-N7000 ICS leaks are UNSAFE
All GT-N7000 ICS official kernels are UNSAFE
All kernels built from the GT-N7000 sources are UNSAFE unless the following condition is met:
MMC_CAP_ERASE is removed from the capability flags in drivers/mmc/host/mshci.c - check the kernel features for this. Franco.kernel R3 and later and all Speedmod ICS releases are SAFE due to this.
All SHW-M250S/K/L ICS kernels are suspected to be UNSAFE
All SHW-M250S/K/L ICS source releases as of this date are UNSAFE (SHW-M250L Update4 was the cause of the SiyahKernel 3.1rc6 incident. Other Siyah releases are SAFE)
All SPH-D710 ICS releases as of this date are UNSAFE - Rumor has it that the official OTA may have a fixed kernel, but it is recommended to consider this kernel UNSAFE until source code is released and can be reviewed.
It's hard to get ALL of the cases and evaluate them, but in general in terms of levels of danger (As of June 6, 2012 - this could change with time):
SPH-D710 users are in the most danger - They have no official ICS releases AND the I9100 Update4 source base can't be used to build a usable kernel for their device without major developer work
GT-N7000 users are second on the list - They are the only ones outside of Korea to receive official ICS updates that trigger the eMMC firmware defect. However, I9100 Update4 sources required only minor work to create "safe" kernels, and developers know the proper procedure for rendering the official N7000 Update3 source drop "safe"
SGH-I777 users are next - I777 leaks proved to be dangerous a month or so ago. However, the SGH-I777 required the least amount of work to be able to use the GT-I9100 Update4 source base, and as a result, with the exception of the leaks themselves, nearly all I777 ICS kernels are based off of safe source code bases.
GT-I9100 users are in the least danger - No leak, official binary release, or source code release for this device has been dangerous. Only one I9100 kernel has ever proven dangerous and that was quickly pulled by its developer.
I am not evaluating the SHW-M250S/K/L in the above list, as while I know their source and binaries are dangerous, the language/culture barrier means we have very little information on how this fiasco is panning out for those users.
__________________
Samsung Galaxy S II (SGH-I777) -CM9, sometimes self-debloated/deodexed TW
Samsung Galaxy Player 5.0 (YP-G70) - Stock system + my kernel
Galaxy Tab 10.1 - Cyanogenmod 9
Samsung Confuse 4G (SGH-I997) - Self-deodexed/debloated UCLB3 + my kernel
Last devices - Huawei S7 and AT&T Tilt2 (RHOD300) running XDAndroid FRX06 (still have them collecting dust)
My Github profile - Some Android stuff, some AVR stuff
An excellent post on "noobs vs. developers"
A few opinions on kernel development "good practices"
TRADUCCION POR VENABLES
Bueno os dejo la Traducción a ver si lo entendéis mejor así:
Sería beneficioso para proporcionar más información sobre el Bug del Brick para evitar que algunas personas no estén tan están asustados (como la mayoría de los usuarios del i9100).
Para este error se necesitan 3 cosas para que pueda estar en peligro, y todas estas condiciones se deben cumplir para el peligro:
1) Un chip defectuoso eMMC / fwrev que es incapaz de controlar los comandos del máster Erasmus Mundus comando ERASE (38) correctamente. (Voy a ofrecer un enlace con más detalles sobre la naturaleza del error más tarde) - Esta condición es nuevos controles de Chainfire para aplicaciones. Por cierto, M8G2FA fwrev 0x11 (visto en algunos Kindle Fire) es también sospechoso de ser defectuoso.
2) Un recovery Binario que intenta borrar las particiones cuando está formateando. La mayoría de los Recoverys Binarios de ICS en esta categoría, la mayoria de las Recuperaciones de Gingerbread no intenta llevar a cabo una operación de borrado así que son seguros.
Hay que tener en cuenta también, una de actualización binaria afectada en un ZIP podría ser una causa de problemas. (Por ejemplo, flashear un firmware ICS que tiene una actualización binaria y formatea la partición podría causar un problema, incluso haciendolo a través de un recovery seguro.) Así que un Kernel puede ser embalados (Repack) de nuevo con un CWM "seguro" (como las más recientes versiones de CF-Root), pero todavía sólo parcialmente a salvo.
3) Un Kernel que permite borrar una partición puede ocurrir en realidad. (En contraposición a la presentación de informes "no compatible" y no hacer nada.) - Una forma común de hacer una copia de un kernel Seguro es eliminar MMC_CAP_ERASE desde / MMC / mshci.c
A partir del 06 de junio 2012, esto es lo que sé en cuanto a los Kernels que cumplen con la condición 3:
GALAXY S2
Todas las ICS Leaks GT-i9100 y oficiales son SEGURAS (MMC_CAP_ERASE no aparece)
Todos los Kernels basados en GT-i9100 ICS Update4 son SEGUROS (MMC_CAP_ERASE no aparece) - Esto incluye todos las CM9 nightlies SGH-I777 para, GT-i9100, y GT-N7000
Todas las ICS LEAKS GT-N7000 son INSEGUROS
Todos los Kernels oficiales ICS son INSEGUROS
Todos los Kernles construidos a partir de las fuentes GT-N7000 son INSEGUROS a menos que la siguiente condición: MMC_CAP_ERASE se se haya retirado de / mmc / host / mshci.c - comprobar las características del Kernel para confirmar esto.
Kernel Franco R3 y posteriores y todos los de Speedmod ICS son SEGUROS debido a esto.
Todos los Kernels SHW-M250S/K/L ICS se sospecha que son INSEGUROS
Todos los ICS Oficiales de SHW-M250S/K/L a partir de esta fecha son INSEGUROS(ACS-M250L Update4 fue la causa del incidente SiyahKernel 3.1rc6. Otras versiones Siyah son SEGUROS)
Todos los comunicados de SPH-D710 ICS partir de esta fecha son INSEGUROS - Se rumorea que la OTA Oficial puede tener un Kernel Fixed, pero se recomienda tener en cuenta este Kernel como INSEGURO hasta que el código fuente esté liberado y pueda ser revisado.
Es difícil obtener todos los casos y evaluarlos, pero en general en términos de niveles de peligro (el 6 de junio de 2012 - esto podría cambiar con el tiempo):
Los Usuarios del SPH-D710 están en mayor peligro - No tienen versiones de ICS oficiales y el i9100 Update4 no puede ser utilizado para construir un kernel utilizable para su dispositivo sin un trabajo importante de desarrollador
Los Usuarios del GT-N7000 Están en 2º lugar en la lista - Ellos son los únicos fuera de Corea en recibir actualizaciones oficiales de ICS que provocan el defecto del firmware eMMC. Sin embargo, i9100 el Update4 requiere menor trabajo para la creación de Kernels Seguros, y los desarrolladores saben el procedimiento adecuado para hacer que la oficial N7000 Update3 sea segura.
SGH-I777 usuarios están al lado - I777 Las Leakcs han demostrado ser peligrosas o menos un mes atrás. Sin embargo, el SGH-I777 requiere mucha menor cantidad de trabajo para ser capaz de utilizar el GT-i9100 Update4 base, y como resultado, con la excepción de las propias Leaks, casi todos los Kernels de I777 ICS que se basan fuera del código fuente son seguras.
GT-i9100 Son los usuarios que están en menor peligro - Sin Leaks Oficiales o la liberación del código fuente. Sólo un núcleo de i9100 ha demostrado ser peligroso y que fue retirado rápidamente por el desarrollador.
No estoy evaluando la SHW-M250S/K/L en la lista anterior, ya que mientras aunque yo sé de su fuente y que los binarios son peligrosos, la barrera del idioma / cultura significa que tenemos muy poca información acerca de este Fiasco.
Añadido por ikaos la traduccion de venables para la mejor compresión de todos.
It would be beneficial to provide more information on the brick bug to avoid some people getting unnecessarily scared (such as most I9100 users).
This bug requires three things for you to be in danger, and ALL of these conditions must be met for danger:
1) A defective eMMC chip/fwrev that is unable to handle eMMC ERASE commands (command 38) properly. (I'll provide a link with more detail on the nature of the bug later) - This condition is the one Chainfire's new app checks for. By the way, M8G2FA fwrev 0x11 (seen on some Kindle Fires) is also suspected of being defective.
2) A recovery binary that attempts to erase partitions when formatting them. Most ICS recovery binaries fit in this category, most Gingerbread recoveries do not attempt to perform an erase operation so are safe. Note that also, an affected update-binary in a ZIP could be a cause of problems too. (e.g. flashing a firmware that has an ICS update-binary and formats the partition could cause a problem even with a "safe" recovery.) So a kernel can be repacked with a "safe" CWM (such as the most recent CF-Root releases) but it will still only be partially safe.
3) A kernel that allows attempts to erase a partition to actually happen. (as opposed to reporting "not supported" and doing nothing.) - A common way of rendering a kernel safe is to remove MMC_CAP_ERASE from the capability flags in drivers/mmc/mshci.c
As of June 6, 2012, this is what I know as far as kernels that meet condition 3:
All GT-I9100 ICS leaks and official releases are SAFE (MMC_CAP_ERASE not present)
All kernels based on GT-I9100 ICS Update4 sources are SAFE (MMC_CAP_ERASE not present) - This includes all CM9 nightlies for SGH-I777, GT-I9100, and GT-N7000
All GT-N7000 ICS leaks are UNSAFE
All GT-N7000 ICS official kernels are UNSAFE
All kernels built from the GT-N7000 sources are UNSAFE unless the following condition is met:
MMC_CAP_ERASE is removed from the capability flags in drivers/mmc/host/mshci.c - check the kernel features for this. Franco.kernel R3 and later and all Speedmod ICS releases are SAFE due to this.
All SHW-M250S/K/L ICS kernels are suspected to be UNSAFE
All SHW-M250S/K/L ICS source releases as of this date are UNSAFE (SHW-M250L Update4 was the cause of the SiyahKernel 3.1rc6 incident. Other Siyah releases are SAFE)
All SPH-D710 ICS releases as of this date are UNSAFE - Rumor has it that the official OTA may have a fixed kernel, but it is recommended to consider this kernel UNSAFE until source code is released and can be reviewed.
It's hard to get ALL of the cases and evaluate them, but in general in terms of levels of danger (As of June 6, 2012 - this could change with time):
SPH-D710 users are in the most danger - They have no official ICS releases AND the I9100 Update4 source base can't be used to build a usable kernel for their device without major developer work
GT-N7000 users are second on the list - They are the only ones outside of Korea to receive official ICS updates that trigger the eMMC firmware defect. However, I9100 Update4 sources required only minor work to create "safe" kernels, and developers know the proper procedure for rendering the official N7000 Update3 source drop "safe"
SGH-I777 users are next - I777 leaks proved to be dangerous a month or so ago. However, the SGH-I777 required the least amount of work to be able to use the GT-I9100 Update4 source base, and as a result, with the exception of the leaks themselves, nearly all I777 ICS kernels are based off of safe source code bases.
GT-I9100 users are in the least danger - No leak, official binary release, or source code release for this device has been dangerous. Only one I9100 kernel has ever proven dangerous and that was quickly pulled by its developer.
I am not evaluating the SHW-M250S/K/L in the above list, as while I know their source and binaries are dangerous, the language/culture barrier means we have very little information on how this fiasco is panning out for those users.
__________________
Samsung Galaxy S II (SGH-I777) -CM9, sometimes self-debloated/deodexed TW
Samsung Galaxy Player 5.0 (YP-G70) - Stock system + my kernel
Galaxy Tab 10.1 - Cyanogenmod 9
Samsung Confuse 4G (SGH-I997) - Self-deodexed/debloated UCLB3 + my kernel
Last devices - Huawei S7 and AT&T Tilt2 (RHOD300) running XDAndroid FRX06 (still have them collecting dust)
My Github profile - Some Android stuff, some AVR stuff
An excellent post on "noobs vs. developers"
A few opinions on kernel development "good practices"
TRADUCCION POR VENABLES
Bueno os dejo la Traducción a ver si lo entendéis mejor así:
Sería beneficioso para proporcionar más información sobre el Bug del Brick para evitar que algunas personas no estén tan están asustados (como la mayoría de los usuarios del i9100).
Para este error se necesitan 3 cosas para que pueda estar en peligro, y todas estas condiciones se deben cumplir para el peligro:
1) Un chip defectuoso eMMC / fwrev que es incapaz de controlar los comandos del máster Erasmus Mundus comando ERASE (38) correctamente. (Voy a ofrecer un enlace con más detalles sobre la naturaleza del error más tarde) - Esta condición es nuevos controles de Chainfire para aplicaciones. Por cierto, M8G2FA fwrev 0x11 (visto en algunos Kindle Fire) es también sospechoso de ser defectuoso.
2) Un recovery Binario que intenta borrar las particiones cuando está formateando. La mayoría de los Recoverys Binarios de ICS en esta categoría, la mayoria de las Recuperaciones de Gingerbread no intenta llevar a cabo una operación de borrado así que son seguros.
Hay que tener en cuenta también, una de actualización binaria afectada en un ZIP podría ser una causa de problemas. (Por ejemplo, flashear un firmware ICS que tiene una actualización binaria y formatea la partición podría causar un problema, incluso haciendolo a través de un recovery seguro.) Así que un Kernel puede ser embalados (Repack) de nuevo con un CWM "seguro" (como las más recientes versiones de CF-Root), pero todavía sólo parcialmente a salvo.
3) Un Kernel que permite borrar una partición puede ocurrir en realidad. (En contraposición a la presentación de informes "no compatible" y no hacer nada.) - Una forma común de hacer una copia de un kernel Seguro es eliminar MMC_CAP_ERASE desde / MMC / mshci.c
A partir del 06 de junio 2012, esto es lo que sé en cuanto a los Kernels que cumplen con la condición 3:
GALAXY S2
Todas las ICS Leaks GT-i9100 y oficiales son SEGURAS (MMC_CAP_ERASE no aparece)
Todos los Kernels basados en GT-i9100 ICS Update4 son SEGUROS (MMC_CAP_ERASE no aparece) - Esto incluye todos las CM9 nightlies SGH-I777 para, GT-i9100, y GT-N7000
Todas las ICS LEAKS GT-N7000 son INSEGUROS
Todos los Kernels oficiales ICS son INSEGUROS
Todos los Kernles construidos a partir de las fuentes GT-N7000 son INSEGUROS a menos que la siguiente condición: MMC_CAP_ERASE se se haya retirado de / mmc / host / mshci.c - comprobar las características del Kernel para confirmar esto.
Kernel Franco R3 y posteriores y todos los de Speedmod ICS son SEGUROS debido a esto.
Todos los Kernels SHW-M250S/K/L ICS se sospecha que son INSEGUROS
Todos los ICS Oficiales de SHW-M250S/K/L a partir de esta fecha son INSEGUROS(ACS-M250L Update4 fue la causa del incidente SiyahKernel 3.1rc6. Otras versiones Siyah son SEGUROS)
Todos los comunicados de SPH-D710 ICS partir de esta fecha son INSEGUROS - Se rumorea que la OTA Oficial puede tener un Kernel Fixed, pero se recomienda tener en cuenta este Kernel como INSEGURO hasta que el código fuente esté liberado y pueda ser revisado.
Es difícil obtener todos los casos y evaluarlos, pero en general en términos de niveles de peligro (el 6 de junio de 2012 - esto podría cambiar con el tiempo):
Los Usuarios del SPH-D710 están en mayor peligro - No tienen versiones de ICS oficiales y el i9100 Update4 no puede ser utilizado para construir un kernel utilizable para su dispositivo sin un trabajo importante de desarrollador
Los Usuarios del GT-N7000 Están en 2º lugar en la lista - Ellos son los únicos fuera de Corea en recibir actualizaciones oficiales de ICS que provocan el defecto del firmware eMMC. Sin embargo, i9100 el Update4 requiere menor trabajo para la creación de Kernels Seguros, y los desarrolladores saben el procedimiento adecuado para hacer que la oficial N7000 Update3 sea segura.
SGH-I777 usuarios están al lado - I777 Las Leakcs han demostrado ser peligrosas o menos un mes atrás. Sin embargo, el SGH-I777 requiere mucha menor cantidad de trabajo para ser capaz de utilizar el GT-i9100 Update4 base, y como resultado, con la excepción de las propias Leaks, casi todos los Kernels de I777 ICS que se basan fuera del código fuente son seguras.
GT-i9100 Son los usuarios que están en menor peligro - Sin Leaks Oficiales o la liberación del código fuente. Sólo un núcleo de i9100 ha demostrado ser peligroso y que fue retirado rápidamente por el desarrollador.
No estoy evaluando la SHW-M250S/K/L en la lista anterior, ya que mientras aunque yo sé de su fuente y que los binarios son peligrosos, la barrera del idioma / cultura significa que tenemos muy poca información acerca de este Fiasco.
Añadido por ikaos la traduccion de venables para la mejor compresión de todos.