back to article Google: How to make any AMD Zen CPU always generate 4 as a random number

Googlers have not only figured out how to break AMD's security – allowing them to load unofficial microcode into its processors to modify the silicon's behavior as they wish – but also demonstrated this by producing a microcode patch that makes the chips always output 4 when asked for a random number. And this ability to …

  1. Nate Amsden

    if trust is a true issue

    Don't use someone else's computer to run your VMs on regardless. There will always be security issues around that. Most people probably don't care. But I would never put much stock in such features myself.

    I for one am not a fan of all this nrw fangled signing and encryption stuff in thr name of security to take control away from the person who owns or operates the equipment.

    1. diodesign (Written by Reg staff) Silver badge

      Zero trust

      Be as that may, SEV is a selling point for AMD and Intel (or the equiv thereof). It's for paranoid-leaning corporations that don't trust or can't trust their hypervisor / cloud provider's internal security.

      Orgs like banks, governments, and healthcare providers that want to put sensitive info on other people's computers, basically.

      C.

      1. john.jones.name
        Mushroom

        This is HUGE TPM certs need to be changed

        I dont think everyone has thought this through

        they need to blow a efuse

        change certificates

        EVERYTHING is over for the AMD64 / X86-64 they need to change and update all the root of trust

        far out this is what happens when you have HARDWARE that is MODIFIABLE (which most is now) you need a way of changing certificates and verifying them...

        good luck

        John Jones

    2. Anonymous Coward Silver badge
      Facepalm

      Re: if trust is a true issue

      Do you think owning the hardware vs a VM on someone else's hardware is really any different to an upstream supply-chain issue where the hardware that you own is already compromised before you buy it?

      If you're paranoid enough, there's always another bogeyman.

      1. Anonymous Coward
        Anonymous Coward

        Re: if trust is a true issue

        > where the hardware that you own is already compromised before you buy it?

        Once you've bought it, you can wipe it (and check for other issues that, unlike this one, can't be fixed with a patch).

        That is why you have IT guys to buy in and prep your machines for you.

        If the machines are not under your control in the first place...

        1. phuzz Silver badge

          Re: if trust is a true issue

          That's fine for most of us, but for the really paranoid, it's entirely possible for a nation-state level adversary to intercept your hardware during shipping, and modify it in ways that aren't detectable without effectively destroying that hardware.

          It's known that the NSA did this with Cisco gear.

          Not something most of us have to worry about though.

        2. Elongated Muskrat Silver badge

          Re: if trust is a true issue

          Once you've bought it, you can wipe it (and check for other issues that, unlike this one, can't be fixed with a patch).

          You probably need to read this (again?)

          Reflections on Trusting Trust

          If you can't trust a compiler, even one you have compiled yourself (because you can't trust the tools used to compile that compiler), then you certainly can't trust that the microcode, on the sealed CPU, which you can't see the inside of has been wiped, if there's a potential for the tools that do so (on the same chip) to be compromised in such a way that they don't have to be truthful about having performed that wipe.

          Edit - this is probably the (very appropriate) sentence to focus on:

          In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode [my emphasis].

          And there we have it, Ken Thompson foresaw this exact issue in... August 1984.

          1. Roo
            Windows

            Re: if trust is a true issue

            There is very little that is genuinely new in computing - the majority of the legwork was already wrapped up by the mid-70s. I remember reading that article in the early 90s, having used late 70s vintage machines for some time, what he wrote wasn't radical or obscure back then - it was a simple statement of fact that was obvious to anyone who had booted up a minicomputer and compiled up a UNIX system. That isn't taking anything away from Ken, his genius was seeing it as a problem and spelling it out clearly for PHBs.

            1. that one in the corner Silver badge

              Re: if trust is a true issue

              Well said.

              We tried to come up with pragmatic responses to that article; the best we had (which you can still argue over 'til the cows come home) was you would try to ensure that you weren't trapped within that closed set of pre-built tools that were looking for their own source code to poison. Which only works if you have a multiplicity of compilers/assemblers/linkers - i.e. the entire toolchain - and use these to build each other. Which may mean going back to the original way the first compilers come about, hand-building the first one and bootstrapping up. Or being convinced that it is not feasible for all of your toolchains to be able to recognise and poison every other toolchain from its sources.

              This takes up a lot of time and energy. Especially if you are going to start worrying about, say, poisoned AMD microcode; it was easier back in the 1980s: if you had modifiable microcode it wasn't all cryptographically signed and you had a chance to play the same game.

              Which, of course, then drops you straight into the hoary old question of how much work you feel is necessary to adequately protect yourself.

              Which is bottom-line the question that every paper about security and trust poses.

    3. Roo
      Windows

      Re: if trust is a true issue

      You have to put your balls in a vice whenever you run your code on someone else's hardware anyway, this just shows (yet again) that the Emperor has no Clothes.

      With respect to shagging microcode, the attack surface could be severely curtailed by separating the *control* plane from the data plane (aka code the user can load onto the box). In the old days this was an 8" floppy hooked up to a service processor. These days I guess it would be a *physically* separate network cable (or USB port) on a BMC (or maybe a 8" floppy controller hooked up to a service processor USB port for traditionalists).

      Quit trying to make everything *too* easy.

    4. teknopaul

      Re: if trust is a true issue

      Surprised you got down voted.

      It true everyone develops on the cloud for good reasons, so this stuff is important, but if you have even a medium sized system to run, building your own with open tools makes financial sense, isn't that hard, and shields you from almost all of the security issues that are surfacing nowadays.

      Real remote execs that can by pass firewalls and a layered architecture do happen, but are few and far between.

      As in this case the likes of Google give shops a decent window to apply patches before releasing details to the the wild.

      Where I work, we get hit harder by vulns in off the shelf kit than in anything we do ourselves.

  2. Blazde Silver badge
    Happy

    'likely a reference to XKCD'

    I like to think they flipped a coin to decide between the xkcd reference and the Dilbert reference (nine nine nine nine..)

    (props to those who worked on this by the way, looking forward to 5th March to geek out on the microcode details a bit)

    1. Elongated Muskrat Silver badge

      Re: 'likely a reference to XKCD'

      I like to think that they looked at Randall Munroe, then at Scott Adams, and then back at Randall Munroe, gave a nod, looked back at Scott, shook their collective heads, then back to Randall, and said, "nah, not that ****wit, what was that xkcd reference again?"

      1. BossHobo

        Re: 'likely a reference to XKCD'

        My thoughts exactly. S Adams lost a lot of fans when he decided to "say what he really felt" out there on the internet.

        1. RAMChYLD

          Re: 'likely a reference to XKCD'

          Yeah. Its sad tho. I looked up to him until his true colors as a magat trumpet came out. Actually it turns out that a few people I held in high regards prior are magat trumpets. I'm really disappointed in their delusions and disappointed at myself for thinking of them as great people.

    2. bpfh

      Re: 'likely a reference to XKCD'

      First thing that came to mind was Dilbert 9999999... : https://www.random.org/analysis/dilbert.jpg

  3. Wily Veteran
    Joke

    The Answer?

    I'm truly surprised they didn't make the return value 42.

    1. Anonymous Coward
      Anonymous Coward

      Re: The Answer?

      Those pesky kids, no appreciation of the classics!

  4. Anonymous Coward
    Anonymous Coward

    "An insecure hash"

    Doubtless they used MD5, because really, it's secure enough for basically everything.

    However, it's probably an offer to the US TLA's -- something that's "secure" unless you have Google-level resources to reverse an MD5 HMAC. It needs a signing key with the data, hmac generated. That, and the microcode documentation so that the US can make these chips do whatever they deign. Because there's only *one* key to find (like government backdoor'd encryption, *again*), it makes a prime target for entities with resources -- and, as demonstrated, backdoors will be unlocked by others. Now that someone other than the TLA has shown its vulnerability, "Oops, hah, hah, that was a *total* oversight, lets get that fixed, then. Here ya go."

    This is not something that anyone but nations and corporations the size of Google can achieve -- and how much did Google spend on this, anyway? I guess about $50 000 to crack an md5 hash these days, right? for a proof-of-concept?

    The fix is obvious: code the microcode to check for a *second* signature, of sha1 or sha256 (I wonder which -- if it's not at least sha256, then they're again giving concessions to the TLA's). Then the newer microcode is included in the BIOS of patched motherboards (so that it can't be worked around), and loaded (first!!?) for anything else -- preventing later loading of an attack microcode. All microcodes will still have to be signed (first) with the MD5 hmac, so that *any* cpu (even older ones) will accept the real microcode patched with a stronger hash, but then the same microcode will reverify itself (because theater), and verify the stronger hash of any later-loaded microcode (forward-security).

    1. Anonymous Coward
      Anonymous Coward

      Re: "An insecure hash"

      There are some space concerns in microcode. There seems to be not that much room for extra security checks.

    2. FIA Silver badge

      Re: "An insecure hash"

      Doubtless they used MD5, because really, it's secure enough for basically everything.

      Unless you have a modern GPU.

      1. Jou (Mxyzptlk) Silver badge

        Re: "An insecure hash"

        So CRC8 is not good enough any more?

    3. Elongated Muskrat Silver badge

      Re: "An insecure hash"

      "The fix is obvious" sounds an awful lot like "roll my own security", which is the same fallacy as "I can't think of a way to break this, so nobody else can," a special case of the Dunning Kruger effect.

      In terms of "breaking" MD5 hashes, from the wikipedia page on MD5:

      A collision attack exists that can find collisions within seconds on a computer with a 2.6 GHz Pentium 4 processor (complexity of 224.1). Further, there is also a chosen-prefix collision attack that can produce a collision for two inputs with specified prefixes within seconds, using off-the-shelf computing hardware (complexity 239). The ability to find collisions has been greatly aided by the use of off-the-shelf GPUs. On an NVIDIA GeForce 8400GS graphics processor, 16–18 million hashes per second can be computed. An NVIDIA GeForce 8800 Ultra can calculate more than 200 million hashes per second.

      In other words, if this was "secured" by hashing with MD5 (which isn't encryption, but might be used as a checksum), it could be broken by a single modern mid-range laptop in a matter of seconds.

      At the very least, I would expect that this would be secured using some form of asymmetric key encryption (hopefully the most up-to-date SHA or equivalent), and then the only ways to have broken it would be for the signing (private) key to have been leaked, or to be otherwise insecure or predictable, or to have used a side-channel attack to circumvent the cryptographic verification entirely, due to a weak implementation (basically telling the chip that the data it was loading into its microcode cache had already been decrypted by itself).

  5. An_Old_Dog Silver badge
    Windows

    In the Olden Days, Microcode

    ... could be written and loaded by ordinary users; it wasn't special secret sauce. Some uni group wrote a set of microcode for a DEC PDP 11 which turned it into a Pick machine (the Pick instruction set was optimised for datsbase operations).

    1. CommonBloke

      Re: In the Olden Days, Microcode

      Not only that, this exploit only works if you have full admin/root access to the machine. At that point, being able to inject microcode straight into the CPU is exactly the same as just running a BIOS update.

      1. Elongated Muskrat Silver badge

        Re: In the Olden Days, Microcode

        Yeah, the difference is that the microcode is supposed to be encrypted and signed (and in the case of AMD, apparently obfuscated as well, not that this is any real security), because since the days of the PDP-11, something called computer security has become a thing. If you think it's not necessary, please go and install Windows XP on your PC and connect it to the internet.

        Arguably, BIOS updates should be more secure (and who knows, maybe some motherboards do have BIOS that is cryptographically signed?), but the underlying point is: you can't actually trust that, either. The thing is, you can make arbitrary modifications to anything you own, but the idea here is that you can't make modifications that appear to work to a CPU's microcode unless you know exactly what you are doing. A "standard car analogy" might be that you can do whatever you like to the ECU in your car, but if you don't know what you're doing, the most likely result is that your car won't start.

        1. riking

          Re: In the Olden Days, Microcode

          Yeah, the concrete exploitation pathway for regular people is compromised update channels, which historically have not had much effort put into their security because "everyone knows" the CPU does strong verification already.

          1. Elongated Muskrat Silver badge

            Re: In the Olden Days, Microcode

            The simplest case of this being a DNS redirect to "I'm a genuine update / verification server, me". I could probably configure my Pi-hole to do this in seconds.

            1. Rahbut

              Re: In the Olden Days, Microcode

              DNS I get, but that's another reason for using HTTPS because you're less likely to have the matching cert.

      2. Roo
        Windows

        Re: In the Olden Days, Microcode

        With VAX-11/78x's you needed *physical* access to the machine in order to update the microcode (as it was uploaded by the "console" when the machine was bootstrapped), so it wasn't (as easy?) to compromise the machine - even though it the vendor actively encouraged customers to write microcode. :)

    2. rcxb Silver badge

      Re: In the Olden Days, Microcode

      I've been waiting 9 years for someone to mention Pick, so I could post this video:

      https://www.youtube.com/watch?v=CFpK8440HZA

      Right up there with the MS-DOS 5 Promo, and Don't Copy That Floppy.

  6. Jamesit

    Epyc fail

    1. Korev Silver badge
      Coat

      I'm sure AMD are Ryzen to the challenge of fixing it though...

      1. HandlesMessiah

        Take my upvotes, you magnificent bastards

        1. Rob Daglish

          Indeed. I'm surprised nobody has called in an Epyc fail yet, though.

  7. Sceptic Tank Silver badge
    Trollface

    The train is waiting attestation

    Hehehe, here is me laughing in my beard about having to issue a microcode patch to patch up the faulty microcode and to my great astonishment I see that that is exactly what AMD did. I'm assuming that a power cycle reverts the CPU to it's factory state and either the BIOS or OS has to load the patches. So how can you trust such a device if your BIOS likely spends 70% of its initialisation time loading rootkits from NSA / Chinese Military / North Korea / Russia / Finland.

    Ok, so I've never had a beard. Just happy in a strange way that I got the Intel CPU despite the challenges over there. I was kinda surprised that this type of attack took so long to happen.

    1. Nick Ryan

      Re: The train is waiting attestation

      The microcode in the CPU is essentially firmware, it is not written to every time the system starts.

      Long BIOS initialisation periods are largely down to having to support hardware that is a crock of shite and doesn't use sensible initialisation processes. Some of these hardware devices are so bad that the concept of transactional computing, as in answer/response, is entirely lost on them and this requires that the startup processes have to wait for a long time out rather than trust that the hardware is implemented competently and will respond quickly.

      1. Blazde Silver badge

        Re: The train is waiting attestation

        The microcode in the CPU is essentially firmware, it is not written to every time the system starts

        The microcode update needs to be applied to each CPU every time it boots. It can be done in BIOS or by the OS. In this case you obviously want to get it loaded as early as possible to protect against malicious microcode updates later in the boot process.

        The CPU itself does have ROM containing the original microcode at manufacture. That's what gets patched, but the patch vanishes when it's powered off.

        1. Roland6 Silver badge

          Re: The train is waiting attestation

          > “The CPU itself does have ROM containing the original microcode at manufacture”

          Given they also include a TPM, there is no reason why that ROM isn’t rewriteable…

          I assume this is what Intel already do, for the IME…

          1. Blazde Silver badge

            Re: The train is waiting attestation

            IME is chipset, and as far as I know the same goes for any persistent rewritable capability.

            The firmware-TPM/IME/PSP stuff is all very complicated, intentionally obscure and implemented differently by AMD & Intel but I believe the CPU's role is only to provide a secure environment for doing sensitive operations, and to provide a hidden Endorsement Key which is unique and burned into the CPU once at manufacture and which acts as a root of trust to verify data stored outside the CPU hasn't been tampered with. Both those features are non-volatile.

            The CPU is a single chunk of silicon (or, lately a few chunks cleverly stuck together). It would increase manufacturing complexity, reduce yields, increase failure rates to put different memory technology on the same silicon. It wouldn't buy extra physical security because non-volatile memory becomes less non-volatile in easily reproducible situations (depending on the technology: power loss, freezing, x-rays, etc), and it would probably not be all that cheap to make it tolerate CPU heat cycles.

            I suppose the nightmare scenario is that this microcode vulnerability can be used to expose the CPU's Endorsement Key, which then forever compromises the CPU without the presence of any actual backdoor..

    2. Irongut Silver badge

      Re: The train is waiting attestation

      > so I've never had a beard

      Yeah we can tell by your lack of knowledge about how CPUs, BIOS and microcode work.

  8. Anonymous Coward
    Anonymous Coward

    Just a reminder ...

    ... that a CPU is a computer running a microOS in itself. [1]

    And every computer can be hacked.

    [1] Size of AMD microcode approximately that of the Commodore 64 Kernal.

    1. Nick Ryan

      Re: Just a reminder ...

      C64 kernel was a few bytes under 8K. It was a fine exercise in cramming as much stuff into as little space as possible. Unfortunately it also meant that more useful slightly higher level operations weren't a part of the kernel requiring them to be rewritten. But then one of the first initiation tasks that a developer who wrote much for the C64, which was inevitably games, was to swap out the kernel and basic ROMs, freeing up 16K of RAM for use.

    2. Michael Strorm Silver badge

      This is possibly what you were alluding to, but to elaborate...

      ...another reminder that- since the Pentium Pro and Pentium II came out over 25 years ago- all Intel's new "x86" CPUs (*) have essentially been an x86-compatible "wrapper" around a sort-of-RISC-style non-native-x86 core (**) that converts instructions on the fly.

      (*) And presumably AMD's too, from some point on, though I don't know when.

      (**) It's been disputed by some whether or not the core was actually RISC or not. (***) But the point either wayis that it's definitely *not* native x86.

      (***) Besides which, it's quite feasible they could have completely redesigned or replaced the internal architecture once or more since then- since it's not supposed to be user-accessible, all that matters is that new models can continue to run x86-compatible code.

      1. Anonymous Coward
        Anonymous Coward

        Re: This is possibly what you were alluding to, but to elaborate...

        Indeed, it's all RISC below the surface.

        Why does Intel hide internal RISC core in their processors?

      2. Bebu sa Ware
        Windows

        Re: This is possibly what you were alluding to, but to elaborate...

        x86-compatible "wrapper" around a sort-of-RISC-style non-native-x86 core

        Agnor Fog's optimisation resources https://agner.org/optimize/ especially the x86 microarchitecture document https://www.agner.org/optimize/microarchitecture.pdf makes fascinating reading.

        User microcodeable processors would be interesting to experiment with ... sort of one step up from FPGAs but I imagine the coding to optimise register renaming and pipeline management might be challenging. I could imagine a (just in time?) compiler that produces optimised microcode for an application but I suppose that is pretty much the RISC idea.

        1. that one in the corner Silver badge

          Re: This is possibly what you were alluding to, but to elaborate...

          > User microcodeable processors would be interesting to experiment with ...

          Have a look at the Xerox Alto emulator (another article). You, the end-user, were expected to be loading up programs and/or OSes that each had their own microcode and you can debug microcode in the emulator.

    3. Jou (Mxyzptlk) Silver badge

      Re: Just a reminder ...

      The microcode is only a part for complex stuff. The CPU is still hard wired for most of the part, but the microcode is there to catch many many many exceptions and special cases. Even the 8086 had a microcode for more complex instructions, albeit without the ability to update it....

      Another nice post is this quick-fix of an 8088 bug inside 8086.

  9. Greybearded old scrote
    1. Elongated Muskrat Silver badge

      Re: Obligatory

      You didn't read the actual article, did you?

  10. that one in the corner Silver badge

    On the bright side

    Can we hope for a resurgence in people having a go at writing some microcode to do something useful/interesting/fun?

    You know, hack it.

    How about something that will run Conway's Life *really* fast?

    Or - can you run Doom on it?

    1. Blazde Silver badge

      Re: On the bright side

      I doubt there's much performance benefit to be had, because ultimately whichever way you run the micro-ops you'll tend to run into the same few key bottlenecks that the x86 instruction set is already equipped to run into. But definitely could be a lot of fun.

  11. GNU Enjoyer
    Angel

    It's not a security vulnerability

    That a user with ring-0 access can load software (as that's what they should be able to do).

    I hope the other handcuffs for the init software is flawed too, making it at least potentially possible to use Ryzen CPUs with free software.

    1. Henry Wertz 1 Gold badge

      Re: It's not a security vulnerability

      Microsoft and others have this fantasy that secureboot and tpm type stuff can let them run stuff on your system that yourself, even as superuser, cannot be privy to. Of course claiming it's for your own good but really for media companies to be able to restrict your use of your own computer. (And so people can theoretically use it on ATMs. slot machines, etc. as yet another layer of security.)

      1. GNU Enjoyer
        Angel

        Re: It's not a security vulnerability

        Yes, the whole idea is that you don't own the computer - microsoft and/or other parties do.

        >theoretically use it on ATMs. slot machines, etc. as yet another layer of security.

        The issue is that the more proprietary software and obscured hardware you add, the worse security gets.

        Restricted boot (boot secure + guard boot) has been demonstrated to make security worse by the "LogoFAIL" vulnerability (old BIOS's are easy to exploit, but in many cases you would need to tailor an exploit per motherboard (sure the "megatrends BIOS" was extremely common, but at least not every motherboard used such BIOS), instead of being able to make a single exploit PNG that works on all of them) - which most UEFI implementations are vulnerable to and if you don't want to be vulnerable to that - too bad, better hope that an update is released (how the UEFI is proprietary prevents you from fixing it yourself and guard boot is provides the cryptographic guarantee you can't change the software (yes, very old versions of guard boot were found to be possible to render ineffective due to incompetence, but I don't believe newer versions can be)).

        Most ATMs and slot machines don't actually use stuff like SGX etc, as it has been proven to fail to improve, or even reduce security time and time again.

  12. Henry Wertz 1 Gold badge

    assumed it was locked out

    i assumed it was locked out, so there was one chance at bootup to load microcode patches (or possibly 2, one for the BIOS and one that SHOULD be used for early boot), then part of the microcode load would be to 'flip a switch' so the capability was disabled unti the cpu was power cycled.

    Of course, maybe there is and Google tampered with the 'early boot' update rather than updating microcode a third time later, i didn't look to see the mechanics of their exploit other than it exploiting week MD5 hashes. But the way they talk about ring 0 access this sounds like this capability is left on and they are doing a late microcode update.

  13. nautica Silver badge
    Boffin

    There is absolutely no problem here.

    4 ('four', the fifth of the positive integers) is a random number.

    1. bazza Silver badge
      Trollface

      Re: There is absolutely no problem here.

      Ah, an invitation to debate the meaning of numbers.

      Zero is not an integer, so 4 is the fourth positive integer not the fifth.

      1. rcxb Silver badge

        Re: There is absolutely no problem here.

        Wikipedia says 0 is an integer. C/C++ `int` data types will happily hold zero. Seems non-controversial that 0 is an integer.

        Now for the real question... Is 0 positive?

        1. Jou (Mxyzptlk) Silver badge

          Re: There is absolutely no problem here.

          All deduct from this subthread is you are prone for the classical "off by one" error source. One of the most common errors. Often combined with where to start counting from.

          (Oh, I am prone for that as well :D )

        2. CowHorseFrog Silver badge

          Re: There is absolutely no problem here.

          Our friend bazza must be a fundamentalist who doesnt believe in zero because the bible and god and jesus never gave us a zero.

          1. Grunchy Silver badge

            Re: There is absolutely no problem here.

            “…the bible and god and jesus never gave us a zero.”

            Sure, Jesus walked on the water.

            But astronauts walked in SPACE!

            They even walked on the MOON!!

            Come to think of it… water skiing is blasphemous. Isn’t it!

        3. Bebu sa Ware
          Windows

          Re: There is absolutely no problem here.

          "Wikipedia says 0 is an integer"

          I suspect some confusion between natural numbers ℕ and non negative integers ℤ≥0

          From pure maths course nearly 50 years ago I recall Peano postulates every natural number has a successor and that there exists a natural number that is not the successor of any number. Originally this was "1" but later "0" - but if it's a real concern one can take the lead from thermodynamics which is blessed with a zeroeth law in addition to the first, second and third.

          Von Neumann once stated "Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin."

        4. Elongated Muskrat Silver badge

          Re: There is absolutely no problem here.

          In twos-complement, it doesn't have the sign bit set, so it's not negative, we can eliminate that possibility. That doesn't tell us whether it is positive, though.

          Perhaps we should settle on four being the fifth incremental non-negative integer (we are also assuming sort order, the set of non-negative integers is just that, a set, it has no intrinsic order).

      2. nautica Silver badge
        Meh

        Re: There is absolutely no problem here.

        "...Elementary algebra

        ...The natural number following 0 is 1 and no natural number precedes 0. The number 0 may or may not be considered a natural number...but it is an integer, and hence a rational number and a real number...All rational numbers are algebraic numbers, including 0...."--Wikipedia

        1. bazza Silver badge
          Trollface

          Re: There is absolutely no problem here.

          Ah well, 0 is simply an unnecessary number. All we use it for is to denote things or terms in equations that never existed or no longer exist. It’s not really a number at all, never mind an integer number!

    2. rcxb Silver badge

      Re: There is absolutely no problem here.

      Nobody expects The Spanish Inquisition number 4!

      1. Ken Shabby Bronze badge
        Childcatcher

        Re: There is absolutely no problem here.

        I am not a number I am a free man!

        1. Bebu sa Ware
          Big Brother

          Re: There is absolutely no problem here.

          I am not a number I am a free man!

          Given the world today I think if I were in No.6's predicament I would think being stuck in Portmeirion, with plenty of whisky and around the second episode I think an enthusiastic young woman turned up, so not too shabby.

        2. FirstTangoInParis Silver badge

          Re: There is absolutely no problem here.

          So perhaps the random number should have been 6 then?

    3. Elongated Muskrat Silver badge

      Re: There is absolutely no problem here.

      1) The set of positive integers does not have an order.

      2) Zero is not in the set of positive integers (https://math.stackexchange.com/questions/849259/mathbbz-includes-zero-or-not).

      3) In this implementation, four is also the first, second, third, fourth, etc. positive integer.

  14. Anonymous Coward
    Anonymous Coward

    Quelle Surprise .... not !!!!

    1. Security is HARD !!!

    2. That means for EVERYONE !!!

    3. Any method of securing code/access/updates CAN and will BE broken eventually !!!

    4. The latest FIX will work ONLY for a period of time BUT 3. will kick in at some stage ... again !!!

    5. Security exists ONLY at a 'point in time', it is the duration of that 'point' that is variable !!!

    6. FEELING secure & BEING secure are NOT the same !!!

    7. ALWAYS work on the basis that Govts/People with power/TLA's have probably ALREADY broken the security you depend on !!!

    8. Don't brag about your 'Global Domination plans etc' before they have been completed ... no matter how 'secure' you feel you are !!!

    :)

  15. anothercynic Silver badge

    And Tavis & Co strike again...

    ... That's all. *makes Meryl Streep gesture*

    Bonus to those who recognise the reference.

  16. Grunchy Silver badge

    Sid6581 LFSR

    My trusty old Sid “noise generator” works via “linear feedback shift register,” fully described here:

    https://youtu.be/aASlxcOsYUg

    If you slow the noise generator down slow enough, and capture each sample, you can very quickly predict the sequence: even in BASIC!

    (I always thought the noise was akin to radio noise, but nope, it never was.)

    1. that one in the corner Silver badge

      Re: Sid6581 LFSR

      > My trusty old Sid “noise generator” works via “linear feedback shift register,”

      A LFSR generates randomoid numbers - they look (and sound) random (to our senses) but they really aren't.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like