Page 6 of 22 FirstFirst ... 4567816 ... LastLast
Results 51 to 60 of 217

Thread: MIPS Loongson 3A Benchmarks On Debian

  1. #51

    Default

    Quote Originally Posted by Kano View Post
    @maldorordiscord

    in order to upload microcode to the cpu you have to be root. when you are root already you can do much smarter things and what you want the least is that the system just crashes. you can allocate much ram even as user permanently, so you do not even need to get root to make one system unstable.
    If the command is to sabotage the enemy's system on a maximum level then
    you just replace the bios and cpu microcode with a broken one and you make sure the update function of the microcode is disabled after that. You do not just crash the enemy system you damage it permanently. The goal here is to destroy the enemy hardware forever.
    I known cases where hardware was thrown in the garbage after such a attack.
    The financial damage is enormous.

  2. #52
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    ?? AFAIK the microcode update mechanisms are all RAM-based -- patches are read in and applied via CAM for CPU, the entire microcode image is loaded for GPU.

    Don't think there is any way to permanently update the microcode *or* to disable future updates except by flashing the BIOS, and bricking hardware via bad BIOS flash is already a time-honoured tradition.

  3. #53

    Default

    @bridgman
    There are System on a chip systems with mram or flash inside of the chip for the microcode.
    http://en.wikipedia.org/wiki/System_on_a_chip
    This means on SoC systems there is a way to permanently update the microcode and in the same way its posible to disable future updates.

    Bridgman: "and bricking hardware via bad BIOS flash is already a time-honoured tradition."

    Isn't it funny? In the future we will see more complex bricking via update the microcode on SoC attacks.
    In my point of view Loongson is a succesfull, and a very conservative in the meaning of Kerckhoff's principle, Murphy's law and open source as a security strategy, concept.
    Any remuneration for this?

  4. #54
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    Quote Originally Posted by maldorordiscord View Post
    There are System on a chip systems with mram or flash inside of the chip for the microcode.
    http://en.wikipedia.org/wiki/System_on_a_chip
    This means on SoC systems there is a way to permanently update the microcode and in the same way its posible to disable future updates.
    No, it means you can flash the ROM just like on a regular PC. If you're suggesting there is a way on specific SOC parts to disable further flashing please provide something more specific than the Wikipedia SOC page.

  5. #55

    Default

    Quote Originally Posted by bridgman View Post
    No, it means you can flash the ROM just like on a regular PC. If you're suggesting there is a way on specific SOC parts to disable further flashing please provide something more specific than the Wikipedia SOC page.
    Now the "Security through obscurity" kicks in and I can't be more specific without breaking laws.
    Censorship makes every conversation so incredibly fruitful.

    But a colleague had such a case he had to dispose of the hardware and he also replace the bios chip with a fresh healthy one without any effect to the trojan.
    The Virus / Trojan was placed in a microcontroller with own flash firmware/microcode in some parts of the hardware and infect the OS automatically.

    If you are interested i can give you an email address via PM then you can ask.

  6. #56
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    Yeah, that sounds feasible. It's one of the reasons we like RAM-based microcode.

  7. #57

    Default

    Quote Originally Posted by bridgman View Post
    Yeah, that sounds feasible. It's one of the reasons we like RAM-based microcode.
    I sent you an email with the source just in case you don't believe me.

  8. #58
    Join Date
    Aug 2007
    Posts
    6,598

    Default

    You do not even need an attacker that a system stops working because of bad nvram values which are stored inside the same chip. Basically all uefi based systems work that way and could stop working - even when you dont flash the chip, just by toying around with efibootmgr. An old system with bios would be working again with a cmos clear. As this seems to be more common that a system does not post anymore with uefi you find now 2 chips on more expensive boards to have got a fallback. Sadly some boards (mainly gigabyte) solder em directly, not a good idea...

  9. #59

    Default

    @kano

    maybe the chinese government should pay for a virus to attack the "efibootmgr" on non-free systems to sell more Loongson systems
    The best arguments for selling Loongson really comes from the enemy you really do not need any sale point with such a enemy.
    Best sale points: there is no "Secure" Boot UEFI and you can not run Windows on it and the closed source adobe flash player will not run on it!

  10. #60
    Join Date
    Apr 2012
    Location
    Germany
    Posts
    205

    Default

    Quote Originally Posted by maldorordiscord View Post
    you can not run Windows on it and the closed source adobe flash player will not run on it!
    Yes, you can. That is why it has acceleration units for qemu: http://en.wikipedia.org/wiki/Loongso..._x86_emulation

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •