35 comments

[ 5.1 ms ] story [ 85.3 ms ] thread
If an attacker can indeed just observe cache changes from a sibling core, what is the purpose of the patch indeed?
AWS has non-virtualized "metal" instances as well. Customer may be be running container workloads on those instances with SMT disabled.
As a DBA, I feel that AWS has a conflict-of-interest in making PRs that decrease performance, then telling me, "Just pay for a bigger instance."

Luckily, database instances are a small percentage of a fleet, but even so, they're also usually the most expensive ones.

(Meltdown and Spectre had a huge impact on databases near the limits of their existing instance size, unexpectedly tipping them over into the next tier and doubling the cost.)

The cloud industry as a whole might have that conflict of interest. But AWS itself is a single player in a really quite competetive industry. Configuring their kernels to be deliberately slow would be a clear disadvantage vs. Google and Microsoft et. al.
Obviously I can't say for certain Amazon has an agenda here but I could see how this would benefit them.

[puts on additional tin foil hat]

I don't think Amazon would be targeting the big players like Google and MS. All of them can easily afford to take the loss. But this could affect the smaller VM providers (DO, Linode, Upserve, etc.) with less capital. Losing even just a few percentage points of CPU performance would cut into already thin margins. If there is a conspiracy here, I think they would be targeting the smaller players in the industry.

If one's not careful, they may end up using so many of these services that the idea of switching to a better cloud provider is academic.

Athena • CloudSearch • Elasticsearch Service • EMR • Kinesis • Redshift • Quicksight • Data Pipeline • Glue • Lake Formation • Data Exchange • EventBridge • Step Functions • Simple Queue Service • Simple Notification Service • MQ • AppSync • Sumerian • Managed Blockchain • Quantum Ledger Database • Alexa for Business • Chime • WorkMail • WorkDocs • Connect • Pinpoint • EC2 • Elastic Container Service • Elastic Kubernetes Service • Elastic Container Registry • Lightsail • Batch • Elastic Beanstalk • Fargate • Lambda • Serverless Application Repository • VMware Cloud • Outposts • Wavelength • WorkSpaces • AppStream 2.0 • WorkLink • GameLift • Lumberyard • Aurora • RDS • DynamoDB • ElastiCache • Neptune • DocumentDB • CodeStar • CodeCommit • CodeBuild • CodeDeploy • CodePipeline • Cloud9 • X-Ray • Command Line Interface • Corretto • IoT Core • FreeRTOS • Greengrass • IoT 1-Click • IoT Analytics • IoT Button • IoT Device Defender • IoT Device Management • Partner Device Catalog • SageMaker • Comprehend • Lex • Polly • Rekognition • Translate • Transcribe • DeepLens • Deep Learning AMIs • Apache MXNet • TensorFlow • Elastic Inference • SageMaker Ground Truth • Deep Learning Containers • Augmented AI • CloudWatch • Auto Scaling • CloudFormation • CloudTrail • OpsWorks • Service Catalog • Systems Manager • Trusted Advisor • Personal Health Dashboard • Control Tower • License Manager • Well-Architected Tool • Console Mobile Application • Management Console • Managed Services • Organizations • Compute Optimizer • Elastic Transcoder • Kinesis Video Streams • Elemental MediaConvert • Elemental MediaLive • Elemental MediaPackage • Elemental MediaStore • Elemental MediaTailor • Elemental MediaConnect • CloudEndure Migration • Application Discovery Service • Migration Hub • Server Migration Service • Snow Family • DataSync • Transfer for SFTP • Amplify • API Gateway • Device Farm • VPC • PrivateLink • CloudFront • Route 53 • Direct Connect • Cloud Map • App Mesh • Transit Gateway • Global Accelerator • Elastic Load Balancing • RoboMaker • Resource Access Manager • Identity & Access Management • Cloud Directory • Cognito • Single Sign-On • GuardDuty • Inspector • Macie • Certificate Manager • CloudHSM • Directory Service • Firewall Manager • Key Management Service • Secrets Manager • Shield • WAF • Artifact • Simple Storage Service • Elastic File System • S3 Glacier • Storage Gateway • Snow Family • FSx for Windows File Server • Backup

> The cloud industry as a whole might have that conflict of interest.

IaaS providers (and maybe PaaS providers) have that conflict of interest. SaaS providers certainly don't. If the customer only pays for actions performed, you have an incentive to do it with as little resources as possible.

Disclosure: I work in the internal cloud unit of a company offering SaaS.

I don’t think that’s the reasonable conclusion when there’s a more obvious one. AWS has a different agenda in that they don’t directly bear the cost of these security reinforcements directly (as they are passed along to customers in the form of reduced “capacity” on all Linux machines everywhere) but they directly benefit (directly via the ability to use shared tenancy, and directly by having customers more willing to use shared tenancy solutions).

It is also very much in their favor for “slower execution” to not be under the AWS column in a Pros and Cons list stacked against an on-prem alternative, which would be the case if it’s a patch they’re using (forced to use by nature of renting out shared tenancy to potential attackers) that on-prem configurations wouldn’t be.

While I don't disagree with the conclusion, I really wish he would not fly off the handle like this all the time. I seem to recall that he promised to stop this sort of behavior.
(comment deleted)
His tone is perfectly OK, he isn't attacking anybody and simply expresses what he thinks is wrong with the patch.

In addition he also ends with:

  I'm more than happy to be educated on why I'm wrong, but for now I'm unpulling it for lack of data.
I see nothing wrong with his reply, he's making his points without insulting anyone and is very composed compared to some reactions he had in the past.
I wish people would stop mischaracterizing statements to push an agenda. Nowhere did he "fly off the handle". If you are so sensitive that his statement felt that harsh, perhaps the internet is not the place for you. Or toughen up for pete's sake.
This is such an awful, hyperbolic reaction to the parent post, it's disheartening to see it on HN. Maybe the parent post is overstating - but "perhaps the internet is not the place for you"? "If you are so sensitive?" "Toughen up"? "push an agenda"?? Honestly: Holy shit.
This article is not newsworthy because Linus commented on some submission but because of the way he commented.

Oh, I'm _soo_ special and pretty and such a delicate flower, that I want to flush the L1D on every task switch

I'll flush the L1 at context switch" is beyond stupid.

Those are not the words of a wisened leader attempting to explain why allowing user space cache eviction is probably not a great idea but some flippant jerk attempting bully his viewpoint by calling other ideas and by proxy submitters stupid.

Linus himself has recognized this behavior is inappropriate and pledged to "get help"

https://www.theregister.com/2018/09/17/linus_torvalds_linux_...

I certainly respect his accomplishments, but just as certainly I don't condone his behavior. Further I feel his rants tell other savants that acting like jerks is perfectly acceptable and just part of open source contributions.

I always find his defenders to be a puzzle. So many believe and champion the cause of open source yet also condone and champion behavior that drives contributors away. As a champion of open source you should want to cultivate more contributors but our community is filled with those that emulate his unacceptable behavior.

Your comment instructing me to toughen up perfectly illustrates why his behavior is contagiously inappropriate. Thanks

It’s hyperbole. He didn’t attack anyone by name. He definitely wasn’t singling you (or any other HN reader) out. It’s fine.
FWIW, if I wrote this patch and worked at AWS, I might not want to go to work the next day.

While it’s not as bad as other criticisms, there is still plenty of room for improvement to establish a more professional work environment.

Looks like a case of looking for things to be offended by to me. I also should remind you Linus is head of a opensource project not a corporate division so he has no need to act "professional" at all.
If I wrote this patch and worked at AWS, I probably wrote it because some manager asked me to. I probably have realized already that the idea is kind of shady, but my manager doesn't care, so I go forward towards the inevitable rejection by Linus.
Luckily, Linus is independently wealthy and doesn't need to play the corporate politics. I personally think his response is perfectly fine and may seem "too much" only by the distorted corporate standards.
He is nowhere near flying off the handle here. You should take a step back and reexamine how you view communication from others and where you set expectations of thought process and culture matching your own.
Any code review that included the argument:

"Oh, I'm _soo_ special and pretty and such a delicate flower, that I want to flush the L1D on every task switch"

Is completely inappropriate. If you feel like that is somehow appropriate in a review then it is you who need to "step back and reexamine how you view communication from others and where you set expectations of thought process and culture matching your own".

I'd rather work with someone who makes good (or even bad) jokes about my code in reviews than a humorless bore who spends all their time policing everyone's appropriateness according to his own stodgy cultural standards.
Why not neither? Why not a person within the normal range of emotional intelligence, rather than either a humorless policer or an antagonistic smart person? Why are you defending his tone with such hostility?
The belief that one can or should judge another person (ie, on the normalness of their emotional intelligence) is quite boring, and is particularly annoying in coworkers. It is by definition fun to work with people who joke around, if one starts with thick skin, an open mind, and the confidence to occasionally be the butt of the joke.
The main problem here is he jumps to a bunch of wrong conclusions and aggravates that with his tone.

And even after being shown an excessive amount of deference (even when he is wrong) he only tacitly admits his mistake and he's still grumbling about and focusing on the areas he still disagrees with.

If he admitted he was wrong with the same tone he concluded he was right, there wouldn't be an issue.

It's the one sided nature of his communication that's unhelpful.

Article ends with "Herrenschmidt said the patches aren't trying to solve problems happening inside of a customer VM running SMT and nor are they about protecting VMs against other VMs on the same system."

Well then what the fuck IS it for?

AWS has non-virtualized "metal" instances as well. Customer may be be running container workloads on those instances with SMT disabled.
If it's not a VM you dont need to worry about the cache.
To protect processes from snooping by other processes on the same core with disabled SMT.