d3f:unloads
aamedina opened this issue · 4 comments
d3f:unloads
I would like to be able to reason over facts asserting that some individual artifact (like a host d3f:Kernel executing a process being traced) unloads a d3f:KernelModule or d3f:HardwareDriver.
d3f:unloads a owl:ObjectProperty ;
rdfs:label "unloads" ;
rdfs:subPropertyOf :evicts ;
d3f:definition "x unloads y: The technique or artifact performs the action of unloading some artifact (applications, kernel modules, or hardware drivers, etc.) from a computer's memory." .Do these system calls make sense? They don't fit nicely into the OSAPIFunction hierarchy, but they are system calls in Linux.
d3f:LoadModule a owl:Class ;
d3f:definition "A system call that loads a driver or extension into the kernel." ;
rdfs:seeAlso <https://man7.org/linux/man-pages/man2/init_module.2.html> ;
rdfs:subClassOf d3f:SystemCall,
[ a owl:Restriction ;
owl:onProperty d3f:loads ;
owl:someValuesFrom [
owl:unionOf ( d3f:KernelModule d3f:HardwareDriver )
] ;
] .
d3f:UnloadModule a owl:Class ;
d3f:definition "A system call that unloads a driver or extension from the kernel." ;
rdfs:seeAlso <https://man7.org/linux/man-pages/man2/delete_module.2.html> ;
rdfs:subClassOf d3f:SystemCall,
[ a owl:Restriction ;
owl:onProperty d3f:unloads ;
owl:someValuesFrom [
owl:unionOf ( d3f:KernelModule d3f:HardwareDriver )
] ;
] .References
Those make sense to me. The OS API taxo is parallel to the system call library, we could add those as well. We will be publishing a blog on syscalls soon to explain our design. CC @ryantxu1
The key distinction to consider is what is being hooked where.
Yes we're considering shifting around the OS API taxo - found (here). With you're suggestion, we'll probably add a 'Load Module' and 'Unload Module' as subclasses of 'Syscall', and then 'OS API Load Module' and 'OS API Unload Module' as subclasses of 'OS API System Function'. and 'Linux Init Module'/'Linux Delete Module' as subclasses of those.