We present ClearView, a system for automatically patching errors in deployed software. ClearView works on stripped Windows x86 binaries without any need for source code, debugging information, or other external information, and without human intervention.ClearView (1) observes normal executions to learn invariants that characterize the application's normal behavior, (2) uses error detectors to monitor the execution to detect failures, (3) identifies violations of learned invariants that occur during failed executions, (4) generates candidate repair patches that enforce selected invariants by changing the state or the flow of control to make the invariant true, and (5) observes the continued execution of patched applications to select the most successful patch.ClearView is designed to correct errors in software with high availability requirements. Aspects of ClearView that make it particularly appropriate for this context include its ability to generate patches without human intervention, to apply and remove patches in running applications without requiring restarts or otherwise perturbing the execution, and to identify and discard ineffective or damaging patches by evaluating the continued behavior of patched applications.In a Red Team exercise, ClearView survived attacks that exploit security vulnerabilities. A hostile external Red Team developed ten code-injection exploits and used these exploits to repeatedly attack an application protected by ClearView. ClearView detected and blocked all of the attacks. For seven of the ten exploits, ClearView automatically generated patches that corrected the error, enabling the application to survive the attacks and successfully process subsequent inputs. The Red Team also attempted to make ClearView apply an undesirable patch, but ClearView's patch evaluation mechanism enabled ClearView to identify and discard both ineffective patches and damaging patches.

developed thrombosis, our patients' CWA parameters remained remarkably high despite the use of thromboprophylaxis during their ICU stay. It is possible that CWA and other thrombin generation assays might not be sensitive enough to detect the haemostatic changes caused by the standard prophylactic dose of low molecular weight heparin.All three patients recovered from COVID-19 infection.Thatour findings of markedly raised CWA parameters in critically ill infected cases are possibly consistent with hypercoagulability is not unexpected. Such patients exhibit hyperinflammation and cytokine overdrive, and extensive crosstalk is known to exist in the cytokines, the inflammatory system, and coagulation. 6 Critically ill COVID-19 patients have been shown to have increased proinflammatory cytokines including IL-2 and TNF-α, 4 and these factors could upregulate the coagulation system. 6 We speculate that this could partially account for the CWA changes observed.Although our findings are limited by the relatively few patients and data points and by the lack of other correlation studies with other coagulation assays, we believe there are still valuable points to take away. Many of the specialized and research haemostatic assays cannot be safely and easily performed on samples collected from COVID-19 patients in view of laboratory biosafety concerns. As COVID-19 infection is spreading relentlessly worldwide, there is an urgent need for rapid and readily accessible biomarkers that can aid clinical stratification and management. So, CWA represents a simple, automated and rapid test, which fulfills these biosafety criteria. Whenever an aPTT is performed, an aPTT waveform is generated automatically by commonly used optical analysers worldwide.In conclusion, the rise of CWA parameters precedes and coincides with ICU admission and warrant further study to confirm its utility in the routine management of COVID-19 patients.

No abstract

COVID-19 caused by Severe Acute Respiratory Syndrome Coronavirus-2 (SARS-CoV-2) and other respiratory viral (non-CoV-2-RV) infections are associated with thrombotic complications. The differences in prothrombotic potential between SARS-CoV-2 and non-CoV-2-RV have not been well characterised. We compared the thrombotic rates between these two groups of patients directly and further delved into their coagulation profiles. In this single-center, retrospective cohort study, all consecutive COVID-19 and non-CoV-2-RV patients admitted between January 15th and April 10th 2020 were included. Coagulation parameters studied were prothrombin time and activated partial thromboplastin time and its associated clot waveform analysis (CWA) parameter, min1, min2 and max2. In the COVID-19 (n = 181) group there were two (1.0 event/1000-hospital-days) myocardial infarction events while one (1.8 event/1000-hospital-day) was reported in the non-CoV-2-RV (n = 165) group. These events occurred in patients who were severely ill. There were no venous thrombotic events. Coagulation parameters did not differ throughout the course of mild COVID-19. However, CWA parameters were significantly higher in severe COVID-19 compared with mild disease, suggesting hypercoagulability (min1: 6.48%/s vs 5.05%/s, P < 0.001; min2: 0.92%/s2 vs 0.74%/s2, P = 0.033). In conclusion, the thrombotic rates were low and did not differ between COVID-19 and non-CoV-2-RV patients. The hypercoagulability in COVID-19 is a highly dynamic process with the highest risk occurring when patients were most severely ill. Such changes in haemostasis could be detected by CWA. In our population, a more individualized thromboprophylaxis approach, considering clinical and laboratory factors, is preferred over universal pharmacological thromboprophylaxis for all hospitalized COVID-19 patients and such personalized approach warrants further research.

This paper presents a formal specification-based software monitoring approach that can dynamically and continuously monitor the behaviors of a target system and explicitly recognize undesirable behaviors in the implementation with respect to its formal specification. The key idea of our approach is in building a monitoring module that connects a specification animator with a program debugger. The requirements information about expected dynamic behaviors of the target system are gathered from the formal specification animator, while the actual behaviors of concrete implementations of the target system are obtained through the program debugger. Based on the information obtained from both sides, the judgement on the conformance of the concrete implementation with respect to the formal specification is made timely while the target system is running. Furthermore, the proposed formal specification-based software monitoring technique does not embed any instrumentation codes to the target system nor does it annotate the target system with any formal specifications. It can detect implementation errors in a real-time manner, and help the developers and users of the system to react to the problems before critical failure occurs.