Announcement

Collapse
No announcement yet.

MIPS Loongson 3A Benchmarks On Debian

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    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.

    Comment


    • #52
      ?? 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.
      Test signature

      Comment


      • #53
        @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?

        Comment


        • #54
          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.
          Test signature

          Comment


          • #55
            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.

            Comment


            • #56
              Yeah, that sounds feasible. It's one of the reasons we like RAM-based microcode.
              Test signature

              Comment


              • #57
                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.

                Comment


                • #58
                  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...

                  Comment


                  • #59
                    @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!

                    Comment


                    • #60
                      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

                      Comment

                      Working...
                      X