-
Notifications
You must be signed in to change notification settings - Fork 467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create CryptographicHardwareIntrinsicsAnalyzer.cs #4005
Conversation
Tagging @dotpaul as this is a security rule. |
Thank you @Youssef1313 ! Edit: Oh, I see you already did that. 😄 |
|
||
compilationStartContext.RegisterOperationAction( | ||
context => AnalyzeObjectCreation(context, tooGenericExceptionSymbols, reservedExceptionSymbols), | ||
OperationKind.ObjectCreation); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I use OperationKind.Invocation
here instead? I'm unsure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. System.Runtime.Intrinsics.X86.Aes
looks like a static class, i.e. it can't be instantiated, so you wouldn't see ObjectCreation operations.
Edit: I mean, a lot of the methods inside System.Runtime.Intrinsics.X86.Aes
are static, so should catch those cases as well.
Try playing around the System.Runtime.Intrinsics.X86.Aes
API, and then you'll have an idea of what unit tests to write.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, since it's an abstract class, we should also make sure no one is deriving from it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't need to worry about deriving from it. All of the intrinsics are abstract classes with internal ctors, meaning that only the runtime itself can subclass it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh okay, cool.
ReferenceAssemblies = new ReferenceAssemblies( | ||
"netcoreapp3.1", | ||
new PackageIdentity( | ||
"Microsoft.NETCore.App.Ref", | ||
"3.1.0"), | ||
Path.Combine("ref", "netcoreapp3.1")), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ReferenceAssemblies.NetCore.NetCoreApp31
doesn't exist. It's probably because an older version of roslyn SDK being used in 2.9.x branch.
@mavasani, Do you want to update the sdk version instead? If so, please inform me where the version should be updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Marking this as blocked until #3646 (comment) is resolved.
Don't forget these classes as well:
Note: there may also be nested classes within these types, such as |
Closing as the discussion in the issue has moved towards using EditorBrowsable for these APIs. |
@mavasani @GrabYourPitchforks, I need an initial review on this.
Fixes #3646