Linus rejects 'beyond stupid' AWS-made Linux patch | Hacker News Reader

Linus rejects 'beyond stupid' AWS-made Linux patch

zdnet.com

45 pointsjonbaer33 comments

Here's the actual message from Linus (and the responses from the developer as well): https://lore.kernel.org/lkml/CAHk-=wgXf_wQ9zrJKv2Hy4EpEbLuqt...

That thread shows a decent back-and-forth discussion about the merits of the patch compared to the clickbait title of the article here.

The dude is prickly but so many software people of the same era were(are?) like that.

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.

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.

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.

Seemed pretty tame to me.

...for Linus anyway heh.

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.

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.

Reply on news.ycombinator.com