[HN Gopher] I'm unsure of the security of simultaneous multithre...
___________________________________________________________________
I'm unsure of the security of simultaneous multithreading on modern
x86 CPUs
Author : zdw
Score : 115 points
Date : 2021-11-12 14:43 UTC (8 hours ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| daneel_w wrote:
| If these servers are "general multi-user environments", are you
| sure you're really getting any benefit at all out of SMT? It's
| never a magical 200% performance silver bullet, not even for
| highly specialized workloads.
| zdw wrote:
| Goal of SMT isn't double the performance, it having >1 threads
| better using execution units within a CPU core.
|
| The example frequently given is running an integer heavy and
| floating point heavy code at the same time - they don't use the
| same execution units, so they can better utilize available
| resources.
|
| In the real world it's more likely that one thread is waiting
| on memory access or some other part of the system and the other
| thread can proceed during that wait.
| OldHand2018 wrote:
| The blog entry states:
|
| "(For reasons beyond the scope of this entry, we can assume
| that SMT is worthwhile for us.)"
|
| This is also coming from utoronto.ca - so... I guess the
| question I would have is actually more along the lines of
| whether there are actually adverse effects from exploiting SMT
| to snoop on other processes?
|
| Is this going to be a whole lot of engineering students doing
| finite analysis homework? If so, what do you get out of an SMT
| exploit? There are probably a lot easier ways to cheat on your
| homework.
|
| Are they doing analysis of medical data that hasn't yet been
| anonymized? Perhaps that's a bigger deal. Maybe.
|
| 1. There is no such thing as perfect security
|
| 2. Security is an economic decision. You have to know what you
| stand to lose before you decide if buying 2x the number of
| processors and disabling SMT is worth it.
| phkahler wrote:
| I've found SMT to give 20-25 percent performance improvement on
| parallel workloads using a lot of the same data, so threads
| shouldn't be polluting each others cache. Different users would
| obviously not get the same improvement.
|
| I'm not sure 20-25 percent is even worth having SMT given that
| is' like going from 4 cores to 5.
| daneel_w wrote:
| For highly optimized workloads (e.g. x264 video encoding or
| raytracers) I've seen about the same 20-25% increase at most.
| On general heavy and diverse workloads the number is rarely
| ever above 5%, while the power consumption and the security
| concerns run off all the same. I personally disable SMT on
| everything I can.
| dragontamer wrote:
| > I'm not sure 20-25 percent is even worth having SMT given
| that is' like going from 4 cores to 5.
|
| Can you think of another 25% bonus that costs nothing in
| terms of chip area? SMT doesn't add any new registers (the
| register files and retirement buffers are the same). SMT
| doesn't add cache, or pipelines, or anything.
|
| SMT just requires the chip's resources to be partitioned up
| in some cases, so its a complication to add to a chip but
| doesn't seem to take up much area at all.
|
| Normally to get a 25% bonus, you'd have to double the L2
| cache or something similar (and as the 3x L3 cache tests from
| Microsoft proves for Milan-X, even 300% L3 cache isn't
| anywhere close to 300% faster, despite taking up
| significantly more die area... albeit cheap die area in the
| form of 3d-stacked chiplets but still, a lot more silicon is
| being thrown at the problem there... compared to nearly-zero-
| silicon in the case of SMT)
| abotsis wrote:
| Recent Linux patches allow the scheduler to only schedule
| processes with the same seed on the same core. The "seed" would
| be something tied to the user, or something else... I don't think
| they're merged yet... but that might be a solution.
| phkahler wrote:
| From TFA:
|
| >> We're planning to get some high core count machines to be
| new compute machines in our environment of general multi-user
| Unix login servers
|
| I think the "general multi-user Ubix login" thing assumes
| different users on the same CPU. Unless they're actually going
| to have more CPUs than users. It seems like sharing a CPU is
| actually less secure than sharing one via SMT because of all
| those SMT-specific exploits (in addition to whatever exploits
| might be possible due to CPU sharing).
| toast0 wrote:
| Sharing an SMT is IMHO less secure, because the adversary can
| probe while the victim is running. Sharing a CPU means you
| can only probe the effects.
|
| It would make sense to me for a traditional multiuser shell
| server to have a scheduling policy prohibiting SMT sharing
| between users. As long as the scheduler work is not
| expensive, it would seem almost no-cost vs disabling SMT in
| case all users only run a single thread, but you can still
| get whatever benefits SMT provides within a user's workload.
| vlovich123 wrote:
| Linux added core scheduling recently which is a way to turn on
| HT/SMT in unsafe environments (but requires SW changes to make
| sure you stay safe) https://www.kernel.org/doc/html/latest/admin-
| guide/hw-vuln/c...
| bjoli wrote:
| I disabled SMT in 2007 after reading colin percivals thoughts on
| intels hyperthreading. I have disabled it on every computer I
| have had since, since the fixes didn't inspire much confidence
| back then.
|
| I have done benchmarks from time to time and it doesn't really
| matter much for my workloads.
| gautamcgoel wrote:
| A lot of these discussions focus on servers. What about us Plebs,
| who only run desktop machines? What should we do?
| secondcoming wrote:
| I'd have thought that a desktop machine was more likely to run
| untrusted code than a server.
| hmrr wrote:
| And then god said _" let there be Docker!"_ ...
|
| These days I mostly have no idea what the hell any of my
| equipment is running. There is a whole industry that popped
| up to write tools to work out what the hell you are running
| and work out how screwed you are. Doesn't feel healthy to me.
| staticassertion wrote:
| Unless you're a cloud provider/ a SaaS that provides remote
| code execution, that's likely true.
| kllrnohj wrote:
| Leaving SMT enabled is most likely what you want to do. It's
| more performance, and the attack vector on a desktop machine
| for this is incredibly small. You'd need to run untrusted code
| (not hard, JavaScript is everywhere after all) but that JS code
| would need to have something to attack on a neighboring thread
| (unlikely) and know to attack that neighboring thread (even
| more unlikely) and not get mitigated by any of the browser
| spectre mitigations that have been in place for a while now
| (again, unlikely)
| f00zz wrote:
| I disable Spectre/Meltdown mitigations on all my Linux
| machines, that's how worried I am.
| kevinherron wrote:
| ... and you will do nothing, because you can do nothing.
| enchiridion wrote:
| Well... aren't these attacks only a concern if you have
| adversarial code running on adjacent cores? So for a desktop
| user the threat model really doesn't change. Just do your
| best to keep malicious programs off of your machine. If
| someone can already run a speculative execution attack
| against you're local machine, there are much easier attacks
| to run.
| jnwatson wrote:
| Every web page you visit allows a "malicious program" to be
| run on your machine.
| 4ad wrote:
| > Just do your best to keep malicious programs off of your
| machine.
|
| So don't visit the web then.
| enchiridion wrote:
| Is there any record of web-based attacks like this?
| staticassertion wrote:
| Browser vendors have been pretty quick to add
| mitigations, disable attack surface, etc. Someone comes
| up with a new way to attack systems via JS, but vendors
| are all headed in a safer direction.
| magila wrote:
| Not AFAIK. There are contrived PoCs of browser based
| Specter exploits, but no practical examples have been
| discovered.
| silon42 wrote:
| Disable JS by default.
| acdha wrote:
| How closely have you followed the layers of mitigations
| which the major browser engines have implemented? I think
| a more interesting form of this question is asking how
| often people are exposed to malicious code which isn't
| covered by the browser sandboxes.
| modzu wrote:
| if you arent running vms, you can chill.
| 4ad wrote:
| No you can't, attacks like spectre are exploitable from
| javascript.
| Filligree wrote:
| Has anyone seen an attack in the wild, though? Ever?
| crazysim wrote:
| People were doing POCs before the browser makers nerfed
| the hell out of timing APIs especially from web assembly
| and autoupdate distributed the nerfs out.
| davidw wrote:
| What does 'nerfed' mean in this context?
| cmg wrote:
| Browser manufacturers changed the behavior of APIs like
| performance.now() [0] to add slight rounding 'errors' or
| limit the granularity of timing functions. That function
| used to report on the microsecond level in (most)
| browsers, but now is generally limited to around 1ms due
| to timing attacks.
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/API/Performance...
| a-dub wrote:
| surely high precision clocks can be constructed via busy
| waits or random api calls that hit hardware to do things
| with fixed latency, no?
| staticassertion wrote:
| Yes, like the SharedArrayBuffer that browsers disabled.
| There are probably roughly infinite ways to construct
| clocks. Closing the obvious leaks has been a stop gap
| while other mitigation techniques are rolling out, like
| site isolation.
| silon42 wrote:
| All those can be limited, because thankfully JS is not
| multithreaded (otherwise you could do busy-loop timing).
| mekkkkkk wrote:
| 'Nerf' is a term used for when game developers update a
| game and reduce the effectiveness of something. 'My sword
| attack ability was nerfed in the latest patch'. In this
| context I suppose the API capabilities was reduced in
| browser updates.
| Iv wrote:
| Lower the precision by adding random noise.
| londons_explore wrote:
| If you are trying to prevent attacker code communicating with
| another piece of attacker code on another core: No. It isn't
| secure. There are a lot of side channels.
|
| If you are trying to prevent attacker code figuring out what code
| is running on another core: No. Patterns of L3 cache eviction and
| memory bus contention will probably leak sufficient information
| to have a good guess what another core is up to.
|
| If you are trying to prevent attacker code figuring out _data_ in
| another cores memory or registers: Probably, yes. As long as the
| core is doing something with no data dependent branches, or
| instructions with data dependent timings, it should be safe.
|
| _Very_ little code is written to have no data dependent
| branches, or instructions with data dependent timings. Some well
| written cryptography code has that, but thats about it.
| omegalulw wrote:
| > Very little code is written to have no data dependent
| branches, or instructions with data dependent timings
|
| Ooh I have some idea on how to use data dependent branches in
| your own code to leak critical information through side
| channels (Spectre) but how do you leak information from others'
| data dependent branches and instructions?
| londons_explore wrote:
| Imagine code you want to attack has an array lookup based on
| some secret data: x = array[secretdata].
|
| The entry in the array will be loaded into the cpu core via
| the L3 cache. If the L3 cache is already full, then one entry
| will have to be evicted from the cache. The evicted entry
| will depend on the memory address that is being accessed.
|
| Another CPU, running an attackers code, can repeatedly try to
| load stuff from L3, and detect what was evicted and when to
| learn the secretdata.
| manpagereader wrote:
| OpenBSD defaults to turning SMT off these days because the core
| team is of the same opinion. Theo actually expressed a similar
| opinion over 15 years ago.
| ldng wrote:
| I'm unsure of the security of simultaneous multithreading on
| modern Apple CPUs
| garren wrote:
| Apple cpus specifically, or arm64 in general? The same class of
| bug (i.e., speculative execution) or something else altogether?
|
| I've found myself with more and more arm hardware these days,
| and I'd assumed (probably incorrectly) that it wasn't as prone
| to these kinds of issues.
| eyelidlessness wrote:
| I'm unsure of the existence of simultaneous multithreading on
| Apple CPUs.
| dmitrygr wrote:
| > simultaneous multithreading on modern Apple CPUs reply
|
| Where did you find such a thing?
| reasonabl_human wrote:
| I'm not well versed in architecture intricacies of arm64,
| simultaneous multithreading doesn't exist on those platforms?
| dragontamer wrote:
| Architecture: ARMv8 or ARMv7.
|
| Microarchitecture: Neoverse N2, NeoverseE1, Apple Firestorm
| (all the same ARMv8 architecture, but all different
| microarchitectures)
|
| Of these: Neoverse E1 has SMT. Apple Firestorm does not.
| MiguelHudnandez wrote:
| Can you share some of your research about it?
| sam0x17 wrote:
| I'm unsure of the security of anything on modern Apple
| operating systems or hardware, since I can't review the source
| code or hardware schematics.
| macdice wrote:
| I haven't followed it or tried it, but supposedly you can
| boot up a pure open source Darwin system. Certainly it has
| been very useful for me as a cross-platform developer to be
| able to browse its source and understand quirks of system
| calls etc. Are you saying that key parts you'd like to review
| are closed source? Hmm, the new file system is closed source,
| which is a clue, but I don't know to what extent Darwin is
| "different" from what macOS is really running...
| emteycz wrote:
| Can you send me the Intel/AMD/Qualcomm/Samsung sources and
| schematics?
| mhh__ wrote:
| Intel at very least do publish a pretty hefty optimization
| manual.
|
| We do have a bunch of leaked intel firmware, or so I'm
| told...
| acdha wrote:
| I've been thinking along similar lines, and also wondering what
| percentage of workloads still see significant benefits from SMT.
| It made a lot more sense in 2002 when it was still common to find
| servers with only one core but now even a phone has half a dozen
| cores and laptops are pushing into the tens of cores range while
| servers are pushing an order of magnitude greater.
|
| I remember disabling SMT in the mid-2000s because it was a
| performance degradation for some memory-sensitive code one of my
| users was running. I'd be really curious what percentage of
| workloads are not limited by I/O but still stay below the level
| where resource contention between threads lowers performance.
| gpapilion wrote:
| I would say most workloads benefit from SMT. I've done work
| disabling and enabling it and rerunning benchmarks to
| understand the impact.
|
| As a gross over generalization, disabling it can improve
| latency for workloads that are compute intensive. This is not
| most workloads, and almost everything will see some improvement
| and increase in throughput by having SMT turned on at lower
| utilizations.
|
| As you push the workload beyond 60-70% utilization the wins
| from SMT fall away, but generally are not impacting you
| negatively. What happens is your processor is over performing
| at lower utilizations, and your performance curve bends to
| where it would have been without SMT at lower utilizations.
| wiredfool wrote:
| The only workload I've done lately that buried all the cores
| was a significantly parallel CSV import into clickhouse from
| compressed zips of multiple CSVs, while filtering the CSVs
| with python. Running nproc=cores was 5% slower than
| nproc=cores+smt in overall throughput.
| [deleted]
| dragontamer wrote:
| DDR4 RAM has the same latency as DDR2 RAM. DDR5 will probably
| have the same latency as well.
|
| In 2002, our processors were so thin they could only execute
| maybe 2-instructions per clock tick. Today, we've got CPUs that
| hit 4 (x86 L1 cache), 6 (x86 uop cache), or 8 (Apple M1)
| instructions per tick.
|
| With many problems still memory-latency bound (aka: any Java
| code going through blah->foo()->bar()... look at all those
| pointer indirections!!), it makes sense to "find other work to
| do" while the CPU stalls on memory latency.
|
| The RAM supports higher bandwidth. The CPU supports more
| instructions-per-tick. Spending effort to find work to do just
| makes sense.
| acdha wrote:
| Oh, I'm aware of that concern but I was wondering how many
| benchmarks show a significant win. After you consider the
| impacts on the processor caches, and the fraction of apps
| which are performance sensitive but still end up limited on
| cache-unfriendly random memory access, it seems like it could
| be an increasingly niche concern where most of the code
| people run either isn't performance sensitive or has gotten
| better about memory access patterns after decades of hardware
| trending in that direction.
|
| Apple's highly-competitive performance with processors which
| don't support SMT suggests that this is not such a clear win,
| especially given the non-trivial cost of the security
| mitigations.
| dragontamer wrote:
| https://www.phoronix.com/scan.php?page=article&item=intel-
| ht...
|
| * HT (Intel's SMT, aka Hyperthreading) wins on Blender,
| Parboil, Rodinia, HMMer Search, TTSIOD 3D Renderer, x264
| Encoding, 7-Zip, Stockfish Chess AI, ASMFish Chess AI,
| Linux Kernel Compiles, PHP Compiles, C-Ray, POV-RAY,
| m-queens,
|
| * HT loses on VP9 Encoding
|
| * Virtually a tie on GraphicsMagick,
| acdha wrote:
| Thanks - that's the kind of spread I was curious about
| since there are some other factors like the cost of
| Spectre mitigations which have added addition dimensions
| to comparisons.
| polskibus wrote:
| CAS Latency has been increasing with each DDR version.
| throwaway2048 wrote:
| CAS latency is counted in cycles, ram speed has increased,
| the cycle count has increased, the absolute amount of time
| passing has not.
| formerly_proven wrote:
| It has decreased, but let's say halving a timing within
| 20-25 years is not exactly the kind of progress people
| intuitively associate with semiconductors.
|
| What has decreased quite a lot though is the time to
| transfer, which is of course stacked on top of CL. CPUs
| always have to fetch a full cache line (usually 64
| bytes), and the time to get 64 bytes out of memory has
| more than halved each generation.
| MauranKilom wrote:
| ...unless you are bandwidth-bound already. In such cases I've
| observed 10-30% gains from turning _off_ SMT...
| CyberDildonics wrote:
| It is very rare for programs to be memory bandwidth bound.
| It usually take a lot of optimization just to get to that
| point as well as some disregard for memory bandwidth on top
| of that (such as looping through large arrays, only doing
| one simple calculation to each index, then doing that on
| many cores).
|
| The vast majority of what people run is memory latency
| bound and in those cases using extra threads makes sense so
| that the explicit parallelism can compensate for memory
| latency.
| stefan_ wrote:
| This is a red herring. Where are all the people that are unsure
| of the security of virtualization? There is some Xen
| vulnerability every year that is the equivalent of the house
| burning down, but where is the Azure support article that
| suggests disabling Xen? (Oh right, you can't.)
|
| I mean, the article is totally right of course, you shouldn't run
| untrusted code - THAT INCLUDES THE FREAKING HYPERVISOR.
| api wrote:
| There's definitely a bias in security toward "sexy"
| vulnerabilities that are novel and creative but hard to exploit
| in practice vs boring "forgot to bounds check" or "off by one
| logic error" type vulnerabilities that are pervasive.
|
| SMT (a.k.a. hyperthreading) is kind of a security minefield,
| but so is out of order execution and crufty instruction sets
| like x86_64. But vulnerabilities of this sort tend to be hard
| to exploit in the wild. Not saying you shouldn't be concerned
| about them, but _how_ concerned you are should depend on your
| threat model. If I were _really_ paranoid and could pick I 'd
| choose something like a low-power simple ARM or RISC-V core to
| do critical computation. Alternatively you could run your
| secure compute on any system as long as _nobody is allowed to
| run any other code_ on that system or have physical access to
| it.
|
| BTW I am deeply surprised that there has never been a cloud
| hypervisor doomsday vulnerability that has brought down AWS or
| some other huge provider. Back when virtualization in the cloud
| got big I would have bet serious money that this would have
| happened by now.
| staticassertion wrote:
| > BTW I am deeply surprised that there has never been a cloud
| hypervisor doomsday vulnerability that has brought down AWS
| or some other huge provider.
|
| There have been multiple cases of significant vulnerabilities
| where cloud providers had to perform patching and restart
| their services. No one, to my knowledge, has exploited those
| maliciously, but the vulns have had impact.
| CalChris wrote:
| > If I were really paranoid and could pick I'd choose
| something like a low-power simple ARM or RISC-V core to do
| critical computation.
|
| Isn't that what Apple does with its Secure Enclave processor?
| kongolongo wrote:
| >BTW I am deeply surprised that there has never been a cloud
| hypervisor doomsday vulnerability that has brought down AWS
| or some other huge provider. Back when virtualization in the
| cloud got big I would have bet serious money that this would
| have happened by now.
|
| I think at this point anyone that's capable of launching such
| an attack would much rather it be as transparent as possible
| as they'd have far, far more to gain from not disrupting
| services. Aside from ransomware attacks, I think the general
| trend has always been towards those type of attacks as
| they're way more likely to be profitable
| melolife wrote:
| To quote James Mickens, "large swathes of the security
| community are fixated on avant-garde horrors such as the fact
| that, during solar eclipses, pacemakers can be remotely
| controlled with a garage door opener and a Pringles can."
| sonicanatidae wrote:
| Yeah, making a note of this quote. Thanks!
| mwint wrote:
| Is this real? Can I read research somewhere about this?
|
| Edit: Here's the apparent source of the quote: https://scho
| lar.harvard.edu/files/mickens/files/thisworldofo...
| fpgaminer wrote:
| > BTW I am deeply surprised that there has never been a cloud
| hypervisor doomsday vulnerability that has brought down AWS
| or some other huge provider. Back when virtualization in the
| cloud got big I would have bet serious money that this would
| have happened by now.
|
| Meh, the vast majority of rational hackers will just sell a
| zero day capable of doing that either to the vendor
| themselves or to a nation state for several million dollars.
| I suppose they could bring down AWS for "fun", or try to
| short Amazon's stock and make a personal profit, but the
| consequences of getting caught are devastating. Selling the
| vuln is practically risk free and nets life changing money.
| AnthonyMouse wrote:
| > SMT (a.k.a. hyperthreading) is kind of a security
| minefield, but so is out of order execution and crufty
| instruction sets like x86_64. But vulnerabilities of this
| sort tend to be hard to exploit in the wild.
|
| I'm not sure this is even true, so much as that it's just
| easier to do it some other way.
|
| You could use speculative execution by measuring timing to
| extract secrets to get privilege escalation, but then you
| have to sit there with the CPU at 100% for ten minutes while
| doing timing statistics. Whereas you pull the latest 0-day
| off a list somewhere, and the target is going to install the
| patch tomorrow but hasn't yet, and that pops the system in
| less than a second. So people do that instead.
|
| > BTW I am deeply surprised that there has never been a cloud
| hypervisor doomsday vulnerability that has brought down AWS
| or some other huge provider. Back when virtualization in the
| cloud got big I would have bet serious money that this would
| have happened by now.
|
| The assumption there is that the goal of somebody who got in
| would be an externally visible denial of service, as opposed
| to e.g. data exfiltration which might never be detected.
| notyourday wrote:
| > You could use speculative execution by measuring timing
| to extract secrets to get privilege escalation, but then
| you have to sit there with the CPU at 100% for ten minutes
| while doing timing statistics.
|
| Code wins arguments:
|
| 1. provide the exploit code that does it i.e. I go to a
| website and it reads a content that I have in a different
| browser tab.
|
| 2. provide the exploit code that while running on one VM on
| a host that does not have mitigations enabled reads a value
| of a file in a different VM.
| notyourday wrote:
| As expected from the "security" experts -- it is all
| chicken little "Sky is falling" talk and zero
| demonstrations.
|
| This is why pretty much no one takes it seriously : it
| used to be that the fancy exploits came with a demo:
|
| $ ./some-exploit-code
|
| #
|
| some-exploit-code won the argument. No one could argue
| that it did not matter as anyone who managed to get code
| executed on a target server got #. These days we just get
| lots of "OMG! We are all going to get pwned!" handwaving
| and zero demonstration that can be done in front of
| execs.
| [deleted]
| formerly_proven wrote:
| https://marc.info/?l=openbsd-misc&m=119318909016582
| beebmam wrote:
| Does Azure even use Xen? I was under the assumption they used
| Hyper-V for virtualization of hosts
| hansel_der wrote:
| idk but would not be surprised if every popular hypervisor
| out there is a descendant of xen
| acdha wrote:
| > (Oh right, you can't.)
|
| I think you inadvertently hit on why this is a good discussion
| to have: security is a concern across the entire stack and
| attackers have many points where they can successfully
| compromise your system. It's much harder to replace Xen than it
| is to disable SMT, so it's much more feasible for someone to
| consider the latter since it's a single configuration point
| with very little chance of side-effects other than cost whereas
| touching Xen would have massive ripple effects for ops &
| potentially compatibility.
| maerF0x0 wrote:
| > so it's much more feasible for someone to consider the
| latter
|
| And conversely it's much more beneficial for an attacker to
| consider the former (attacking the hypervisor), this
| exacerbates the situation by making red team more aggressive
| to one side whilst blue team is busy debating if they should
| disable SMT .
| acdha wrote:
| I mean, that's always possible but it was always the case
| that the blue team needs to worry about the entire stack
| and one of those two choices has several orders of
| magnitude more work involved. The blue team could disable
| SMT and switch back to debating Xen with almost no
| discernible impact on the time needed for the latter and an
| entire branch of the threat tree removed.
| Spooky23 wrote:
| Hyper-threading guidance has been to disable for a long time in
| security sensitive environments.
|
| Spectre/etc reinforced that.
| [deleted]
| upofadown wrote:
| This would be an issue where no virtualisation was done at all.
| In perhaps some sort of critical situation where the rsk of
| virtualisation was unacceptable. So the subject of
| virtualisation is, well, a red herring.
| tryauuum wrote:
| I'm a simple guy, I trust the kernel and its devs. If kernel says
| to me via /sys/ that on this CPU I have to disable SMT if I want
| to get rid of "Vulnerable" messages, I do so.
|
| Kernel considers recent Intel CPUs not vulnerable even with SMT,
| it's good enough for me
| tenebrisalietum wrote:
| if /sys/kernel/jump_off_a_cliff was 1 would you go ahead and do
| it?
| ByThyGrace wrote:
| What if sys/kernel/jump_off_a_cliff returns .9999?
| jasonhansel wrote:
| Actually, that's a common misconception. When
| "jump_off_a_cliff_ratio" is set to a value other than "-1",
| then "jump_off_a_cliff" is ignored. The ratio is divided by
| 20000, so if you set it to 10000 your system will only jump
| off a cliff if 50% of friends do so.
|
| The default setting is "15000", but some distros change it
| (e.g. Arch sets it to "0" so that your system always jumps
| first--more performant, but less safe).
|
| Conveniently, none of this is documented anywhere, all the
| other information you can find online is years out of date,
| and most sysadmins just accept the risk of cliff-jumping
| rather than trying to tune it manually.
| yjftsjthsd-h wrote:
| If the kernel developers had collectively decided that it was
| safer to jump off the cliff then stay, then yes, absolutely.
|
| https://xkcd.com/1170/
___________________________________________________________________
(page generated 2021-11-12 23:00 UTC)