4320 of 7435

Security Post #4722, on Aug 2, 2022 in TG

Defense In Depth, Geopolitics Edition

Why is this Security meme funny?

Level 1: Too Many Locks

This is like putting four locks on your front door because you think each lock company might secretly work for a different sneaky neighbor. It feels safer because there are more locks, but the real joke is that you still have to trust somebody, and nobody in the picture seems fully trustworthy.

Level 2: Backdoors All Around

A firewall is a device or service that controls network traffic. It decides which connections are allowed through based on rules like source address, destination port, protocol, application identity, or threat signatures. In simple terms, it is a gate with a rulebook.

A backdoor is a hidden or unintended way to bypass normal security. It might be deliberately inserted, accidentally created, or added by an attacker after compromise. In the meme, each firewall claims to protect against some other country's backdoors, which is why the joke lands: the protection chain assumes every vendor might be untrustworthy, but also assumes the next vendor can be trusted enough to protect you.

Defense in depth means using multiple layers of protection so one failure does not ruin everything. For example:

A firewall blocks unwanted inbound traffic.
Strong authentication protects administrator access.
Patch management removes known vulnerabilities.
Monitoring detects strange behavior.
Network segmentation limits what an attacker can reach.

The meme twists that good idea into security theater. Instead of showing layered controls that solve different problems, it shows four similar-looking brick walls whose real job is emotional reassurance. A junior engineer might first encounter this at a company where the network diagram looks impressively secure, then discover that the firewall rules are full of any any allow exceptions because "the business needed it."

The "trusted LAN" bubble is also a classic old-school assumption. A LAN, or local area network, is the internal network inside an office or organization. Calling it trusted made more sense when most systems lived in one building and attackers were presumed to be outside. Modern security is more skeptical: internal networks can be compromised too, so many teams prefer zero trust ideas where every request still needs verification.

Level 3: Trust Firewall Theater

The diagram is funny because it turns defense in depth into a procurement-driven geopolitical joke. Traffic starts in a cloud labeled:

The Bad-Internet

Then it walks through four brick walls: Huawei FW, Juniper FW, Cisco FW, and Checkpoint FW, each supposedly protecting against a different country's backdoors, before reaching:

Our trusted LAN

In real security architecture, stacking firewalls can make sense when the layers have different policies, failure modes, inspection engines, administrative boundaries, or blast-radius controls. Here, the layers are not separated by protocol role or trust zone. They are separated by suspicion. Each vendor is treated less like a security control and more like an antidote to the previous vendor's alleged national allegiance.

That is the senior-engineer pain point: threat modeling often begins as a sober exercise in adversaries, assets, and attack paths, then gets dragged into vendor politics, compliance theater, and executive folklore. The labels "Protection against US backdoors," "Protection against Chinese backdoors," "Protection against Israeli backdoors," and "Protection against Russian backdoors" satirize the idea that supply-chain risk can be neutralized by buying enough mutually distrusted boxes. Somewhere, an enterprise architect has probably made a diagram only slightly less absurd and called it a reference architecture.

The uncomfortable truth behind the joke is that network appliances are themselves high-value attack surfaces. A firewall sits at a privileged choke point, parses hostile traffic, terminates sessions, may inspect encrypted flows, and often has management access into the very network it protects. If that device is compromised through firmware, update channels, management credentials, or hidden functionality, it can become the most expensive way to invite an attacker inside.

The dotted arrow also matters: it suggests a single clean path from danger to safety. Real networks are messier. There are VPNs, cloud peering links, SaaS integrations, remote admin consoles, forgotten test tunnels, vendor support accounts, and that one "temporary" allow rule from 2017 that became sacred infrastructure. The meme's perfect diagonal line is what diagrams show before reality files a support ticket.

Description

A simple network diagram shows traffic flowing by a dotted arrow from a blue cloud labeled "The Bad Internet" through four brick firewall icons into a blue bubble labeled "Our trusted LAN." The firewalls are labeled "Huawei FW" with "Protection against US backdoors," "Juniper FW" with "Protection against Chinese backdoors," "Cisco FW" with "Protection against Israeli backdoors," and "Checkpoint FW" with "Protection against Russian backdoors." A small t.me/dev_meme watermark appears near the lower-left corner. The joke is a cynical defense-in-depth model where each security appliance is trusted mainly to defend against the geopolitical backdoors suspected in the previous vendor.

Common Tags

Firewall FirewallRules DefenseInDepth ThreatModeling CyberEspionage SecurityTheater NetworkSecurityProtocols NetworkInfrastructureDesign InformationSecurity CorporateSecurity TrustIssuesInTech SoftwareSupplyChainSecurity

Comments

139

Anonymous ★ Top Pick The threat model is solid until procurement asks which nation-state backdoor comes with the best enterprise discount.

Anonymous ★ Top Pick

The threat model is solid until procurement asks which nation-state backdoor comes with the best enterprise discount.
@SamsonovAnton 3y

And all of those firewall appliances built upon US / UK designed processors. 👌
1. dev_meme 3y
  
  so network traffic will travel through CPU?
  
  @SamsonovAnton 3y
  
  Unlike switches with ASICs, firewalls process traffic by software in a general-purpose CPU, with some offloading / acceleration possibility.
  
  dev_meme 3y
  
  Well how? Will network traffic ever go below the kernel? CPU processes 0s and 1s, and doesn't do anything else. How will a CPU accelerate the network or provide firewall capabilities? If you're talking an HSM kinda thing or some chip with a compiler burned as firmware, it's different.
  
  no name 3y
  
  see uefi rootkit
  
  dev_meme 3y
  
  see what? A rootkit injects some modules to the host, and again it works at the kernel level, not CPU level. A CPU is there to process 0s and 1s. A CPU is a large number of transistors to process 0 or 1 i.e. current flowing or not.
  
  no name 3y
  
  i mean it is possible to inject something sneaky by patching higher levels
  
  dev_meme 3y
  
  It's totally possible and I have both created rootkits and mitigated them from systems, but it has nothing to do with the CPU doing that stuff.
  
  @SamsonovAnton 3y
  
  Modern and complex CPUs like x86 and ARM are "computers in itselfs" that can do much more than simply running the supplied code — they may act as remote controllers. (Some of those functions may lie in an external chip, but still tightly coupled to the central processing unit.)
  
  dev_meme 3y
  
  Well the point is not what an x86 or ARM based CPU can or cannot do. The point is how can they filter network traffic, without the use of kernel? Even meltdown and spectre can't do it without a process(part of a kernel) involved.
  
  @SamsonovAnton 3y
  
  No, you got it all wrong. CPUs won't process the traffic as intended instead of firewall software — but they may react to the very same traffic in their very own way, thus creating a backdoor.
  
  dev_meme 3y
  
  Nope a CPU won't do that unless you have some external chip involved to feed that data to it and take back the results or some chip which has some compiler burnt as firmware.
  
  dev_meme 3y
  
  A CPU, in very pure terms is like a function, which you feed data to and receive the results. Now, if you wanna call an SoC a CPU, it's totally absurd.
  
  @SamsonovAnton 3y
  
  Let's go step by step: Regular software may access the NIC ports. CPU / SB firmware may access the NIC ports — at least integrated ones, but also any other Intel-based controllers on PCI bus. What prevents the CPU / SB firmware to react to ingress network traffic or even inject self-crafted packets (frames) into the egress queue?
  
  dev_meme 3y
  
  No software can do anything without it being on a persistent storage(disk, NAS, firmware) and then memory to finally feed off the CPU.
  
  @SamsonovAnton 3y
  
  This "software" is called firmware and resides in a persistent memory inside the CPU, but also is loaded by BIOS and/or OS from an totally opaque file supplied by the CPU vendor.
  
  dev_meme 3y
  
  I already wrote firmware in parentheses
  
  @oficsu 3y
  
  Functions sometimes have a shared mutable state, bugs and vulnerabilities A hacked cpu might disable the firewall (because it has enough cache memory to detect patterns of known software or its parts, including an OS, and it can freely access and inspect all memory regions) and forward malformed packets to the other firewalls At the end of this chain, all firewalls will be compromised
  
  dev_meme 3y
  
  Again, you didn't get the point and started to send random things. I didn't say a function can't be buggy. We write smart contracts carefully for precisely this reason. The point is a CPU alone cannot do it. Cache is empty when it's not being fed off by the RAM. RAM is empty when it's not being fed off by a persistent storage(disk, NAS, firmware). So cache can't store any pattern which later it can use as an exploit. No malware can do anything unless it has a process to work with. Even meltdown and spectre can't. So that's the point. There is nothing like a hacked CPU! There are exploits, rootkits, backdoors, etc. all of which work at OS, kernel and process(in general) level(at best, they can affect the fw). You can't program a CPU via a software to make it malicious for an OS.
  
  @oficsu 3y
  
  Are we talking about impossibility or how hard it is? Your arguments are right in the second case, but not in the first tl;dr: you should prove that a cpu itself isn't already a SoC, and you can't because you can't trust the vendor in the context of backdoors >> you can't program a CPU via a software to make it malicious for an OS As a user, you can't. As the vendor, you can. The talk is about backdoors, about the second >> RAM is empty when it's not being fed No, it's not. In the context of this talk, we have at least firewall code and a network packet in the RAM and the cpu cache, so they aren't empty And you can't prove, the cpu doesn't already have a built-in malicious payload At some point, a network packet ends up in the cpu cache. And you can't prove there is no any algorithm inside that can disable firewall based on both a packet and software patterns If you're going to prove it's impossible at all (impossible, not too hard), you need to follow the formal logic and prove both: * a cpu doesn't know the patterns of executing software (os or firewall) * software doesn't allow a network packet to go through cpu cache in an unchanged or a known state (e.g. other hardware can compress or encrypt packets) And to prove both of this in general, you need to prove these for each potential combination of cpu, os and firewall. To prove this in the context of a particular combination, you need to reverse that cpu (and it's nearly impossible too) >> Even meltdown and spectre Because it's another type of vulnerability
  
  dev_meme 3y
  
  you should prove that a cpu itself isn't already a SoC, and you can't because you can't trust the vendor in the context of backdoors A CPU(processor, the term used by a person, due to which the discussion originally started) is a combination of transistors put together and then fabricated. Modern ways of creating processors have tried to incorrectly stretch this definition to include NB(as AMD merged it some years ago and the rest followed suit), SB, other peripheral connects, unified memory and so on. But, the original definition of a CPU hasn't changed, it is a group of transistors put together in a certain way as to complete calculations on 0s and 1s and return the results. A CPU takes this data from a combination of registers, caches, memory and finally persistent storage and reverts back the processed data in the form of 0s and 1s in the same order as it received the unprocessed data. This is in part, analogous to the ROM misconception that many, including but not limited to, the mobile vendors have spread to stretch it to PROM, EPROM, EEPROM and so on to the point where a mobile disk is incorrectly referred to as ROM. This does not however, change the initial and pure definition of a ROM. In a similar way, it doesn't change the pure and original definition of a CPU which is plugged inside the motherboard. A CPU DOES NOT include SB or other parts of an SoC, that would be called a system, not a processor, at least until you are sticking to the currently accepted standards. All those exploits, backdoors and so on form a part of some persistent storage, without which the CPU can't be exploited or create a malicious version of itself. It can just receive malicious code and act on it, giving the results as a consequence. Now this result is the thing that can harm a system, and by system, I mean OS, kernel, disk etc. No exploit can change a CPU to behave in a different way than it was designed to at the 0s and 1s level. As the vendor, you can. The talk is about backdoors, about the second Again, I'm not talking about some persistent chips(fw or something else) which is included with the CPU but the processor only. No, it's not. In the context of this talk, we have at least firewall code and a network packet in the RAM and the cpu cache, so they aren't empty The point here is, a CPU cannot by purely itself have some malicious code that works at the 0s and 1s level. That code must have been provided to it in the form of a high-level or at the very least binary language, it cannot create malicious binary code on its own. And that malicious code would have to have been provided at the level of the persistent storage, not at the level of RAM, because you can't load ELF binaries directly to the RAM, they have to go through a lot of stages, like ELF linking. Even if you go through that stage(which almost no one would), maybe you feed it through /dev/stdout or things like UPX, you can't at any cost modify the registers or caches, which are actually a part of the CPU, to serve exploits on reboots and power offs, i.e. you can't modify them to behave differently than they were intended to, using an exploit. They will reset after a reboot. You maybe able to(and believe me it's not trivial) read the cache contents, if you sniff on the content addressable cache's system bus, but again, at that point, you aren't injecting any malicious code pragmatically, even from a persistent source. So, the point of a processor doing it on its own is totally absurd. And you can't prove, the cpu doesn't already have a built-in malicious payload I totally proved it for a pure processor, not a whole system, only who's name is a processor. At some point, a network packet ends up in the cpu cache. And you can't prove there is no any algorithm inside that can disable firewall based on both a packet and software patterns It will have to be originated by a persistent storage, and again it can't modify CPU cache to remain there always, a cache is empty on each reboot.
  
  dev_meme 3y
  
  And to prove both of this in general, you need to prove these for each potential combination of cpu, os and firewall. To prove this in the context of a particular combination, you need to reverse that cpu (and it's nearly impossible too) This thing is trivial so, I would assume it's not needed to prove it, however, it surely can be proved with formal logic: it is impossible to prove the reverse of it, i.e. a software modified the contents of a CPU, and after that the CPU started to serve exploits and malicious code on its own. Because it's another type of vulnerability The point here was, even these CPU attacks needed a process(on a persistent storage) to cause an exploit on a CPU.
  
  @oficsu 3y
  
  >> Again, I'm not talking about some persistent chips(fw or something else) which is included with the CPU but the processor only. And... why? Because we're talking about this cpu. Just a little black box sold by intel/amd (for example). It can contain any software or hardware malicious payload inside the box. Can't it?
  
  @RiedleroD 3y
  
  it can't because intel and amd have to abide by the law /s
  
  Deleted Account 3y
  
  What about Intell Me ? Poor documented feature ? ))
  
  dev_meme 3y
  
  It may or may contain any chip inside of it. However, I'm not talking about only these but a CPU in general. A processor which has the components which are accepted as the standard now. Now, if a company implements a hidden chip or not, if a software company tracks your activity or not, sells your cookies or not is totally indeterministic and not the norm. You can make assumptions based on the standard, not imagining an exception that may be out there somewhere.
  
  @oficsu 3y
  
  Software practice shows us that the standard is to track users. Do you think that hardware design was built upon other standards? Why? InfoSec isn't about baseless trust. It's about strong guarantees. And we don't have such guarantees
  
  dev_meme 3y
  
  The point of tracking isn't a standard, but appears to be as cookie selling is a thing, but wasn't designed keeping that in mind. It's not even the point, this thing was said in support of the hidden chip fact. You're going on a totally distracted path.
  
  @SamsonovAnton 3y
  
  The meme was about backdoors. Those can be of any kind. Imagine a "Wake-on-LAN" kind of specially crafted packet, that acts as "Ping of Death", or makes the packet payload to executed in privileged mode, totally transparent to the main OS and its "Trusted Platform" means.
  
  @L2CacheGay 3y
  
  And where do you suggest that payload would even run?
  
  @L2CacheGay 3y
  
  From the perspective of the hardware reacting to such a package you wouldn’t have much control over the CPU package itself or what goes on inside it
  
  @SamsonovAnton 3y
  
  Do you know what a System Management Mode of x86 CPUs is? It's there since 386. And now we also have Intel Management Engine running in even higher privileged mode. https://en.wikipedia.org/wiki/System_Management_Mode https://en.wikipedia.org/wiki/Intel_Management_Engine
  
  @L2CacheGay 3y
  
  Of course
  
  @feedable 3y
  
  what is below kernel, anyway
  
  @feedable 3y
  
  can it go into userspace? yes it can, and it routinely does. can it go through ime? yes, it can too.
  
  dev_meme 3y
  
  Userspace is above the kernel in that regard.
  
  @feedable 3y
  
  what exactly is below, then
  
  dev_meme 3y
  
  Firmware, Bootloader, SB etc.
  
  @feedable 3y
  
  bootloader will not continue to operate after the kernel is loaded. from the perspective of a booted system it's as if there were no bootloader in the first place
  
  dev_meme 3y
  
  Yes that's exactly what I'm saying as well
  
  @feedable 3y
  
  kernel does not need kernel to operate
  
  dev_meme 3y
  
  Kernel is very complex software, it has parts that need each other to complement them
  
  dev_meme 3y
  
  It's below the kernel
  
  @feedable 3y
  
  it won't execute after the kernel is loaded
  
  @feedable 3y
  
  it does not matter wether it is above or below
  
  dev_meme 3y
  
  Are you high
  
  @feedable 3y
  
  what
  
  dev_meme 3y
  
  Whether what is above or below?
  
  @feedable 3y
  
  not whenever, wether
  
  @feedable 3y
  
  look up that word
  
  dev_meme 3y
  
  ?
  
  @feedable 3y
  
  the bootloader
  
  @feedable 3y
  
  oh come on
  
  dev_meme 3y
  
  Yeah I know that
  
  dev_meme 3y
  
  It loads at boot time after POST
  
  @el_khatto 3y
  
  hardware
  
  dev_meme 3y
  
  Depends how you're talking. In general, firmware has data that doesn't need a kernel.
@SamsonovAnton 3y

Excavator FW.
dev_meme 3y

Wake on LAN works only when the system is in hibernate state and not when it's powered off, again the kernel is on at that time and the network traffic is going through the path of OS -> Kernel -> CPU. Is CPU doing any processing on the network traffic's 0s and 1s without the kernel being involved?
1. @SamsonovAnton 3y
  
  The CPU (or southbridge, if any) may process network packets in parallel to the main OS, at least on integrated LAN ports.
2. dev_meme 3y
  
  Have to disagree on "when the system is in hibernate state and not when it's powered off” Intel’s (at least) support WoL when machine is powered off (not with swtich ofc), thanks to same approach how , for example, old phones been able to work even when not connected to the socket (PoE)
  
  dev_meme 3y
  
  You can't do it from S5 stage, is what I meant
  
  dev_meme 3y
  
  https://www.intel.com/content/www/us/en/support/articles/000038313/ethernet-products.html
  
  dev_meme 3y
  
  can you do it from a totally powered off state?
  
  dev_meme 3y
  
  Like no power cord being inserted? On a desktop PC? Surely not
  
  dev_meme 3y
  
  [In reply to dev_meme] nope, totally powered off with all power cables inserted?
  
  dev_meme 3y
  
  Yeah!
  
  dev_meme 3y
  
  have you ever tried it or saying it from online blogs?
  
  dev_meme 3y
  
  Well, let’s separate online blog and official Intel documnetation/website
  
  dev_meme 3y
  
  Well, if you find any recent one for Linux systems, send me over, it would be great help for me saving power.
  
  dev_meme 3y
  
  Could you clarify model of your network board/CPU/motherboard? 😄 And have you tried etherwake (with all required patches) And which distro you use, too
  
  dev_meme 3y
  
  Ubuntu and Centos only Z-490, Z-690 and X-570 Yes, ethewake didn't work in case it was totally off
  
  dev_meme 3y
  
  And at the same times it does function already while below S5, right?
  
  dev_meme 3y
  
  Yes it does, that's correct
  
  dev_meme 3y
  
  https://www.reddit.com/r/gigabyte/comments/gnujnz/x570_aorus_master_wakeonlan_usb_power_after/
  
  dev_meme 3y
  
  Anyway, just try to go through this discussion Definetly carefull research for each set of equipment is required
  
  dev_meme 3y
  
  Anyway if you find, send over, thank you for all your help.
  
  dev_meme 3y
  
  I sure will look into everything again, tried it all 2-3 years ago and there wasn't any such thing for Linux back then on my systems.
  
  dev_meme 3y
  
  Is this for Linux systems? And my mobo is X570 E-Gaming from Asus
  
  dev_meme 3y
  
  Once again for Windows https://rog.asus.com/forum/showthread.php?101283-Wake-on-LAN-not-working-from-shutdown-Asus-Deluxe-Z170
  
  dev_meme 3y
  
  This is same thing over-over
  
  dev_meme 3y
  
  Just confirms that it MAY and somehow SHOULD work
  
  dev_meme 3y
  
  True
  
  dev_meme 3y
  
  And question of how to make it work in reality is a quest, not a question 😄
  
  dev_meme 3y
  
  I've suffered so I could say
  
  dev_meme 3y
  
  and POE is totally different to WOL, for WOL, you need some power, however low it maybe, you can't turn it on from powered off state, to be precise.
  
  dev_meme 3y
  
  If you do, you're correct in this regard.
3. dev_meme 3y
  
  And I made this comment based totally on my experience
  
  dev_meme 3y
  
  I remember that it should work because many years ago, when this feature and some early version of VT-d been delivered with CPUs I read one in depth research article where one security researcher found that Intel firmware in his case was replaced with some weird one, instead of one provided on Intel’s website, while even checksums been same
  
  dev_meme 3y
  
  For those who got interested, sorry, I will not be able to find it. And it was written in Russian, somewhere between 2009 and 2012 But md5 at those days still been heavily used (unfortunatelly) and possibility to create collisions for not same data wasn’t… Well-known
  
  dev_meme 3y
  
  And #education repo about collision, for our fellow readers 😄 https://github.com/corkami/collisions#fastcoll-md5
  
  dev_meme 3y
  
  I've been using Linux since 2005 and haven't been known of such a thing
  
  dev_meme 3y
  
  What do you mean Linux/Windows?
  
  dev_meme 3y
  
  Well it must have been for Windows
dev_meme 3y

South bridge is not a part of the CPU
1. @SamsonovAnton 3y
  
  It does not matter, as long as CPU/NB and SB (chip set, that us) form a solid hardware platform, tightly integrated with each other and controlled by an opaque, encrypted and signed firmware.
  
  dev_meme 3y
  
  My dear, a solid tightly coupled platform isn't called a processor, it's an SoC or a system.
dev_meme 3y

It's a part of the mobo
dev_meme 3y

Unlike the north bridge which was merged into the CPU some years ago by AMD and all else followed
dev_meme 3y

Stolen
dev_meme 3y

First of all SB is not a part of the CPU
1. @SamsonovAnton 3y
  
  What's the deal with how many chips a processor is split into? It's just a matter of "IP blocks", lithography and packaging.
  
  dev_meme 3y
  
  A CPU(processor is not that), offcourse a CPU with one or more chips can do anything you burn inside the firmware or feed it via a persistent storage via the memory.
dev_meme 3y

Let's get that off
dev_meme 3y

Thanks
@varn0 3y

Best meme discussion so far, thanks folks 😂
dev_meme 3y

CPUs: 10900K, 12900K, 5950X
dev_meme 3y

I mean WOL
1. dev_meme 3y
  
  Gotcha, yeah 🙁
dev_meme 3y

Thanks for your help
1. dev_meme 3y
  
  Sorry for not finding anything really useful In corporate world for this purpose people buy sample hardware and test it to satisfy special requirements, like working WoL in specific PS
  
  dev_meme 3y
  
  And in case of NIX OSs Intel probably cares only about those big customers, for whom they may have all data and compatibility tables with links to drivers
  
  dev_meme 3y
  
  Hey not a problem buddy, you're not here from Intel, are you?
  
  dev_meme 3y
  
  Nope 😄 I’m @linegel
dev_meme 3y

Yeah, we similar one some time ago too 🙂
dev_meme 3y

Kernel is Ring 0. Then you have, Drivers: Ring 1, Hypervisors: Ring 2, Browsers: Ring 3
1. @feedable 3y
  
  hypervisors are below kernels, aren't they?
  
  dev_meme 3y
  
  Nope
dev_meme 3y

Things that don't need kernel to operate
dev_meme 3y

Tell me which one?
dev_meme 3y

Not even baremetals
dev_meme 3y

Yes we weren't talking about bootloader here, it came into discussion as you asked what is loaded before a kernel is loaded
dev_meme 3y

Because bootloaders can inject boot sector viruses, we were talking purely a CPU
1. @feedable 3y
  
  what are you trying to prove anyway
dev_meme 3y

Nothing, I was trying to tell that a CPU alone can't be malicious
dev_meme 3y

It's like a pure function that takes input processes it and returns it.
1. @feedable 3y
  
  take ime for example
  
  @feedable 3y
  
  is it a part of a cpu?
  
  @feedable 3y
  
  can it be malicious?
  
  dev_meme 3y
  
  What's an IME
  
  @feedable 3y
  
  https://en.wikipedia.org/wiki/Intel_Management_Engine
dev_meme 3y

It doesn't have a persistent storage by itself, so it the software(firewall, exploit) isn't being fed off by the persistent storage, it won't do anything
1. @feedable 3y
  
  yes, but without that exact storage it won't be able to do anything, harmful or not
  
  dev_meme 3y
  
  Well that's exactly what I said
dev_meme 3y

It's a part of the mobo(like SB), not a CPU
1. @feedable 3y
  
  it exists on the crystal
  
  @feedable 3y
  
  i mean, if you are arbitrarily going to chop off parts of the cpu until it fits your criteria this discussion would not make any sense
  
  dev_meme 3y
  
  neither will it make sense if you try to include the parts of a motherboard into a CPU(processor)

Use J and K for navigation

Defense In Depth, Geopolitics Edition

Why is this Security meme funny?

Level 1: Too Many Locks

Level 2: Backdoors All Around

Level 3: Trust Firewall Theater

Description

Categories

Common Tags

Comments

Related Memes

Deterministic Randomness Exposed

The Impossible Jailbreak Guarantee

AI Founder Rediscovers People