[HN Gopher] Spectre mitigations murder userspace performance
___________________________________________________________________
Spectre mitigations murder userspace performance
Author : hasheddan
Score : 288 points
Date : 2021-06-19 12:07 UTC (10 hours ago)
(HTM) web link (robert.ocallahan.org)
(TXT) w3m dump (robert.ocallahan.org)
| nerdponx wrote:
| Who is ultimately at risk because of Spectre and Meltdown? What
| additional risks am I taking on by disabling mitigations?
| MauranKilom wrote:
| Those exploits enable any program to read essentially all
| memory.
|
| This means nothing you did between turning on your computer and
| running an application with potentially malicious code (e.g.
| looking at a website with javascript enabled) is secret.
| mhh__ wrote:
| Meltdown for example can exfiltrate data at a genuinely
| ridiculous rate, from any process (or at least any interesting
| ones).
|
| Spectre is more context dependent but Meltdown is _egregious_.
| dijit wrote:
| The scope of the potential damage is rather huge and can't
| really be overstated.
|
| It's akin to handing over your entire working OS memory to a
| person, complete with all encryption keys, session tokens and
| whatever documents you're working on.
|
| Potentially, anyway. The working proof-of-concept attacks I've
| seen use a lot of CPU to read memory and they read slowly, but
| those are proof-of-concepts and it would not be terribly
| difficult for a motivated person to make them significantly
| faster and less obvious.
| thrower123 wrote:
| Has there ever been a real-world attack of this type?
|
| All kinds of things are possible, but you don't cut your leg
| off because theoretically you might possibly one day get
| gangrene from an ingrown toenail.
| mhh__ wrote:
| I assume the triple letters have done it, but these attacks
| require a lot of careful planning so why bother when you
| can exploit something else. That kind of protects us, but
| these exploits are terrifying for purveyors of homogenous
| interfaces (i.e. the cloud) that can be attacked in ways
| you are already imagining.
|
| Also, anyone deploying this won't be stupid enough to chat.
| dijit wrote:
| Yes there are working proofs of concept using JavaScript
| for this kind of attack.
|
| https://leaky.page/ Is a good example
|
| The proof of concept code has been further mitigated by
| removing high precision timers from JavaScript in most/all
| browsers; however it is not terribly difficult to create
| code which bypasses that restriction.
|
| The only thing that's prevented more investment into this
| method of attack is that it has essentially no value due to
| everyone being immune.
| msbarnett wrote:
| There are working proof of concept attacks. The only reason
| you don't hear more about this is that the mitigations
| being complained about here are universally enabled in the
| most vulnerable targets, like cloud hosts.
|
| Otherwise it would be pretty trivial to weaponize the
| original demonstration, deploy an image to AWS or Google
| Cloud and read out all your neighbours' secrets.
|
| The success of the mitigations in rendering these attacks
| unworkable is literally the only reason people are under
| the mistaken impression that the cost of the mitigations
| isn't worth it "because these attacks don't happen".
| kd913 wrote:
| Is this agnostic to hardware? I thought Intel/AMD had different
| strategies regarding variants of spectre with AMD having specific
| solutions of retpoline.
|
| Without knowing the hardware, what is the point of the
| performance comparison?
| yyyk wrote:
| >Is this agnostic to hardware?
|
| Not agnostic at all. Newer processors have less bugs to work
| around, and instructions to speed up the workarounds, so the
| performance impact is smaller:
|
| https://www.phoronix.com/scan.php?page=article&item=3-years-...
|
| The author's hardware is uniquely susceptible - Skylake is old
| enough to suggest Meltdown mitigation (the new Intel processors
| and of course AMD don't require it) in addition to Spectre
| mitigation, yet it's new enough to use indirect branching more
| thoroughly than Broadwell.
|
| If the author had older or newer hardware the performance
| effect would have been smaller.
|
| * It might be noted that there were Intel models betwen Skylake
| and the current which were still susceptible to meltdown. Even
| those had a smaller performance impact:
|
| https://www.pcgamesn.com/intel-security-patch-performance
| apgwoz wrote:
| > Skylake, Linux 5.12
| ghoward wrote:
| I would love to see new chips that take all of the transistors
| used for speculation and use them for more cores. I asked
| electrical engineers once how many of the transistors on a chip
| serve speculation, and they said, "To a first approximation,
| 100%."
|
| That means we could add a lot more cores. Add enough, and the OS
| could easily pin basically all processes/threads to their own
| cores.
|
| And that, I believe, might win some performance back.
|
| I have more ideas at [1].
|
| [1]: https://gavinhoward.com/2020/02/computing-is-broken-and-
| how-...
| saagarjha wrote:
| Hey, I just read your blog post, and while I assume you have an
| interest in making improvements in this area I think you're
| handwaving away a _lot_ of concerns, and are seemingly unaware
| of many other issues in ways that significantly affect the
| viability of your designs. If I could come up with an analogy,
| it might be like if I wrote the following about cars:
|
| "Car design has stagnated for decades. They emit massive
| amounts of greenhouse gases, and they're not even all that
| efficient in doing so. But we can fix this! First, we're going
| to use antimatter to power the engine, it's 100% efficient and
| it has no waste products to boot,"
|
| Your entire post is kind of like this for computer
| architecture. You rely on a lot of theoretical/academic ideas,
| which are cool, but nowhere near being practical (or even
| proven). Then there's stuff like "we'll solve security by
| formally verifying the OS and core software, and writing
| everything else in a memory safe language"...I mean yes, this
| obviously solves certain security issues. But there's no clear
| path to get there, and we don't even have the tools to formally
| verify certain software yet.
|
| Then there are parts where you either undersell your knowledge
| on the topic or are seeming unaware of the current state of the
| art: dynamic linking for example. Your idea of memory mapping
| libraries is basically how dynamic linking works, except you
| call it static linking so you can handwave away the concerns
| that come with it. There's also a lot of things that are
| unlikely to be efficient at all: pinning tasks to their own
| cores means they are unlikely to be doing much most of the
| time, using a ring buffer for message passing means that you're
| going to be spinning on them (which is good for high-
| performance contexts, but most applications aren't going to
| benefit from this). And so on.
|
| I think overall you've actually done a fairly interesting job
| redesigning how a lot of HPC stuff works already, so I guess
| you can at least consider yourself on the right track for that
| kind of thing. But this kind of design isn't really going to
| fly for general workloads, and you're still relying on a lot of
| things that don't actually exist beyond a research paper.
| MauranKilom wrote:
| > Add enough, and the OS could easily pin basically all
| processes/threads to their own cores.
|
| But usually (when you care about performance) you don't have 20
| processes requiring 5% CPU load each, but 1-2 processes
| requiring everything. Making those slower won't accomplish
| much.
|
| And if your problem is _actually_ embarrassingly parallel [0],
| you are looking to run your code on a GPU (as another commenter
| notes).
|
| [0]: https://en.wikipedia.org/wiki/Embarrassingly_parallel
| ghoward wrote:
| I think you need to read my full blog post. :)
| btown wrote:
| > take all of the transistors used for speculation and use them
| for more cores
|
| We have these - they're called GPUs!
|
| https://www.nvidia.co.uk/content/PDF/fermi_white_papers/P.Gl...
| provides a good overview (search the word "speculative"):
|
| > Since most of the circuitry within each core is dedicated to
| computation, rather than speculative features meant to enhance
| single-threaded performance, most of the die area and power
| consumed by Fermi goes into the application's actual
| algorithmic work.
|
| But GPUs are far from easy to code for, even in 2021, and there
| are a lot of workloads that benefit from speculative branching.
| Having a combination of GPU cores and speculative CPU cores in
| an architecture allows you to access the best of both worlds.
| umanwizard wrote:
| ... in the presence of frequent syscalls.
|
| This crucial qualification in the original title is missing from
| the HN title.
| Barrin92 wrote:
| is there an actual number one can attach to at how much risk this
| puts me in practice? Say I'm an average user, writing softare,
| using the web, is it one in a million on any given day, on in a
| thousand? It's hard make judgements about whether to make these
| performance/security trade-offs without any real sense of how
| dangerous it is.
| delduca wrote:
| https://make-linux-fast-again.com/
| albntomat0 wrote:
| Since others may be curious, here is the discussion on those
| specific config changes:
| https://news.ycombinator.com/item?id=22830330
| Verdex wrote:
| I have to say that I'm liking the technical discussion here.
| Although I am surprised that nobody has mentioned the meta topic
| about the word usage of the title. Like did I miss something and
| is "murder" actually legit jargon? Or is the author just being
| dramatic? (Article looked like "kills" would have been perfectly
| adequate and appropriate.)
| c7DJTLrn wrote:
| https://en.wiktionary.org/wiki/superlative
| akersten wrote:
| Well, the marketing of these vulnerabilities was also bombastic
| and hyperbolic, so it follows that the retorts should employ
| similar language so they are taken just as seriously.
| TheGuyWhoCodes wrote:
| This was very well known when the mitigations came out but I do
| wonder if they were too broad. sure mitigation in place for a
| platform that run untrusted code like a browser make sense but
| should it affect every program running? I know trust is fickle
| but at least for power user there should be an option to disable
| mitigation on a per program basis.
| zozbot234 wrote:
| > sure mitigation in place for a platform that run untrusted
| code like a browser make sense but should it affect every
| program running?
|
| The issue is that mainstream OS's are simply not designed to
| protect against information disclosure vulns like Spectre in a
| principled way.
| https://en.wikipedia.org/wiki/Multilevel_security is a very
| well known approach academically but practical implementation
| is lacking. So we have to go with one-size-fits-all mitigations
| that treat all code as untrusted, and all data as potentially
| sensitive.
| hinkley wrote:
| What's the current benchmark situation with pre-spectre and post-
| specter hardware now?
|
| Is there vintage hardware that is now faster than contemporary
| hardware?
| seanalexander wrote:
| There are 2011 MacBook Pro laptops that run as fast or faster
| than the most recent gen of Intel MBPs.
| FranchuFranchu wrote:
| This is the kind of problems backwards compatible legacy
| processors cause.
| dredmorbius wrote:
| Language should have explicit text ordering or concept
| precedence.
| jerieljan wrote:
| Speaking of Spectre/Meltdown, are these mitigations also in place
| with Apple M1 Macs?
|
| I'm quite curious how Apple has handled these.
| yyyk wrote:
| On the one hand, I haven't seen any real exploitation of Spectre,
| at least by a non-TLA. On the other hand, the mitigations aren't
| so slow anymore on a modern CPU:
|
| https://www.phoronix.com/scan.php?page=article&item=3-years-...
|
| IMHO, there's a good argument for turning off the mitigations on
| Skylake in some systems - but in modern CPUs the cost of leaving
| the mitigations on is bearable.
| staticassertion wrote:
| Yeah, kinda similar to rowhammer. I was just saying the other
| day that these exploit techniques are totally viable, but
| there's not much point - privesc is trivial on any desktop
| environment (linux or Windows, maybe less on osx), and usually
| not too hard on servers either. Fancy exploits aren't worth it
| when operating systems are so vulnerable to local attackers.
|
| That said, the mitigations are assurances, and it also lets us
| point a finger at intel and say "fix your shit you just caused
| a global performance regression".
| gok wrote:
| If your code is bottlenecked by syscall overhead, your
| performance was already murdered. Spectre mitigations are just
| stabbing the corpse.
| saagarjha wrote:
| In this case the "murdered" software perfectly describes most
| web servers.
| jfrunyon wrote:
| Here's the lesson: we hit the ceiling on our current technology a
| while ago.
|
| Developers continue to behave as though computing resources will
| continue growing as they used to, even though they've been
| stagnant for years.
| PedroBatista wrote:
| That's not really true.
|
| I think your views are founded on the "moar Mhz moar
| performance" myth ( which is prevalent ), and Intel's decades
| old monopoly didn't help either, but if you compare 2
| equivalent CPU's 10-15 years apart, there is no stagnation in
| performance.
|
| Maybe the old trick of cranking up the Mhz and call it a day
| doesn't work the way it used to, but in terms of performance
| results we are getting improvements.
| emilfihlman wrote:
| Can we have syscall chaining finally? Please? There is literally
| no reason why we couldn't have it.
| Filligree wrote:
| Do you mean io_uring?
| emilfihlman wrote:
| No. Io_uring is a message passing system where you tell the
| kernel to do something and let you know when it's done.
|
| Syscall chaining refers to having the kernel execute
| consecutive systemcalls without switching the context back to
| userspace.
|
| An example of this might be closing a multitude of file
| descriptors or registering signals or writing the same data
| to multiple fds etc, which becomes prohibitely expensive if
| you need to do it multiple times quickly, and actually doing
| it even once is really expensive if your sets are large.
| hinkley wrote:
| Doesn't that address fanout, not chaining?
|
| Chaining RPC calls requires something more sophisticated.
| emilfihlman wrote:
| Io_uring doesn't even address fanout if you mean writing
| the same data to multiple fds.
|
| Io_uring is just a way to have "do this and tell me when
| it's done" io.
| Jweb_Guru wrote:
| I imagine extensions to eBPF are more likely.
| michaelmrose wrote:
| Is this equally true for AMD CPUs? Does the kernel offer
| different mitigations per CPU or one unified set of strategies?
| mwcampbell wrote:
| The title here on HN is missing a crucial qualifier: "In The
| Presence Of Frequent Syscalls".
| kyledrake wrote:
| Honestly, I think it's time to reconsider the wisdom of allowing
| arbitrary untrustable third party executable code to run
| instantly in the form of things like JavaScript on web pages,
| instead of just nerf everyone's computer into molasses to prop up
| an idea that's been bad for the web anyways.
|
| I've been of this opinion for a while now, not just because of
| performance slowdowns and security issues, but also just because
| of the way JS on web sites has been reducing usability in the
| form of popups, bitcoin miners, playing videos, sudden redirects
| to phishing sites and whatever crazy things are out there now.
|
| I'm not saying get rid of JS, but treat it like it is - running
| code you can't trust. Web sites should start as largely static
| HTML documents that you read, and then if they need to use JS
| then they should be required to ask permission to do so, the same
| way any other executable code is managed in any other computing
| environment. That seems wild, but I think it's far less crazy
| than taking away a decade of performance improvements to the
| entire computing ecosystem by default so a broken security model
| can continue unquestioned.
| nhumrich wrote:
| [Deleted]
| staticassertion wrote:
| I think virtually every Spectrev1 POC is browser based
| Javascript.
| staticassertion wrote:
| You're basically saying "let's consider reinventing the
| internet", which I think is not reasonable or a good idea.
|
| I think one problem with the comments about this post is that
| they doesn't emphasize enough that the hit is to system call
| heavy workloads. This is NOT a global slowdown of all compute.
| The hit is to system call performance, and it's big, no
| question, but I don't think we need to throw out the internet's
| structure in order to address that.
|
| One option is to make fewer system calls. For a program that is
| basically scanning a file system that might be harder to do
| today, but for tons of other programs it isn't, and with
| iouring we have a very reasonable escape hatch for optimizing
| syscall heavy workloads.
|
| This might sound silly, but this sort of thing is constantly
| happening - programs are optimized for thinking something is
| fast and something else is slow. For example, if you built a
| program in the 2000s you'd do everything you can to avoid the
| disk, aggressively caching. In 2020 disks are insanely fast,
| and the cost of caching will be worse than just optimizing your
| disk usage.
|
| I don't know about the average website, but from what I can
| tell most sites that aren't total shit are pretty 'clean'. With
| an adblocker, especially so.
|
| > running code you can't trust
|
| We do that already. There's literally dozens of mitigations
| taken based on this.
| kyledrake wrote:
| > You're basically saying "let's consider reinventing the
| internet", which I think is not reasonable or a good idea.
|
| It's absolutely reasonable to require the user to give a web
| page permission to start executing powerful, potentially
| dangerous code on their computer. Also JavaScript is not "the
| internet", nor is it even really "the web", which for most of
| its history was relatively benign HTML documents that you
| read, and things have frankly been on a downward trajectory
| in terms of safety and usability since we started changing
| it.
|
| Powerful JS is a relatively recent phenomenon in the history
| of the web, and largely under the theory that we can do it
| safely with correct design. As someone that has to moderate
| code on un-trustable web sites as part of my work, I can just
| say it's not working out very well, even leaving out stuff
| like spectre/meltdown.
| staticassertion wrote:
| I don't think this would solve anything. This is like
| putting Word macros behind a "do you want to run this
| macro?". Yes, yes they do want to run it.
|
| If people were willing to put every webpage behind a "do
| you want to run this webpage" we'd see them all using
| noscript already - virtually no one wants that experience.
|
| > largely under the theory that we can do it safely with
| correct design
|
| I blame operating systems and hardware vendors tbh. It's
| their job to make this safe, and they do a pretty bad job
| of it. Browser vendors have had to pick up a massive amount
| of slack to try to compensate, to the extent that browser
| teams have to make major patches to the Linux kernel.
| slver wrote:
| JS is already treated like code you can't trust. Adjustments
| will be needed from time to time.
|
| A full block would not be for engineering reasons, but for
| ideological reasons.
| kyledrake wrote:
| "Strong JavaScript" continues to fail this trust model even
| with very careful design, leading to (among other things)
| mitigations in the form of multiple double digit performance
| hits to all computing. That seems more like an engineering
| reason to re-evaluate the status quo to me. "Web sites should
| be allowed to run untrustable executable code because we can
| manage it" feels far more ideological to me, because it's
| based on a belief that is becoming increasingly unfounded by
| the accumulating evidence.
| slver wrote:
| When you talk about performance hit, are you under the
| impression that moving this to the server side would be
| faster? No. So what is the alternative?
|
| If you move everything to apps, apps become the vector.
|
| If you ask for explicit ok online, it becomes like the
| cookie dialog. Pointless.
|
| Offer an alternative.
| cheschire wrote:
| For interested Windows users, you can disable spectre and
| meltdown mitigations using InSpectre:
|
| https://www.grc.com/inspectre.htm
| neilsimp1 wrote:
| `mitigations=off` in your GRUB_CMDLINE_LINUX_DEFAULT to disable
| Spectre/Meltdown mitigations, in case anyone is wondering. This
| page has a pretty decent write-up on it:
| https://leochavez.org/index.php/2020/11/16/disabling-intel-a....
| lumost wrote:
| has there been any research on what hardware changes would be
| necessary to reclaim performance? I've noticed extreme stutter
| events on desktop OSX for the last 2 years. Would be curious if
| its related.
| foobiekr wrote:
| You can turn macOS into Windows 3.1 reading a floppy by
| mounting an SMB share with a ton of small files and running
| an rclone sync between it and an external drive that has
| previously completed a sync. The stat() operations make the
| kernel go crazy. It's the most appalling thing I've seen and
| has been broken like this since Catalina where it arrived as
| a massive performance regression.
| saagarjha wrote:
| You don't even need networked storage for that, just attach
| a slow spiny disk and it'll grind every app accessing the
| filesystem (even if those files are on a super fast
| internal SSD!) to a halt at random points.
| jodrellblank wrote:
| Seems like there's a lot of people with stuttering macOS
| https://apple.stackexchange.com/questions/245429/cursor-
| free...
|
| USB-C and USB 3.0 devices are one common cause, Bluetooth
| mouse interference by USB another, and external monitors
| after sleep/wake another.
| desert_boi wrote:
| https://apple.stackexchange.com/questions/407177/windowserv
| e... started happening in Big Sur to me.
| amelius wrote:
| What if your system is virtualized?
| rbanffy wrote:
| If you are pinned to a core, as non burstable instances
| should be, you are still pretty much vulnerable. Having noisy
| neighbours will pollute caches and make extracting data
| harder, but, eventually, everything will leak out.
|
| I've been thinking what would happen if cores would be pinned
| to separate security domains - all kernel processes run on
| one set of cores and user processes on others. I imagine
| microkernel OSs could go that way much easier. If kernel and
| user space communicate only by messages and shared data,
| there's no reason they'd need to even share an ISA.
| amelius wrote:
| Isn't the entire memory hierarchy (caches) part of the
| problem?
| dijit wrote:
| I love that this is a toggle like this, having control of my
| system is why I love Linux.
|
| But I must caution desktop users against doing this for
| performance, it's _much_ better to have some kind of build
| server somewhere else with this kernel flag than to run it on
| your desktop.
|
| Why? because your desktop executes untrusted and rather
| arbitrary code pretty often, not just in the form of Javascript
| but that's the largest example I can think of.
|
| Right now there's a kind of herd immunity for these things,
| nobody would really attack spectre because everyone is running
| mitigations, but if you make the target large enough there will
| be working exploits.
|
| For isolated machines running trusted workloads (thinking:
| databases or webservers serving static content) then it's a
| really nice flag to have on-hand.
| temac wrote:
| > I love that this is a toggle like this, having control of
| my system is why I love Linux.
|
| You can disable mitigations on Windows too.
| SteveNuts wrote:
| Yeah but the next update will probably turn it back on
| silently...
| a1369209993 wrote:
| Unlikely; Windows updates (mostly) only turn things you
| disabled back on if they're harmful to you.
| toomanyducks wrote:
| idk about this, my anecdotal experience suggests
| otherwise - irrelevant things (i.e., monitor resolutions,
| mouse acceleration curves, and I think DNS settings at
| one point) can be thrown around by updates a bit too
| frequently in my experience.
| saurik wrote:
| Yeah: and disabling mitigations for an attack certainly
| wouldn't be considered "harmful" by anyone.
| tyingq wrote:
| Nice 3rd party toggle for windows:
| https://www.grc.com/inspectre.htm
|
| Or a Powershell script from MS:
| https://support.microsoft.com/en-us/topic/understanding-
| get-...
| rkagerer wrote:
| I'd like some more technical details on what exactly
| InSpectre does (specifically for the Meltdown patch). e.g.
| Does it just flip a registry key? Rewrite a microcode patch
| somewhere? Couldn't find an explanation in the software
| (even under Show Tech Details) or on their site; could you
| point me to it?
|
| Also, do all the major browsers now have their own
| mitigations built in?
| rkagerer wrote:
| Answering my own Question #1: Looks like it sets values
| for FeatureSettingsOverride and
| FeatureSettingsOverrideMask under the "HKEY_LOCAL_MACHINE
| \SYSTEM\CurrentControlSet\Control\Session Manager\Memory
| Management" registry key.
|
| FeatureSettingsOverride is a bit field where bit 0
| controls the mitigation for CVE-2017-5715 (Spectre) and
| bit 1 controls it for CVE-2017-5754 (Meltdown). If the
| bit value is 0 the corresponding mitigation is enabled,
| if 1 it's disabled. FeatureSettingsOverrideMask is simply
| a mask to control which bits of FeatureSettingsOverride
| to apply. So, for example, FeatureSettingsOverride = 2
| and FeatureSettingsOverrideMask = 3 would enable the
| Spectre mitigation (if available) and disable the
| Meltdown one.
|
| More info here:
|
| https://support.microsoft.com/en-us/topic/windows-server-
| gui...
|
| https://gist.github.com/daBONDi/6f86210e54c68e84e85372fc4
| d1f...
|
| Haven't checked if the program emits different behavior
| for other CPU's or OS versions.
| Datagenerator wrote:
| Propitiatory big brother OS has some cryptic setting, so?
| Linux and BSD give the user all sorts of freedom
| Microsoft never will. Freedom to research the source,
| ability to disable telemetry if that would exist and so
| on.
| IshKebab wrote:
| Kind of feels like apps should opt in to (or out of)
| mitigations individually. Obviously a web browser needs it,
| but does Clang? VSCode? Zoom? Probably not.
| edflsafoiewq wrote:
| Didn't browsers implement their own mitigations? Or were
| those only for some vulns?
| kzrdude wrote:
| Vscode is a browser
| Nullabillity wrote:
| As in "it runs JavaScript and renders HTML", yes. As in
| "it runs stuff in a security sandbox", no.
| squiggleblaz wrote:
| How about extensions? I would have thought these amount
| to a comparable security concern as web pages. Do they
| have adequate isolation?
| IshKebab wrote:
| No, extensions are fully trusted. They can do anything.
| dijit wrote:
| Three main things here:
|
| 1) we can't trust people to categorise their own apps
| because the incentive for performance over security is a
| trade off we've all made time and time again.
|
| 2) efforts to address mandatory access controls have a
| coloured history here: selinux and apparmor both have very
| low adoption rates no matter your personal anecdotes.
|
| 3) These mitigation's are so thorough that it would be more
| expensive on performance to even _check_ per application
| than it would be just to enable it everywhere.
| staticassertion wrote:
| I don't think that (3) is true.
| dijit wrote:
| How would you implement such a change?
|
| Considering that you have:
|
| A) some list of allowed applications/programs
|
| B) a run of this check on every syscall
|
| C) to be faster than a TLB flush
| staticassertion wrote:
| I don't know but I can't imagine a highly predictable
| branch being slower than a TLB flush.
| dijit wrote:
| Well consider the fact that checking a table of "ok"
| programs is a branch _and a lookup_ in of itself.
| staticassertion wrote:
| Yeah that should be really fast, still. Programs could
| also opt to just _tell_ the OS "hey don't check this
| system call from me", on each system call, avoiding any
| lookup.
| ikiris wrote:
| Just require everyone evil to set the evil bit, and
| everything would be much easier.
| josefx wrote:
| > not just in the form of Javascript but that's the largest
| example I can think of.
|
| As far as I understand browsers still get owned at every
| pwn2own. So you might want to stop running untrusted
| JavaScript anyway.
| swiley wrote:
| I'm continually shocked that people are so ok with
| automatically executing any code random sites they connect
| to shove at them.
| alisonkisk wrote:
| Code is data. Data is code.
| swiley wrote:
| It's more or less impossible to express recursion (in the
| same ways you can with js) with pure css/html.
|
| If you want to be overly reductionist then you can argue
| nothing matters because your just staring at a box with
| lights in it.
| bruce343434 wrote:
| Viral bacteria are matter. Matter is viral bacteria.
| dijit wrote:
| I don't want to go into this topic because frontend
| developers are very defensive of their capability to
| Javascript on people, they often cite javascript adoption
| numbers as proof that it's fine to make it mandatory or
| cite complex web applications as a reason for it to be
| mandatory for all sites, which I personally find to be a
| false dichotomy.
|
| I tend to agree with what you're saying but the ship has
| sailed very much and running without javascript is a losing
| proposition these days.
|
| (my web browser starts up with javascript disabled except
| for some whitelisted sites and it usually only takes 15
| minutes for me to find something completely broken on the
| internet and re-enable javascript entirely).
| sneak wrote:
| Nah. I browse the web with NoScript. Snowden himself says
| to disable scripting in browsers.
| voakbasda wrote:
| Entirely? Use NoScript to temporarily enable only those
| portions of the single site that you need. No
| affiliation, just a happy user.
| SkyMarshal wrote:
| /second NoScript. Instead of whitelisting whole sites,
| you can whitelist links to JavaScript imports across all
| sites, temporarily or permanently.
|
| So for example, you can whitelist urls to all the major
| JavaScript frontend frameworks' CDNs, like bootstrap,
| etc. while leaving known trackers and spyware blacklisted
| by default.
|
| Anecdotally it seems most websites still work with their
| trackers disabled, as long as they have their frontend
| framework/s loaded.
| gruez wrote:
| I disagree. There are way too many sites that require
| javascript that you'll eventually get into the habit of
| blindly enabling scripts when a site breaks, negating any
| security benefits.
| argomo wrote:
| I used to do this. It broke too often when doing credit
| card purchases though... it would take multiple attempts
| to complete a purchase and figure out which domains
| needed to be enabled. Sometimes the status would be left
| ambiguous. Once I double-spent, but fortunately it was a
| cancellable reservation. I suppose you can do better if
| you just spend at a few key sites.
| SkyMarshal wrote:
| _> it would take multiple attempts to complete a purchase
| and figure out which domains needed to be enabled._
|
| Yeah I went through this too, figuring out all the CC
| purchase redirects. Some are just idiotic to the point I
| wish govts would pass a law mandating zero redirects for
| online purchases. Stripe, Paypal, Square, Braintree and a
| few others do payments just fine without the redirects so
| it's clearly possible.
|
| But eventually even that gets solved and the redirects
| get whitelisted. Haven't encountered this problem for a
| long time.
| SkyMarshal wrote:
| I disagree. I'm not just pulling this out of my ass, I've
| been doing exactly this for years, I can't remember how
| long. It works fine.
|
| _> you'll eventually get into the habit of blindly
| enabling scripts when a site breaks, negating any
| security benefits._
|
| The key here is that when you're deciding whether to
| whitelist a JS import, and you don't know what it is and
| don't want to take the time to look it up, then whitelist
| it temporarily not permanently. It will be moved back to
| the blacklist the next time you restart the browser.
|
| Only permanently whitelist JS that you know for sure
| isn't a tracker or malware or sketchy.
| msbarnett wrote:
| > Only permanently whitelist JS that you know for sure
| isn't a tracker or malware or sketchy.
|
| What's the whitelist based on? URI? Or file content hash?
| Because today's "criticalsitefunctunality.js" is
| tomorrow's "upstream got p0wned and there's a Bitcoin
| miner in there too now".
|
| Sites churn so often that "permanently" whitelisting
| hashes is probably a never ending chore, and you're
| unlikely to want to constantly re-inspect minimized JS,
| so this eventually turns into semi-blind faith.
|
| And permanently whitelisting URIs is pure security
| theatre; that file could contain anything, next request.
| SkyMarshal wrote:
| I'm aware of all that, but it's not theater, it's just
| part of a defense in depth strategy. Reduces attack
| surface area, doesn't eliminate it, while maintaining
| usability of the web.
|
| If you have a better approach that accomplishes both of
| those objectives, do tell.
| msbarnett wrote:
| > If you have a better approach that accomplishes both of
| those objectives, do tell.
|
| Use a browser that isolates the JS engine in its own
| process and leave spectre mitigations enabled rather than
| try to play kid-plugging-holes-in-dike-with-finger by
| auditing all the world's constantly-changing JS for
| spectre/meltdown gadgets?
| SkyMarshal wrote:
| _> Use a browser that isolates the JS engine in its own
| process_
|
| Definitely. All for that.
|
| _> and leave spectre mitigations enabled_
|
| I do that anyway. The performance cost is unnoticeable to
| my normal workloads.
|
| _> rather than try to play kid-plugging-holes-in-dike-
| with-finger by auditing all the world's constantly-
| changing JS for spectre/meltdown gadgets?_
|
| I'll continue doing this too, largely because I want to
| see what's going on behind the scenes on all the websites
| I visit. Useful for me to see it all, especially as it
| changes over time as you observe.
|
| That said, Easylist and Privacylist are also great if
| you'd rather crowd-source the finger-in-dike-hole-
| plugging.
| gruez wrote:
| I'm sure it adds some amount of security. I'm just
| skeptical it adds enough security to be worth the hassle.
| I discussed the threat model here:
| https://news.ycombinator.com/item?id=27564457 and came to
| the conclusion that it wouldn't prevent much attacks in
| practice.
| hutzlibu wrote:
| You probably misunderstood : allmost all websites require
| javascript, yes - but you can selectivly allow only the
| javascript of that site, their framework etc. and block
| all the tracker/ads javascript with NoScript/UBlock - and
| then it is working and probably quite safe. But to
| mitigate, more and more websites find ways to sneak in
| the tracker/ads/analytics into the main sites js. So it
| is not as easy, either.
|
| Which is why I just use basic ublock origin and regulary
| wipe the browser cache.
| gruez wrote:
| >but you can selectivly allow only the javascript of that
| site, their framework etc. and block all the tracker/ads
| javascript with NoScript/UBlock
|
| What's the difference between that and just using the
| standard easylist/easyprivacy filter? I suppose there's a
| small chance that a third party site went rogue and isn't
| on the default lists, but I'm skeptical how many attacks
| that would thrawt in reality. The attacks I heard of tend
| to be first party/supply chain (would be white listed by
| you), or delivered through an ad network (probably
| already be on a blacklist).
| SkyMarshal wrote:
| Easylist and Privacylist are great. I suppose the main
| reasons for doing it manually are seeing firsthand what
| all the sites you visit are doing behind the scenes, and
| getting a sense of what is legitimately needed
| functionality, what isn't, and what is just downright
| sketchy.
| hutzlibu wrote:
| Yup. But you can only do this when you have time for it.
| I kind of got very pragmatic with it.
| josefx wrote:
| I feel that is a bit like driving blindfolded because you
| might get distracted at some point anyway. Sure that one
| script you have to enable might be the one to exploit
| your system, but it might also be one of the dozens that
| didn't do anything useful.
| beebeepka wrote:
| I've been using noscript for at least a decade and it
| hasn't happened yet. I have conditioned my wife to use it
| too. She doesn't do it either
| gruez wrote:
| So what happens if you go to a site and see a
| blank/broken page? Do you just go back and abandon the
| page? Do you do a full risk assessment of each of the
| domains? What does that assessment entail?
| alisonkisk wrote:
| uMatrix by uBlock Origin too.
| dijit wrote:
| I use a browser called Qutebrowser which doesn't have a
| noscript addon; but I can disable javascript loading on a
| domain level.
|
| However, overall I can tell you for absolute certain: if
| you have JS partially disabled things break in non-
| obvious ways and I find myself playing whack-a-mole with
| allowing various domains to load javascript to get the
| page working.
|
| I'm pretty certain you do also, because it's basically
| impossible to tell why certain damned sites are broken
| and the most obvious thing to do is just enable JS
| temporarily to see if it works at all.
|
| This is especially annoying on some part of a site such
| as checkout- where reloading the page causes a form
| resubmission.
| alisonkisk wrote:
| I like this breakage because it makes me unhappy with the
| website and less likely to use it -- the immune system is
| working as it should.
| KronisLV wrote:
| That's probably a good approach for random news sites and
| such, much less so when your internet banking and even
| online shopping sites require JS on.
| dustingetz wrote:
| your desktop is already rooted by Zoom
| bostonsre wrote:
| Seriously. I hate zoom, there are so many features that
| smell like malware (how when a call starts sometimes my
| system level volume no longer is controllable and I have to
| go to zoom settings to control it. I have windows+wsl, but
| it's happened on macs in my company as well). Google gets a
| lot of hate, but I like their meeting tool because they
| keep it simple and it works.
| matsemann wrote:
| I just changed company. Wish I could go back to Zoom.
| Google Meet is horrible. I have to open Chrome for all
| meetings, as it (probably intentionally) runs worse in
| other browsers. But even in Chrome there are issues. Some
| workloads (like running tests) can take 5x as long on my
| system if I'm sharing my screen on Meet. Making working
| with others more hassle than it should be.
| jacquesm wrote:
| This is fair, but at least you're sure that when you
| close the window that it's _gone_ and that is as far as I
| 'm concerned its biggest feature. Oh, and that it seems
| to work well on all platforms.
| cj wrote:
| "Close browser tab" - immediately exits a Google Meet.
|
| Closing a Zoom/Webex meeting, who knows since it's still
| running in the background.
|
| I also like meetings sandboxed in a browser so weird
| things like "automatically take control of your screen
| and maximize window" doesn't happen when someone in a
| Zoom meeting starts sharing their screen.
|
| Even at the expense of more CPU.
| teddyh wrote:
| > _"Close browser tab" - immediately exits a Google
| Meet._
|
| How would you know? Or, put another way: Why don't you
| want to trust Google Meet, but apparently want to trust
| Google Chrome?
| wizzwizz4 wrote:
| Meet isn't much integrated into Chrome, so absent a
| Chrome bug, closing Meet stops running Meet code, so
| stops the meeting. "Closing" Zoom relies on Zoom
| detecting the closure and stopping the meeting.
|
| It's not about spying from the software authors (having
| these softwares on your computer makes _that_ impossible
| to defend against), but about knowing whether the people
| you were just talking to still have access to your camera
| and microphone feeds.
| ulzeraj wrote:
| That meme with the actor taking to a bloodied Jesus comes
| to mind while reading you guys comparing google with
| zoom. You guys are so lucky. I work on Skype for Business
| over a Citrix Workspace connection.
|
| While Skype is an unmitigated disaster that can't do
| simple stuff like copying text there is Citrix that
| requires a wizard installer with admin rights that
| deploys 3 background services and requires an audio
| plugin (separated, with another wizard installer) to do a
| worse remote streaming experience than what discord does
| for teenagers using a browser.
| Sunspark wrote:
| The inability to copy text may be due to an admin
| setting. At my previous workplace they disabled the
| ability to paste in images, etc. into Skype for Business
| saying that it was a security risk. They also disabled
| the ability to copy and paste between apps except within
| MS Office for the same reason.
|
| It's not Citrix doing this, but your administrator.
| ulzeraj wrote:
| Copy and paste works. They did disabled any communication
| between the client machine and the Citrix VDI except for
| audio and camera but the feature I'm complaining about is
| within the Remote Desktop. It works but its random and
| terrible. Sometimes you try to copy a single word but it
| copies the entire message along with the metadata
| containing sender and timestamp.
| formerly_proven wrote:
| Since you are on Skype for Business I'm going to assume
| you are not using Teams currently. Teams is actually a
| lot worse in almost every way than SfB when it comes to
| the functions both systems share.
|
| > While Skype is an unmitigated disaster that can't do
| simple stuff like copying text
|
| Do you mean from shared contents or from the chat? The
| latter works for me, but since you also mention using
| Citrix Workspace, which sounds like a remote
| desktop/application tool, it seems likely to me that this
| is actually the fault of Citrix, not Skype. Remote
| clipboards seem to be rather unreliable, I'm using DCV
| 2017 and the clipboard breaks basically every five
| minutes, necessitating a reconnect.
| ulzeraj wrote:
| Sometimes you copy what you want sometimes you copy the
| message with the metadata and sometimes copy doesn't
| work. Pasting stuff from other sources will cause some
| weird table elements to appear. There is no way to format
| code. Sometimes it says the message is too big but then
| you paste the same message into notepad and copy paste
| again it works just fine. The text editor and
| visualization seems to be arctifacts of a bygone era
| where everything was rich text.
|
| I'm not sure if it's the clipboard because my employer
| does not allow shared drives, clipboard, usb or any
| resource from my local machine except for mic and webcam.
|
| Ohhh and let's talk abou the HUGE black ribbon at the top
| of the screen when you are sharing your window. It
| totally covers the browser tabs. You have to restore the
| window and switch tabs and maximize it again. It _is_ an
| unmitigated disaster that degrades the overall
| experience.
| thrower123 wrote:
| There has never been a webmeeting software that people
| didn't bitch about constantly. They all suck, because,
| fundamentally, what they are trying to accomplish sucks.
| Nobody wants to do audio/video meetings, we just suffer
| through them because we have to.
| ziml77 wrote:
| We had Zoom at our workplace for longer than most people
| knew what it was and I still have not installed it on my
| own PC. If I don't need to have myself on video, I run
| zoom on the work machine I'm remoted into and use my
| phone for the audio. If I need to use video, I use the
| application installed on my iPad since I trust that it's
| even more sandboxed than my Android device. I would
| rather not have the application installed on any of my
| personal devices, but that's the closest I can get when
| it comes to keeping Zoom away from my stuff.
| jacquesm wrote:
| And teams. And all that software that you used to be able
| to use that you have to make exceptions for so that in the
| end you end up forgetting to re-enable some critical part
| of the windows scareware implementation.
|
| Seriously: try installing Firefox on Windows 10 (I had to
| do this recently, I have now _one_ computer in the house on
| Win 10 due to a hard requirement for some software
| /hardware combo), and you'll see Microsoft learned next to
| nothing from the browser wars lawsuit. They're simply
| asking to have this done to them again, they now actively
| discourage Firefox to be installed by claiming it can
| 'damage your computer' and is insecure. Incredible this
| stuff.
|
| Oh, and Google will return a link for Chrome as the first
| item when you search for Adblock for Firefox. You can't
| make this stuff up.
|
| Has there ever been a large company in IT that didn't turn
| absolutely evil as soon as the opportunity presented
| itself?
| nerdponx wrote:
| > Has there ever been a large company that didn't turn
| absolutely evil as soon as the opportunity presented
| itself?
|
| No?
| rbanffy wrote:
| > Has there ever been a large company in IT that didn't
| turn absolutely evil as soon as the opportunity presented
| itself?
|
| If turning evil increases shareholder value, it's their
| fiduciary duty to do so.
| pstuart wrote:
| > If turning evil increases shareholder value, it's their
| fiduciary duty to do so.
|
| Meh. Maybe not: https://medium.com/bull-market/there-is-
| no-effective-fiducia...
| tester756 wrote:
| >Oh, and Google will return a link for Chrome as the
| first item when you search for Adblock for Firefox. You
| can't make this stuff up.
|
| Maybe your profile affects results, here:
|
| "Adblock for Firefox"
|
| returns
|
| "https://addons.mozilla.org/en-US/firefox/addon/adblock-
| plus/"
|
| "adblock"
|
| returns 1st url = https://adblockplus.org
|
| 2nd url is = chrome.google.com
| Natsu wrote:
| > Microsoft learned next to nothing from the browser wars
| lawsuit.
|
| That's been true since the very beginning.
|
| I very nearly filed papers to oppose class council in one
| of the state lawsuits on the basis that the proposed
| settlement was calculated to create a new antitrust
| injury to the class.
|
| But I didn't because I was young and pro se and there was
| no way for me to afford or find representation. If I had
| to do it again I would've filed pro se requesting that
| they reject the settlement on that basis and appoint a
| guardian ad litem to roll the dice anyway.
| formerly_proven wrote:
| > You never sent me a response on the question of what
| things an app would do that would make it run with MS-DOS
| and not run with DR-DOS. Is there [a] feature they have
| that might get in our way?
|
| Bill Gates
|
| > What the [user] is supposed to do is feel
| uncomfortable, and when he has bugs, suspect that the
| problem is DR-DOS and then go out to buy MS-DOS.
|
| MS SVP Brad silverberg
|
| > If you're going to kill someone there isn't much reason
| to get all worked up about it and angry. Any discussions
| beforehand are a waste of time. We need to smile at
| Novell while we pull the trigger.
|
| MS VP Jim alchin
|
| What has changed? Nothing, of course. Settling and paying
| fines for blatant abuses of dominant market positions has
| been Microsoft's MO for decades.
| revscat wrote:
| The behaviors described here are intrinsic to capitalism,
| and are not peculiar to any individual company. The
| executives quoted here are simply describing the waters
| they swim in. But they are only one fish in the sea that
| is liberal governance. The system is the problem, not
| Microsoft.
| rbanffy wrote:
| This system will cause any publicly traded company to
| behave like a sociopath and limit career paths for non-
| sociopaths who are unwilling to break (or bend) the law
| to further their agendas.
| thatguy0900 wrote:
| With growth hacking it seems that all the it companies
| that get big now were evil when they were small, too
| Santosh83 wrote:
| I run Windows 10 (Home) since years and the OS has so
| far, never tried to warn me about Firefox. It _does_
| however reset default browser back to Edge after biannual
| major OS upgrades. Also searching 'adblock for Firefox'
| on Google returns several results from Mozilla addons for
| me. Chrome is not linked anywhere on the first page of
| results.
|
| What is personally more annoying is Edge keeps randomly
| popping up a banner asking if I'm sure it shouldn't be
| the default browser. When a user declines once, the OS
| shouldn't nag repeatedly.
| hutzlibu wrote:
| "When a user declines once, the OS shouldn't nag
| repeatedly. "
|
| Haha, ... when you apply that standard to the modern
| world - you sometimed wish the stoneage back.
|
| Seriously, there is something deeply wrong with society,
| when all this shit just gets accepted by everyone.
|
| "Telemetry" such a innocent word. If they would write we
| record allmost everything you do on your computer and
| send that data to wherever we want to .. I doubt much
| would actually change, as MS office software is still
| mandatory in many places, but maybe there would be more
| awareness of it.
| bennyp101 wrote:
| I just setup 2 laptops this week on Win10 Pro, inatlled
| Firefox and Chrome, and nowhere did it mention anything
| about Firefox being bad?
|
| Maybe a Win10 Home, or some other version? Or was that in
| a search result (or ad) not actually Windows?
| callahad wrote:
| Give it time; it's a trickle campaign. Just this morning
| I updated my Win 10 Pro desktop, and on reboot I got a
| full screen wizard prompting me to "use recommended
| browser settings" which is doublespeak for changing my
| default browser to Edge.
|
| Edit: On re-reading, I believe OP was specifically
| referring to false positives with SmartScreen that crop
| up regularly, like at https://www.reddit.com/r/firefox/co
| mments/n7gige/ms_edge_blo...
| kevingadd wrote:
| The SmartScreen stuff is a plague that applies to all
| software developers in varying degrees. Chrome does this
| with their safe browsing stuff too, I hate it -
| essentially everyone gets told your exe is "malicious"
| until enough people have downloaded it without it being
| flagged as malware.
|
| The idea that it applies to trusted vendors like Mozilla
| shipping code-signed executables is bonkers to me.
|
| Nice way to promote further centralization into services
| like app stores that don't suffer from this!
| LinuxBender wrote:
| You can disable SmartScreen with O&O ShutUp10 [1] on the
| home version.
|
| [1] - https://www.oo-software.com/en/shutup10
| hutzlibu wrote:
| " Has there ever been a large company in IT that didn't
| turn absolutely evil as soon as the opportunity presented
| itself?"
|
| I like nuances, though. "absolute evil" is a bit strong.
|
| There were companies who were engaged with enslaving
| people and working them to death. (some still are)
|
| I am no fan of googles development, but absolute evil
| leaves no room to describe other companies who are
| actually worse.
| toomanyducks wrote:
| > some still are
|
| well that's an understatement[0].
|
| I alos think it's less productive to interpret the phrase
| absolute evil as a comment on an entity's moral
| alignments (because it's a corporation, it's not chaotic
| evil or neutral good, it just is) but as a comment on the
| foundation and effects of the economic and political
| systems defining of the corporations (capitalism under
| neoliberalism). Absolute evil seems like a fairly decent
| personification of those metrics to me: every extra push
| to manufacture another product pushes us closer to a
| climate catastrophe (even 'green' products like Teslas,
| _especially_ green products like Teslas[1]). Even if you
| deny climate change, you can 't deny that workers _are_
| being taken advantage of near habitually. If we 're going
| to personify the destruction of the earth and the worker,
| absolute evil does _not_ seem too far off.
|
| 0: https://en.wikipedia.org/wiki/Foxconn_suicides for one
| 1: https://www.wired.com/2016/03/teslas-electric-cars-
| might-not...
| hutzlibu wrote:
| There is still a big difference, between exploiting
| people - and owning people - and literal doing what you
| want with them. Flock them. Burn them. Rape them - as you
| please. This is slavery as it used to be (and partly
| still is!!). And that term gets watered down when applied
| to something else.
|
| Exploiting people because they are desperate is a big
| problem. Maybe call it modern day slavery. But it really
| is not the same as what slavery means for people who are
| literaly and 100% owned by others.
| marcosdumay wrote:
| Just because it's rooted by 1 or 20 companies it's not
| reason to open it up to any random person on the internet.
| porphyra wrote:
| Phoronix has comprehensive benchmarks on the impact of
| spectre mitigations if you want to find out how much of a
| difference it will actually make before exposing your system:
|
| https://www.phoronix.com/scan.php?page=search&q=Spectre
| BeeOnRope wrote:
| It's worth noting that mitigations=off doesn't even restore
| _all_ the performance, compared to kernel versions before
| Spectre mitigations were added at all.
|
| mitigations=off can only "patch out" some expensive
| instructions in the syscall path, or sometimes take a different
| path entirely, but it can't go back to the simple code before
| this was added in the first place. It also can't undo effects
| of compiler flags like -mindirect-branch which change the
| compiled code.
|
| I haven't tested it recently, but when I looked at this more
| than a year ago, the numbers for a simple syscall (which
| doesn't do much work beyond the syscall mechanics itself) were
| something like 130ns, 250ns, 700ns for a "pre mitigation
| kernel", "new kernel with mitigations=off" and "new kernel with
| mitigations=on".
|
| Some of the numbers have improved since then as better
| mitigations have been found, and/or improved CPU support for
| mitigations via microcode updates.
| nemetroid wrote:
| In your kernel command line, to be more precise. If you use
| Grub as your boot loader, this can be achieved by adding it to
| GRUB_CMDLINE_LINUX_DEFAULT.
| nickpeterson wrote:
| I've made similar comments in the past but I think we're just
| trying to predict too much about what programs are trying to do
| in hardware.
|
| I'd rather have simple hardware that is light on energy
| requirements and easier to understand. I don't think software as
| an industry really has a "this chip isn't fast enough problem".
| Most of the real slowdowns anyone has in day to day performance
| has more to do with inefficient code than hardware anyways.
|
| Look at old game consoles (like a regular old PlayStation) and
| what they were able to render on what today would be laughably
| slow hardware. They could do it because developers learned the
| stack inside and out.
|
| I'm hopeful that the emergence of arm as a desktop/server
| competitor will help in some ways by putting enough pressure on
| companies like intel to really rethink some of their core stuff,
| but who knows.
| mkr-hn wrote:
| See: racing the beam
|
| https://www.youtube.com/watch?v=sJFnWZH5FXc
|
| The things they did with 128 bytes of RAM were amazing.
| UncleMeat wrote:
| > I'd rather have simple hardware that is light on energy
| requirements and easier to understand. I don't think software
| as an industry really has a "this chip isn't fast enough
| problem".
|
| Turning off speculative execution reduces performance
| _enormously_. Yes, code is often less efficient than it could
| be but "surprise, you need 5x as large of a datacenter because
| your hardware isn't doing fancy stuff" is not going to be an
| acceptable thing for any large organization.
| icegreentea2 wrote:
| More specifically, we should point out that speculative
| execution is important for papering over IO/memory latency.
| We can incant all we want about 'inefficient code', but the
| compute vs memory latency imbalance is a whole different
| beast.
| infogulch wrote:
| I suspect our heavy reliance on speculative execution is just
| a local optimum, and we can grow out of it by providing the
| processor more information about the data flow, making memory
| access more explicitly asynchronous, and simplifying the hot
| paths.
|
| I like the way the mill approaches these architectural
| problems.
| monocasa wrote:
| I agree with what you're saying around the Mill and
| dataflow in a sense, but feel like we disagree in the
| details. The issue with Spectre, etc. is that data of
| different trust levels are comingled in a single address
| space. We want the processor to speculate on some data, but
| not others and we don't tell it how to tell the difference.
| What's going to save us isn't dependency information or
| static scheduling, but more fine grained permissions around
| the data accessible at a single time.
|
| IMO we need to bring back segmentation hardware. Not the
| x86 version of segmentation (there's not a feature that x86
| wasn't able to make twice as complicated as it needed to be
| while only giving you half the use cases), but the cleaner
| object capability on top of paging hardware versions of
| segmentation. That solves the really rough Spectre cases
| like even NetSpectre where you can slurp out kernel state
| remotely from untrusted network packets. Just stick them in
| a "this memory is untrusted" segment. From there the CPU's
| dynamic dataflow optimizations can include speculation
| where memory is marked as trusted.
| zozbot234 wrote:
| The interesting part about the Mill is that it's not even
| all that complex. It's just taking the existing VLIW
| architectural approach and adding a number of custom
| "tweaks" to improve the programming model over what VLIW
| provides.
| tux3 wrote:
| I'm very unconvinced by these arguments. Providing enough
| information to the processor to claw back all the
| performance that predictors give you, that requires some
| way of knowing all those things in advance. Statically.
|
| And so you fall into the pit of tar and despair that is
| relying on Sufficiently Smart Compilers. Same one that
| couldn't save Intel's shiny new IA-64 architecture (the
| "Itanic").
|
| Static analysis is just not a tractable way to replace
| hardware predictors. Even profile-guided information is a
| questionable answer. Could it be we're missing some key
| idea that'll take us far beyond all of this? Maybe, but
| it's probably not the same WLIV designs that require
| impossible feats of software comparable to asking for the
| weather 2 years in advance so you can save yourself the
| hardware cost of an umbrella.
|
| Now, perhaps it would be unfair to criticize the Mill for
| not taping out an actual chip, after all having new ideas
| is valuable and fabs are very expensive. But we know this
| is a tricky subject. Performance optimization ideas only
| have value after you benchmark them, and they don't have an
| RTL implementation. Nothing that can run on an FPGA, not
| even "abstract" Verilog running in a testbench on a
| software simulator.
|
| If what you want is a DSP that runs super simple hot loops
| very fast, then build a DSP and make it VLIW all you like.
| But that's not the workloads people run on a general
| purpose computer.
| wizzwizz4 wrote:
| > _And so you fall into the pit of tar and despair that
| is relying on Sufficiently Smart Compilers._
|
| How will we ever know that a Sufficiently Smart Compiler
| is impossible, if we never have processors where compiler
| intelligence is useful?
| saagarjha wrote:
| > And so you fall into the pit of tar and despair that is
| relying on Sufficiently Smart Compilers. Same one that
| couldn't save Intel's shiny new IA-64 architecture (the
| "Itanic").
| wizzwizz4 wrote:
| And how can one get their hands on an Itanium machine?
| It's a dead architecture in less than two weeks, and for
| the last decade the things have been almost exclusively
| enterprise machines; not something the hobbyist (or even
| the academic!) is likely to get access to.
|
| Do you have an HP zx6000 lying around, perchance?
|
| Itanium failed early; it had many more problems than
| compilers. And if we don't have a replacement, we'll
| never get those compilers from anyone but the most
| obsessed.
| pjc50 wrote:
| Is the Mill dead? I've not seen the regular flow of HN
| posts about it recently. Everyone got excited about RISC-V
| instead.
| mhh__ wrote:
| They're still going - Ivan said on their forum that they
| were planning on going full steam ahead last summer, but
| scuppered by lockdown. I don't totally buy that, but
| that's the story.
| mburns wrote:
| Not dead, just impacted by the pandemic.
|
| https://millcomputing.com/topic/on-the-lack-of-progress-
| repo...
| temac wrote:
| This has been tried (not on vaporhardware Mill, I'm more
| thinking about e.g. Intel Itanium) and it failed.
|
| The reason is extremely simple: a speculative OOO processor
| optimizes dynamically. If you switch that with static
| compile time optimizations, you are bound to only be as
| fast as before in some quite limited parameter ranges
| (like: number of entries in a hash table, size of an image,
| etc.)
| homerowilson wrote:
| Also don't forget the really interesting Transmeta
| processors, also ultimately a failure. VLIW is very
| difficult in practice.
| verall wrote:
| This is sort of what GPUs do, since a GPU driver is
| essentially a big JIT compiler. Branching is very expensive
| compared to CPUs. Remember that 95%+ of branches of
| predicted successfully, and CPUs work on more stable ISAs.
| josh2600 wrote:
| We're seeing a full frontal assault on Intel by competing
| computing architectures. Everyone is jockeying to see who is
| going to have the better next gen architecture. The problem is
| that in order to start attacking general computing as a
| problem, you need first customers who buy a lot of chips, and
| those customers tend to have specific workloads they want
| accelerated. Now we're back to designing for customers instead
| of abstractly making the absolute best chip.
|
| And that's the reality right? Demand drives innovation it
| private enterprise is funding it. If you want a chip for the
| public good, you'd need to fund it with public money and that's
| a different dance with the devil.
|
| In short, I think the way that technology is produced is
| fundamentally customer focused right now.
| im3w1l wrote:
| I think this has cause and effect reversed. Advancing general
| purpose CPU's is very hard and expensive nowadays. The slower
| rate of progress means that custom chips make more sense,
| they take longer to become obsolete.
| astrange wrote:
| > I'd rather have simple hardware that is light on energy
| requirements and easier to understand. I don't think software
| as an industry really has a "this chip isn't fast enough
| problem".
|
| Have you seen how happy people are with M1 machines? That's
| because it's faster. It's definitely not simpler.
|
| > Most of the real slowdowns anyone has in day to day
| performance has more to do with inefficient code than hardware
| anyways.
|
| Not true, especially not for heat. The energy use of on-CPU/on-
| GPU tasks is more up to the hardware. It might be true for
| things like network bandwidth though.
| saagarjha wrote:
| Wait until Slack outfits their developers with M1 machines
| and we'll quickly be back to being unhappy again.
| temac wrote:
| You would be surprised how "slow" a non speculative processor
| is.
|
| Even Intel Atoms have been speculative since Silvermont.
|
| If you take more mainstream historical processors, for example:
|
| https://www.cpu-world.com/Compare/385/Intel_Pentium_Dual-Cor...
|
| Let say the Pentium MMX 166 is roughly 60x slower, per core,
| than the Pentium G6950. So the "IPC" (I'm not sure of what the
| benchmark are doing, but I'm doing rough evaluations anyway) is
| approx 3.5 lower for the Pentium MMX.
|
| And that is while the speed gap constantly increased between
| memory and CPU (esp latency), so a Pentium MMX cpu core somehow
| speed up to 2.8 GHz would actually probably perform even worse
| in a design with memory that actually exists. Maybe way worse.
|
| The complexity of modern good ARMs is comparable or even higher
| in some area than the complexity of x86 processors.
| jcelerier wrote:
| > I don't think software as an industry really has a "this chip
| isn't fast enough problem".
|
| yet this is what I'm saying to myself every day, even with
| _very_ fast computers available, and _very_ efficient code
| running that hardware pretty much to its limits.
| mhh__ wrote:
| But rendering isn't what makes a modern computer slow. For
| example, Assassin's creed isn't even that well optimized but it
| maxes all threads, uses all the GPU and looks beautiful.
|
| And people have tried "simple" hardware (it ends up being not
| simple) that the programmer (compiler) understands before, it
| doesn't work.
| giantrobot wrote:
| > Look at old game consoles (like a regular old PlayStation)
| and what they were able to render on what today would be
| laughably slow hardware. They could do it because developers
| learned the stack inside and out.
|
| You're oversimplifying the situation and drawing conclusions
| from it. The PSX had dedicated hardware for geometry
| transforms, video decoding, sound processing, and rasterizing.
| The CPU was used for game logic and queuing up the render
| pipeline. So it's not like all PlayStation developers were
| doing black magic in every game, they were using a lot of
| dedicated hardware with well known and relatively modest and
| fixed constraints (NTSC/PAL, stereo audio, and relatively small
| frame buffers).
|
| It's interesting you picked the PSX as your exemplar because
| it's CPU/GPU/MDEC and audio processor were meant to be black
| boxes so developers _didn 't_ have to code to bare metal. The
| IO stack was much shorter and the OS (such as it was) was
| single tasking, single threaded, and didn't have any
| networking.
|
| Slowdowns in modern systems are much more complicated that a
| simplistic "inefficient code makes them slow". There's hundreds
| of small stupid latencies all over the place in modern systems.
| The USB and Bluetooth stacks are filled with little latencies,
| retransmissions, and just wait loops. Unless your inefficient
| code is full of accidentally quadratic loops it's usually
| compounded latencies making systems "feel slow".
| paulryanrogers wrote:
| Consider the philosophy of MAME which plays old games and
| avoids optimizing for GPUs and (IIRC) most specialized graphics
| layers like Direct3D or Metal. As I understand it this makes it
| more portable and easier to maintain, at the cost of some
| performance.
|
| Now MAME's scope is limited to aging games which aren't
| evolving. Only the underlyibg OS's and runtime hardware are
| changing.
|
| Console games pushing aging hardware have a very small variety
| of runtime hardware to optimize for. And optimizations pay off
| in better graphics or features that differentiate. Optimizing
| for ever evolving desktop computers with near infinite hardware
| is a whole different story.
| FunnyLookinHat wrote:
| Should we have a debate as to whether or not Spectre mitigations
| matter for some (or all) desktop computers? I know that,
| theoretically, I could install a piece of software on my Linux
| box that is malware and could try to read my memory via those
| methods, but let's be honest - we're all mostly concerned with
| servers that run code for dozens or hundreds of different
| clients.
|
| I'm a foil hat as much as the next - security is of the utmost
| concern to me, but for once I actually just don't care and would
| take the performance back on my local dev machine.
| thanksforfish wrote:
| Unfortunately "install a piece of software" also includes
| allowing javascript to run in your browser. So the risk may be
| closer to "clicking a link".
|
| https://www.zdnet.com/article/google-this-spectre-proof-of-c...
|
| Additionally, the passwords and keys on your local dev box are
| very valuable for further attacks, like supply chain attacks.
| netr0ute wrote:
| That's what JavaScript blockers like NoScript and uBlock
| Origin are for.
| diegocg wrote:
| Ad blockers can not know if a JavaScript algorithm is
| dangerous or not
| a1369209993 wrote:
| It doesn't matter if it's dangerous or not if it doesn't
| get to run in the first place.
| netr0ute wrote:
| People do, and the JS algorithms will get added to
| adblocker lists in no time.
| reader_mode wrote:
| How long would you have to run JavaScript on your desktop to
| leak sensitive information and has there been any known
| exploits in the wild ?
| mhh__ wrote:
| https://leaky.page/
|
| I don't know about the wild, but if this were tuned (i.e.
| this requires a lot of work for the first byte, the rest
| are easy) for a HVT you wouldn't know.
| ggreer wrote:
| On my laptop's Core i5-10210U with mitigations=off, the
| demo just prints "[!] error: could not infer memory
| layout" until it runs out of retries.
|
| This is on Chromium 91.0.4472.106 and kernel
| 5.12.11-arch1-1. lscpu shows vulnerabilities:
| Itlb multihit: KVM: Mitigation: VMX disabled
| L1tf: Not affected Mds:
| Not affected Meltdown: Not affected
| Spec store bypass: Vulnerable Spectre v1:
| Vulnerable: __user pointer sanitization and usercopy
| barriers only; no swapgs barriers Spectre v2:
| Vulnerable, IBPB: disabled, STIBP: disabled
| Srbds: Mitigation; TSX disabled
| Tsx async abort: Not affected
| magila wrote:
| The problem is that PoC is extracting data which the PoC
| itself created specifically to facilitate said
| extraction. AFAIK no one has created a PoC which can
| extract specific data which hasn't been constructed to
| facilitate the PoC.
| christophilus wrote:
| Yes, but your fans would start spinning like mad. I kill any
| browser that does that. You'd have to execute a successful
| attack within a few seconds to pull it off. I think that's a
| risk I'll take.
| titzer wrote:
| If this is your security mechanism (chuckle), then
| attackers will just slow themselves down by duty cycling.
| Say, only attacking for 100ms at a time, then sleeping a
| second. You'd never know.
| userbinator wrote:
| ...making it even more unlikely the attack would find
| anything of value (or even recognisable as such) in a
| reasonable amount of time.
|
| To use an analogy, these side-channel timing attacks are
| really a "looking for a needle in a haystack" (or
| heap...) situation, except that [1] you don't necessarily
| know what a needle looks like, and [2] the haystack is
| constantly changing. AFAIK all the PoCs shown so far
| relied on having a deep knowledge of the system and
| carefully constructed conditions.
|
| If these attacks could undetectably dump all of your RAM
| in a few seconds, that would definitely be a huge
| concern. But they're more like being able to read a few
| bytes per second, from somewhere in the address space,
| with no idea what they are or where they're being read
| from, and no guarantee that they're even contiguous.
| xrisk wrote:
| I don't think that's a good safety heuristic.
| hjek wrote:
| I agree that it's not good, yet anecdotally I've realized
| that a device has been compromised by running `top`, on
| Windows and on Linux. It's not a good heurestic because
| it's only disvoverable post-compromise.
| jtbayly wrote:
| I've discovered a compromise before because of the fans
| going full speed on a server.
| mhh__ wrote:
| Why would you fans start spinning? You can extract data at
| at least hundreds of MB/s with these exploits, you wouldn't
| know.
| formerly_proven wrote:
| That's the first time I have heard a number this high for
| these exploits. All prior numbers I've heard were many
| orders of magnitude smaller, more like byte/s. The
| article linked above cites 1 kB/s as novel.
| mhh__ wrote:
| That was a number I heard (Meltdown pre-mitigations) when
| the "oh shit" papers started dropping a few years ago,
| could be misremembering. I'm also still slightly
| inebriated so thank you for nerdsniping me (Lit Review
| time!)
| jwif029jf209jf wrote:
| > Yes, but your fans would start spinning like mad. I kill
| any browser that does that.
|
| Good lord, I hope this is satire.
| sp332 wrote:
| I think they mean the browser window/process. I also tend
| to kill off tabs that do this.
| FunnyLookinHat wrote:
| Yeah no disagreement there. I had totally forgotten about the
| JS POC - ugh!
|
| The JavaScript argument is interesting to me in that it's
| already flawed. I suppose I'd rather focus on the security
| issues with browsers running code on my computer more than
| anything else since it's effectively the "but what about ___"
| answer to so many threads like this one.
|
| I've seen a few other comments suggesting per-process rules
| to enable or disable branch protections. That's an
| interesting thought, especially considering you could apply
| it to either "trusted" or "untrusted" code depending on it's
| source.
| fiddlerwoaroof wrote:
| With Arm big.little architectures, it could start making
| sense to have dedicated in-order cores for running
| JavaScript and other "untrusted" code.
|
| Also, I wonder if disabling mitigations on the desktop and
| running the browser in a VM with mitigations enabled would
| be effective.
| saagarjha wrote:
| People want their websites to load fast, though.
| krylon wrote:
| I've never thought about this, but how big are the
| performance penalties for Spectre mitigations vs not having
| Javascript JIT?
|
| (Just to be clear, I'm perfectly happy with the performance
| of my old-ish machine, so I have no motivation to disable
| those mitigations.)
| hjek wrote:
| > Unfortunately "install a piece of software" also includes
| allowing javascript to run in your browser.
|
| Per-process Spectre mitigations could be helpful there, but I
| don't understand the technical details to know whether that
| would be possible to implement. It would be nice to disable
| mitigations on a video editor and for gaming.
| temac wrote:
| Opt-in per-process spectre mitigation is already the case
| for some of them, because the mitigations in question are
| way too costly.
|
| Now it is not possible for every kind of mitigations,
| because e.g. patching the kernel between mitigated
| processes and unmitigated ones would be more costly than
| just always running the mitigations.
|
| edit: thinking more about it: you could have crazy ideas
| like two versions of the whole kernel space always loaded
| :D not sure about the cache impact in this case though.
| pjmlp wrote:
| If gaming implies a MMO, a possible attack vector is
| attacking users to get hold of their gaming account details
| and do as they please.
| usrusr wrote:
| The way I understand it (not that well, admittedly), per-
| process mitigations would be all about keeping that
| process from reading other memory areas, not about
| protecting that process from others. Which is better than
| the reverse if your intention is to allow some processes
| to run random js.
| pjmlp wrote:
| Yeah, but in the context of games, most likely it means
| threaded code written in C or C++.
|
| If anything Spectre has shown us that the only real
| mitigation is to go back to multiprocessing with IPC,
| with the extra hardware resources it entails, as the
| exploit exists regardless of the language for in-process
| memory.
| treis wrote:
| I thought the browsers had put in their own mitigations that
| stop spectre/meltdown attacks.
| eloff wrote:
| They tried. The V8 team eventually gave up and said it was
| unwinnable.
|
| What they did do is move tabs to their own process so they
| can take average of the operating systems protections. Yes
| you can read the memory of the process hosting the
| JavaScript, but now there isn't anything interesting in it.
| Google's security team released a proof of concept attack
| that can read the memory in the renderer in many systems.
| jacquesm wrote:
| average -> advantage
| eloff wrote:
| Man mobile keyboards suck. Any idiot knows the word
| average doesn't work there (at minimum you'd have to
| preface it with the word "the"), so why can't my keyboard
| run an ML model that's not an idiot?
| titzer wrote:
| Mitigations for inter-process side channels address the issue
| of local applications attacking each other. That includes your
| web browser, the JS in it, or any other ad-laden crapware
| attack your local applications, e.g. to steal credit cards, SSH
| keys, etc.
|
| Side-channels are pernicious. In the limit, they give
| applications unfettered read access across protection
| boundaries. If we don't shut them down, we might as well throw
| out the whole UNIX process boundary security model.
|
| Ask yourself, would it be fine if every process had a 4KB/s
| (basically dialup speed) connection to read any desired byte of
| another process's address space?
|
| Of course not. Thus, we need mitigations to shut these channels
| down.
| pjmlp wrote:
| That would be only on the context of shmem, right?
|
| I would assume other IPC mechanisms are safe from it.
| msbarnett wrote:
| You would assume incorrectly.
| pjmlp wrote:
| How would Spectre exploit UNIX message boxes then?
| msbarnett wrote:
| _Multiple_ Spectre variants (RDCL, RSRR, Lazy FP state
| restore, SpectreRSB) bypass process boundaries. It
| doesn't matter what IPC mechanism you use, they can read
| arbitrary privileged memory no matter who owns it.
|
| IPC really has nothing to do with anything, Spectre-wise;
| you don't have to be using any IPC mechanism in either
| the attacker or attackee process to be vulnerable to
| these variants.
| jfrunyon wrote:
| > 4KB/s (basically dialup speed)
|
| I guess if "basically" means "takes 10x longer"?
| rcthompson wrote:
| 32 kb/s is on the same order of magnitude as dial-up (56
| kb/s), not 10x slower.
|
| (I don't know if dial-up is still 56 kb/s these days, but
| that's the speed historically associated with the term.)
| userbinator wrote:
| _address the issue of local applications attacking each
| other._
|
| IMHO it's stupid to even try to isolate processes to that
| extent, as it's a really deep rabbithole that'll lead to
| worse performance and dubious increases in actual security.
| The best defense is to simply make everything running on the
| system be trusted.
|
| Process protection boundaries should be for protection
| against accidental cross-process corruption, a form of
| reliability, and nothing more. That's effectively what the
| early 286/386 documentation stated, so Intel never even
| intended these protections to be defenses against side-
| channels in the first place.
|
| Of course, the "security industry" needs to keep creating
| paranoia-fuel to justify their existence...
| DSingularity wrote:
| If users are still unable to recognize when they are doing
| something security sensitive then how can we remove all
| safeguards?
| mhh__ wrote:
| The issue is that virtual machines could be very easy targets
| if there weren't mitigations (It's much more complicated than
| that but that's the idea)
| mistrial9 wrote:
| yes, I am interested in this.. basically I have mitigations OFF
| and also, do not run a web browser on the base OS.
| (Debian/Ubuntu here) in VMs I do run the browser, with two or
| three in use daily..
___________________________________________________________________
(page generated 2021-06-19 23:00 UTC)