At first glance, the Xbox CPU doesn't really resemble Cell, but if you just compare Cell's PPE to one of Xenon's three cores the similarity is striking: Xenon, Cell
The CPUID instruction provides feature bits that software should use to determine which instructions are available. Using the vendor string is not a reasonable way of detecting the presence/absence of instruction set extensions like SSE.
That die isn't particularly small - 1mm by 1mm. Plenty of existing chips have dies that size, but they're just packaged in larger packages to space out the pins. This picture shows a die (about 3mm*3mm) and the remains of its package so you have an idea of how small a die can be, even in a large package.
Second, doing shit like this only makes it worse. If there really was any concern over privacy then this is by far the worst thing you could do to protect it.
They probably realize that this will attract some attention to the images, but how else would you propose they ensure that this doesn't happen again? Just submitting a request to Google to remove the picture won't help when Microsoft and Yahoo! send their camera vehicles down that private road in the future.
That doesn't solve the problem. Also from the fucking comments:
> For this case, there is a public way of doing what we needed to do, and it works well.
It actually doesn't work all that well because all our embedders (Prism, Songbird, etc) have to add this option to their plists. If they forget, they'll just mysteriously get crappy performance.
Firefox runs into the same problem that caused WebKit to use the undocumented API. Anybody embedding it will get crappy performance unless they add the option to their plists.
A 6T SRAM cell consists of two cross-coupled inverters, and an access NMOS transistor on each side to connect the state nodes to bitlines. Writing is done by charging one bitline, and discharging the other. The devices should be sized such that the drive strengths allow the values on the bitlines to overwrite the values on the state nodes (i.e. win the drive fight). When you do a read, both bitlines are precharged, then the state nodes are connected to the bitlines by turning on the access transistors.
Now, when a read is happening, looking at the side of the bit cell that's holding, we see the bitline (at VDD), the access transistor which is on and looks like a resistor, the state node (initially at ground), and the pulldown transistor of the inverter which looks like a resistor connected to ground. This looks a lot like a voltage divider, and the state node will rise above ground. If it rises high enough, it could cause the bit cell to flip, corrupting its value. This is called a "read stability" problem, and for various reasons read stability tends to be a bigger problem at low operating voltages.
An 8T cell eliminates the read stability issue. It looks exactly the same as a 6T cell when it comes to writes, but reads occur on a separate bitline with a separate wordline. You add one transistor going between ground and a new node "foo", gated by the word line, and another transistor going between node "foo" and the read bitline, gated by one of the state nodes. A read no longer has any effect on the state node*, and won't corrupt the cell. You can see a schematic here (the right side - their "hit" signal would be the read wordline, and wl_ram would be the write wordline.
*ignoring Miller cap and other higher-order effects
TFA isn't very techincal, and makes it sound like the MIT team isn't doing anything very interesting (they mention 8-transistor SRAM cells, but even regular CPUs sometimes have to use them). The interesting story here is that the chip is being operated at a voltage below the voltage where the transistors are normally viewed as being "on". In this region, transistors operate more like amplifiers than digital switches.
One cool thing about this is that the leakage power will be negligible. Leakage currents are generally exponential with respect to voltage.
Another cool thing is that the chip can actually operate at the low voltage. It's not too hard to make a chip retain state at very low voltages, but as soon as you want to do anything you usually have to raise the voltage back up before execution resumes. Any task that requires a small amount of work frequently will benefit from something like this. A contrived example of where this make a big difference is in a poorly-architected MP3 player in which the CPU has to shuffle a few thousand bytes per second to a sound chip, but in very small chunks (this poorly-architected sound chip has a very tiny buffer), hundreds of times per second. A normal chip would be constantly jumping to a high voltage and going back to sleep; depending on how long the voltage transition takes, it might have to stay in a higher voltage state constantly. This chip, on the other hand, could operate continuously at the "sleeping" voltage.
The catch is that transistors operating in the subthreshold regime are going to be pretty slow, so for any tasks that require high performance you'll have to bump the voltage back to a more normal range.
The problem is that Intel is "competing" by dumping their product below cost. I think the fear is that they will take over the market because of that, and when the OLPC project subsequently dies, drop out of that market because it's low margin... leaving kids with no options. It's not like they have a reputation for playing fair.
A lot of people seem to be complaining about this being useless because it only affects your own future search results, and for terms you've already searched. Who says it'll always be that way, though? Wouldn't it make more sense that this is a test to see how many people would take advantage of such a feature, and whether they agree with each other (or can be classified into people who are looking for footwear vs. people having trouble with lilo), and whether they do a good job of rewarding really useful sites over SEO masters like expertsexchange?
People are also arguing that spammers will make this useless. I have to wonder, though - given that Google has so many real address books and so many e-mails, shouldn't it be possible for them to quickly find the real humans and use that information to build a "web of trust" system for filtering out spammers? After all, ratings are tied to gmail accounts...
What you still don't seem to get is that these are DIFFERENT projects. Do you call Ford when your petrol has water in it? Do you expect the roadservices department to fix your car?
No, but you call Ford whether it's the wheels or the engine or the indicator or the radio.
The other problem: you use "Linux". You don't use "Gnome/Firefox/CUPS/Xorg/Ubuntu/GNU/Linux". Even if Linux advocates were advocating "GNU/Linux", it's B.S. to say, "Oh, CUPS doesn't support your printer - it's not GNU/Linux's fault", when users of normal operating systems think of Windows-like situations where Windows handles video card drivers, printer drivers, window management, print-job management, etc. If you advocate "Linux" as an alternative to "Windows", don't be surprised when people complain that "Linux" doesn't handle something well.
I am a carpenter, I ask you if you want anything fixed, you ask that I fix the faulty washing machine. Do you then rant that I won't fix it? That you don't care about the differences between an electricien[sic] and a carpenter?
If someone recommended replacing my current jack-of-all-trades handyman with you, then of course I would complain when you can't fix something the previous handyman could.
The demo video somebody else linked to looks interesting, but it's easy to synthesize a good "top-down" view from side views when you're on an empty parking lot (i.e. flat surface). It would have to look strange to see a side view of the car next to you munged to appear as top-down though...
Unless that hypervisor is burned into a non-rewritable form of storage (e.g. ROM), it will be subverted.
As it has been demonstrated at Black Hat by the illustrious Ms. Rutowska, (as well as being fairly obvious to anyone familiar with hypervisors) a hypervisor is below the OS and can be impervious to the OS's probing, but it still lies between the OS and the hardware.
I think trusted computing takes care of that for you. The Trusted Platform Module will give you a cryptographic hash of all running software; if any level of the software stack has been replaced, the signature won't match.
You don't invest hours into getting your cup of icecream, but you do invest hours into downloading, installing, and setting up (downloading other applications, binary drivers, etc) your OS. If you get a flavor of ice cream you don't like, you lost maybe 15 minutes of enjoyment. If you get a distro you don't like, it's much worse - particularly if you aren't savvy enough to easily transfer your files to a new distro.
People have also spent years eating and learning what flavors they like. A user is unlikely to know whether he'd prefer gnome or kde, or apt/deb or rpm, or ext3 or reiser.
Given the difference between a choice made with good information, and small consequences versus no information and large consequences, your comparison is garbage.
I've played around with linux for years, but never thought it was really any good for the desktop. It was an interesting toy to experiment with, and was good for setting up servers on older hardware without paying for an OS, but the desktop usability just wasn't there - I always eventually had to use the command line for something, or had driver issues (e.g. static from the sound card, poor support for my graphics card, etc) or just couldn't find a good equivalent of a Windows application. I built a new PC last month, and put Ubuntu on it until I had time to pick up another copy of Windows; I was pleasantly surprised. I ended up transferring all my data over, and am not currently planning to install Windows on it (barring some killer game...but I don't game much nowadays).
After downloading the nvidia driver (which was no more difficult than getting a new driver for XP), everything Just Worked. In some cases, things worked better than on Windows (TVTime is much nicer than Hauppauge's own TV application; gaim on linux works better than on Windows). I really like the way higher-privilege things work: the screen dims and you get a password dialog. The ease of installation and initial setup was nice - I'll get back to this in a moment.
Now, last week, my mom bought a new HP laptop, which had Vista on it. After taking care of the first-boot setup (setting the language, time zone, user name) and logging in, there were FIVE windows open, asking me to do different things (set up wireless or sign up for one of the 50 ISPs that were being advertised, download updates for the HP software / take a tour of the OS, register with MS, register with HP, etc. etc. etc). It made me wonder whether any human at HP had actually tried using one of their machines, or if they just took bids for crapware and installed everything they could. It took me long enough to deal with all the crap; it would have taken my mom forever.
Vista's UAC is similar to the graphical sudo in linux, but it's not done as well. In Ubuntu, opening the add/remove software control panel requires authentication, and then you can add and remove as much software as you'd like. With this new Vista machine, each time you install an update or uninstall a program, you're prompted by UAC. That gets annoying fast when the machine is full of garbage (Norton trial software, Office 2007 60-day trial, ~30 WildTangent games (uninstalling them required clicking 30 checkboxes!), Vongo, a bunch of HP bloatware apps....)
Over all, getting the Ubuntu machine to a level where what I needed was there and I wasn't being constantly harassed by garbage pre-installed software was much easier than getting the Vista machine to a pleasant state. There will be a pretty large learning curve with Vista (for one thing, Office 2000 no longer works; it might be easier for someone to switch to OpenOffice than to Office 2007) - for some people, switching to Linux might be an easier move.
microcodes are stored in ROM, they're only ever stored in RAM EEPROM or Flash on development hardware, i.e. not a personal computer processor.
There is a ROM that contains microcode, but there is also a RAM that is used to hold patches. This patent describes how some AMD processors load patches into a small RAM (scroll down to "BACKGROUND OF THE INVENTION" for the human-readable explanation).
Furthermore SRAM is volatile memory, so could not be used for this purpose.
The BIOS usually applies microcode patches at every boot. From patents and BIOS reverse-engineering, people have even figured out how to load their own patches. In this instance, it looks like MS is going to have Windows apply a microcode patch (which makes sense if you think about it - BIOS updates are a pain and very few people actually take advantage of them, but Windows Update can distribute this kind of thing to 95% of computers, and the OS can apply them at boot time).
As petermgreen mentioned, I explained that flash also has problems. Flash memory uses transistors with two gates, one of which is floating; they requires special steps during the manufacturing process.
Just be glad they were smart enough to use such a system where the processor can be updated while running and temporarily, allowing you to revert back to its purchased state.
It's actually easier to just use an SRAM to hold microcode patches than to incorporate flash memory or other non-volatile reprogrammable storage on the die. Flash requires a special type of transistor, and fuses generally can't be unblown once they're blown (meaning you'd be very limited in how many patches you could ever apply to a given chip).
A few years ago, I wanted Mozilla to be able to play a sound when a download completes. I got on IRC and asked for help, and a couple very patient developers helped me understand where the code was that needed to be patched, and how to fix the issue. As I found other things that were missing, or things I didn't like, I wrote more and more patches, each time with less help - probably 99% of the lines of code in my early patches were written over IRC by more experienced devs, and pasted into a text editor by me:-).
I started taking on code-cleanup-type bugs, and eventually, as I became more familiar with the codebase, morevisiblebugs (and even ones that didn't affect me personally). I've fixed quite a few bugs now, and have quite a bit of responsibility.
I don't know how well it'll go if you don't have a vested interest in your contributions - it's incredibly difficult to get into a huge codebase like Mozilla. I had written programs of up to a few thousand lines of code before, but working in a multi-million-line project is very different. Start with small changes, and don't feel bad when your patches have to go through many revisions before being accepted.
The vast majority of the open source/hobbyist made Firefox extensions - those that are hosted at https://addons.mozilla.org/ - are not vulnerable to this attack. Users of popular Firefox extensions such as NoScript, Greasemonkey, and AdBlock Plus have nothing to worry about.
Since it's not mentioned in the summary, it's important to reiterate that this takes advantage of non-secure update mechanisms used by some addons. The addons.mozilla.org site will only host extensions that update from addons.mozilla.org through the built-in mechanism, which is not vulnerable to this attack. This is an extension-specific issue, and would most likely apply to any sort of addon for any software that doesn't verify security certificates.
Is it not built in in Firefox? SeaMonkey has that functionality Edit->Preferences, Advanced->Scripts & Plugins, uncheck "Disable or replace context menus".
Slashdot Mirror
At first glance, the Xbox CPU doesn't really resemble Cell, but if you just compare Cell's PPE to one of Xenon's three cores the similarity is striking: Xenon, Cell
The CPUID instruction provides feature bits that software should use to determine which instructions are available. Using the vendor string is not a reasonable way of detecting the presence/absence of instruction set extensions like SSE.
That die isn't particularly small - 1mm by 1mm. Plenty of existing chips have dies that size, but they're just packaged in larger packages to space out the pins. This picture shows a die (about 3mm*3mm) and the remains of its package so you have an idea of how small a die can be, even in a large package.
Second, doing shit like this only makes it worse. If there really was any concern over privacy then this is by far the worst thing you could do to protect it.
They probably realize that this will attract some attention to the images, but how else would you propose they ensure that this doesn't happen again? Just submitting a request to Google to remove the picture won't help when Microsoft and Yahoo! send their camera vehicles down that private road in the future.
That doesn't solve the problem. Also from the fucking comments:
> For this case, there is a public way of doing what we needed to do, and it works well.
It actually doesn't work all that well because all our embedders (Prism, Songbird, etc) have to add this option to their plists. If they forget, they'll just mysteriously get crappy performance.
Firefox runs into the same problem that caused WebKit to use the undocumented API. Anybody embedding it will get crappy performance unless they add the option to their plists.
A 6T SRAM cell consists of two cross-coupled inverters, and an access NMOS transistor on each side to connect the state nodes to bitlines. Writing is done by charging one bitline, and discharging the other. The devices should be sized such that the drive strengths allow the values on the bitlines to overwrite the values on the state nodes (i.e. win the drive fight). When you do a read, both bitlines are precharged, then the state nodes are connected to the bitlines by turning on the access transistors.
Now, when a read is happening, looking at the side of the bit cell that's holding, we see the bitline (at VDD), the access transistor which is on and looks like a resistor, the state node (initially at ground), and the pulldown transistor of the inverter which looks like a resistor connected to ground. This looks a lot like a voltage divider, and the state node will rise above ground. If it rises high enough, it could cause the bit cell to flip, corrupting its value. This is called a "read stability" problem, and for various reasons read stability tends to be a bigger problem at low operating voltages.
An 8T cell eliminates the read stability issue. It looks exactly the same as a 6T cell when it comes to writes, but reads occur on a separate bitline with a separate wordline. You add one transistor going between ground and a new node "foo", gated by the word line, and another transistor going between node "foo" and the read bitline, gated by one of the state nodes. A read no longer has any effect on the state node*, and won't corrupt the cell. You can see a schematic here (the right side - their "hit" signal would be the read wordline, and wl_ram would be the write wordline.
*ignoring Miller cap and other higher-order effects
TFA isn't very techincal, and makes it sound like the MIT team isn't doing anything very interesting (they mention 8-transistor SRAM cells, but even regular CPUs sometimes have to use them). The interesting story here is that the chip is being operated at a voltage below the voltage where the transistors are normally viewed as being "on". In this region, transistors operate more like amplifiers than digital switches.
One cool thing about this is that the leakage power will be negligible. Leakage currents are generally exponential with respect to voltage.
Another cool thing is that the chip can actually operate at the low voltage. It's not too hard to make a chip retain state at very low voltages, but as soon as you want to do anything you usually have to raise the voltage back up before execution resumes. Any task that requires a small amount of work frequently will benefit from something like this. A contrived example of where this make a big difference is in a poorly-architected MP3 player in which the CPU has to shuffle a few thousand bytes per second to a sound chip, but in very small chunks (this poorly-architected sound chip has a very tiny buffer), hundreds of times per second. A normal chip would be constantly jumping to a high voltage and going back to sleep; depending on how long the voltage transition takes, it might have to stay in a higher voltage state constantly. This chip, on the other hand, could operate continuously at the "sleeping" voltage.
The catch is that transistors operating in the subthreshold regime are going to be pretty slow, so for any tasks that require high performance you'll have to bump the voltage back to a more normal range.
The problem is that Intel is "competing" by dumping their product below cost. I think the fear is that they will take over the market because of that, and when the OLPC project subsequently dies, drop out of that market because it's low margin... leaving kids with no options. It's not like they have a reputation for playing fair.
A lot of people seem to be complaining about this being useless because it only affects your own future search results, and for terms you've already searched. Who says it'll always be that way, though? Wouldn't it make more sense that this is a test to see how many people would take advantage of such a feature, and whether they agree with each other (or can be classified into people who are looking for footwear vs. people having trouble with lilo), and whether they do a good job of rewarding really useful sites over SEO masters like expertsexchange?
People are also arguing that spammers will make this useless. I have to wonder, though - given that Google has so many real address books and so many e-mails, shouldn't it be possible for them to quickly find the real humans and use that information to build a "web of trust" system for filtering out spammers? After all, ratings are tied to gmail accounts...
Oh, please. That's nowhere near as fun as bitching on random websites.
Yeah, if he actually filed usable bugs, they'd get fixed, and then he'd have nothing to whine about any more.
What you still don't seem to get is that these are DIFFERENT projects. Do you call Ford when your petrol has water in it? Do you expect the roadservices department to fix your car?
No, but you call Ford whether it's the wheels or the engine or the indicator or the radio.
The other problem: you use "Linux". You don't use "Gnome/Firefox/CUPS/Xorg/Ubuntu/GNU/Linux". Even if Linux advocates were advocating "GNU/Linux", it's B.S. to say, "Oh, CUPS doesn't support your printer - it's not GNU/Linux's fault", when users of normal operating systems think of Windows-like situations where Windows handles video card drivers, printer drivers, window management, print-job management, etc. If you advocate "Linux" as an alternative to "Windows", don't be surprised when people complain that "Linux" doesn't handle something well.
I am a carpenter, I ask you if you want anything fixed, you ask that I fix the faulty washing machine. Do you then rant that I won't fix it? That you don't care about the differences between an electricien[sic] and a carpenter?
If someone recommended replacing my current jack-of-all-trades handyman with you, then of course I would complain when you can't fix something the previous handyman could.
Cool, that didn't look bad at all.
The demo video somebody else linked to looks interesting, but it's easy to synthesize a good "top-down" view from side views when you're on an empty parking lot (i.e. flat surface). It would have to look strange to see a side view of the car next to you munged to appear as top-down though...
Unless that hypervisor is burned into a non-rewritable form of storage (e.g. ROM), it will be subverted.
As it has been demonstrated at Black Hat by the illustrious Ms. Rutowska, (as well as being fairly obvious to anyone familiar with hypervisors) a hypervisor is below the OS and can be impervious to the OS's probing, but it still lies between the OS and the hardware.
I think trusted computing takes care of that for you. The Trusted Platform Module will give you a cryptographic hash of all running software; if any level of the software stack has been replaced, the signature won't match.
Sure, but to get a decent idea you'd have to spend a day or two using each of the popular distros. How many non-geeks really want to do that?
You don't invest hours into getting your cup of icecream, but you do invest hours into downloading, installing, and setting up (downloading other applications, binary drivers, etc) your OS. If you get a flavor of ice cream you don't like, you lost maybe 15 minutes of enjoyment. If you get a distro you don't like, it's much worse - particularly if you aren't savvy enough to easily transfer your files to a new distro.
People have also spent years eating and learning what flavors they like. A user is unlikely to know whether he'd prefer gnome or kde, or apt/deb or rpm, or ext3 or reiser.
Given the difference between a choice made with good information, and small consequences versus no information and large consequences, your comparison is garbage.
I've played around with linux for years, but never thought it was really any good for the desktop. It was an interesting toy to experiment with, and was good for setting up servers on older hardware without paying for an OS, but the desktop usability just wasn't there - I always eventually had to use the command line for something, or had driver issues (e.g. static from the sound card, poor support for my graphics card, etc) or just couldn't find a good equivalent of a Windows application. I built a new PC last month, and put Ubuntu on it until I had time to pick up another copy of Windows; I was pleasantly surprised. I ended up transferring all my data over, and am not currently planning to install Windows on it (barring some killer game...but I don't game much nowadays).
After downloading the nvidia driver (which was no more difficult than getting a new driver for XP), everything Just Worked. In some cases, things worked better than on Windows (TVTime is much nicer than Hauppauge's own TV application; gaim on linux works better than on Windows). I really like the way higher-privilege things work: the screen dims and you get a password dialog. The ease of installation and initial setup was nice - I'll get back to this in a moment.
Now, last week, my mom bought a new HP laptop, which had Vista on it. After taking care of the first-boot setup (setting the language, time zone, user name) and logging in, there were FIVE windows open, asking me to do different things (set up wireless or sign up for one of the 50 ISPs that were being advertised, download updates for the HP software / take a tour of the OS, register with MS, register with HP, etc. etc. etc). It made me wonder whether any human at HP had actually tried using one of their machines, or if they just took bids for crapware and installed everything they could. It took me long enough to deal with all the crap; it would have taken my mom forever.
Vista's UAC is similar to the graphical sudo in linux, but it's not done as well. In Ubuntu, opening the add/remove software control panel requires authentication, and then you can add and remove as much software as you'd like. With this new Vista machine, each time you install an update or uninstall a program, you're prompted by UAC. That gets annoying fast when the machine is full of garbage (Norton trial software, Office 2007 60-day trial, ~30 WildTangent games (uninstalling them required clicking 30 checkboxes!), Vongo, a bunch of HP bloatware apps....)
Over all, getting the Ubuntu machine to a level where what I needed was there and I wasn't being constantly harassed by garbage pre-installed software was much easier than getting the Vista machine to a pleasant state. There will be a pretty large learning curve with Vista (for one thing, Office 2000 no longer works; it might be easier for someone to switch to OpenOffice than to Office 2007) - for some people, switching to Linux might be an easier move.
microcodes are stored in ROM, they're only ever stored in RAM EEPROM or Flash on development hardware, i.e. not a personal computer processor.
There is a ROM that contains microcode, but there is also a RAM that is used to hold patches. This patent describes how some AMD processors load patches into a small RAM (scroll down to "BACKGROUND OF THE INVENTION" for the human-readable explanation).
Furthermore SRAM is volatile memory, so could not be used for this purpose.
The BIOS usually applies microcode patches at every boot. From patents and BIOS reverse-engineering, people have even figured out how to load their own patches. In this instance, it looks like MS is going to have Windows apply a microcode patch (which makes sense if you think about it - BIOS updates are a pain and very few people actually take advantage of them, but Windows Update can distribute this kind of thing to 95% of computers, and the OS can apply them at boot time).
As petermgreen mentioned, I explained that flash also has problems. Flash memory uses transistors with two gates, one of which is floating; they requires special steps during the manufacturing process.
Just be glad they were smart enough to use such a system where the processor can be updated while running and temporarily, allowing you to revert back to its purchased state.
It's actually easier to just use an SRAM to hold microcode patches than to incorporate flash memory or other non-volatile reprogrammable storage on the die. Flash requires a special type of transistor, and fuses generally can't be unblown once they're blown (meaning you'd be very limited in how many patches you could ever apply to a given chip).
One problem with Flash (in my opinion) is that there is no full open-source implementation.
;-)
Who needs flash? JavaScript is awesome if you don't mind 2 orders of magnitude performance penalties
A few years ago, I wanted Mozilla to be able to play a sound when a download completes. I got on IRC and asked for help, and a couple very patient developers helped me understand where the code was that needed to be patched, and how to fix the issue. As I found other things that were missing, or things I didn't like, I wrote more and more patches, each time with less help - probably 99% of the lines of code in my early patches were written over IRC by more experienced devs, and pasted into a text editor by me :-).
I started taking on code-cleanup-type bugs, and eventually, as I became more familiar with the codebase, more visible bugs (and even ones that didn't affect me personally). I've fixed quite a few bugs now, and have quite a bit of responsibility.
I don't know how well it'll go if you don't have a vested interest in your contributions - it's incredibly difficult to get into a huge codebase like Mozilla. I had written programs of up to a few thousand lines of code before, but working in a multi-million-line project is very different. Start with small changes, and don't feel bad when your patches have to go through many revisions before being accepted.
The vast majority of the open source/hobbyist made Firefox extensions - those that are hosted at https://addons.mozilla.org/ - are not vulnerable to this attack. Users of popular Firefox extensions such as NoScript, Greasemonkey, and AdBlock Plus have nothing to worry about.
Since it's not mentioned in the summary, it's important to reiterate that this takes advantage of non-secure update mechanisms used by some addons. The addons.mozilla.org site will only host extensions that update from addons.mozilla.org through the built-in mechanism, which is not vulnerable to this attack. This is an extension-specific issue, and would most likely apply to any sort of addon for any software that doesn't verify security certificates.
You can't see banding in 24-bit? I sure can.
Is it not built in in Firefox? SeaMonkey has that functionality Edit->Preferences, Advanced->Scripts & Plugins, uncheck "Disable or replace context menus".