>>> On 05.02.16 at 22:47, wrote:
>> Also is using "long" here really a good idea? Shouldn't we rather use
>> fixed width or ELF types?
>
> We can. It would look like this:
>
> struct xsplice_patch_func {
> const unsigned char *name;
> Elf64_Xword new_addr;
> Elf64_Xword old_addr;
>
I've snipped the email. I've taken your reviews in account - and just
responding on some of them that I believe need more comments.
..snip..
> > +However it has severe drawbacks - the safety checks which have to make sure
> > +the function is not on the stack - must also check every caller. For so
> >+
> >+ /->\
> >+ \ /
> >+ UNLOAD <--- CHECK ---> REPLACE|APPLY --> REVERT --\
> >+\ |
> >+ \---<-/
>
> This doesn't make much sense to me. The actions need to be represented b
Hey,
I applied all your comments..
> >+The `struct xen_xsplice_status` structure contains an status of payload
> >which includes:
> >+
> >+ * `status` - whether it has been:
> >+ * *XSPLICE_STATUS_LOADED* (1) has been loaded.
> >+ * *XSPLICE_STATUS_CHECKED* (2) the ELF payload safety checks
>>> On 14.01.16 at 22:46, wrote:
> +## Patching code
> +
> +The first mechanism to patch that comes in mind is in-place replacement.
> +That is replace the affected code with new code. Unfortunately the x86
> +ISA is variable size which places limits on how much space we have available
> +to repla
On 01/14/2016 09:46 PM, Konrad Rzeszutek Wilk wrote:
+## Workflow
+
+The expected workflows of higher-level tools that manage multiple patches
+on production machines would be:
+
+ * The first obvious task is loading all available / suggested
+ hotpatches around system start.
I'd expect that
I skimmed this document and managed to do some non-technical nitpicks.
:-)
On Thu, Jan 14, 2016 at 04:46:59PM -0500, Konrad Rzeszutek Wilk wrote:
[...]
> +## Patching code
> +
> +The first mechanism to patch that comes in mind is in-place replacement.
> +That is replace the affected code with new
A mechanism is required to binarily patch the running hypervisor with new
opcodes that have come about due to primarily security updates.
This document describes the design of the API that would allow us to
upload to the hypervisor binary patches.
This document has been shaped by the input from:
