On 10/27/2015 08:08 AM, Martin Pohlack wrote:
On 06.10.2015 14:57, Ross Lagerwall wrote:
On 09/16/2015 10:01 PM, Konrad Rzeszutek Wilk wrote:
+### xSplice interdependencies
+
+xSplice patches interdependencies are tricky.
+
+There are the ways this can be addressed:
+ * A single large patch tha
On 06.10.2015 14:57, Ross Lagerwall wrote:
> On 09/16/2015 10:01 PM, Konrad Rzeszutek Wilk wrote:
>> +### xSplice interdependencies
>> +
>> +xSplice patches interdependencies are tricky.
>> +
>> +There are the ways this can be addressed:
>> + * A single large patch that subsumes and replaces all pr
On Mon, Oct 26, 2015 at 01:21:46PM +, Ross Lagerwall wrote:
> On 10/26/2015 12:01 PM, Martin Pohlack wrote:
> >On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote:
> >
> >[...]
> >
> >>+### xsplice_patch
> >>+
> >>+This structure has the binary code (or data) to be patched. Depending on
> >>the
>
On 10/26/2015 12:01 PM, Martin Pohlack wrote:
On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote:
[...]
+### xsplice_patch
+
+This structure has the binary code (or data) to be patched. Depending on the
+type it can either an inline patch (data or text) or require an relocation
+change (which re
>>> On 26.10.15 at 13:01, wrote:
> On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote:
>> +The convention for file-type symbols (that would allow to map many
>> +symbols to their compilation unit) says that only the basename (i.e.,
>> +without directories) is embedded. This creates another layer of
On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote:
[...]
> +### xsplice_patch
> +
> +This structure has the binary code (or data) to be patched. Depending on the
> +type it can either an inline patch (data or text) or require an relocation
> +change (which requires a trampoline). Naturally it also
>>> On 16.09.15 at 23:01, wrote:
> +### Symbol names
> +
> +
> +Xen as it is now, has a couple of non-unique symbol names which will
> +make runtime symbol identification hard. Sometimes, static symbols
> +simply have the same name in C files, sometimes such symbols get
> +included via header fil
On 09/16/2015 10:01 PM, Konrad Rzeszutek Wilk wrote:
+### xSplice interdependencies
+
+xSplice patches interdependencies are tricky.
+
+There are the ways this can be addressed:
+ * A single large patch that subsumes and replaces all previous ones.
+ Over the life-time of patching the hyperviso
On 09/16/2015 10:01 PM, Konrad Rzeszutek Wilk wrote:
+### Generation of xSplice ELF payloads
+
+The design of that is not discussed in this design.
+
+The author of this design envisions objdump and objcopy along
+with special GCC parameters (see above) to create .o.xsplice files
+which can be us
>>> On 16.09.15 at 23:01, wrote:
> +### Symbol names
> +
> +
> +Xen as it is now, has a couple of non-unique symbol names which will
> +make runtime symbol identification hard. Sometimes, static symbols
> +simply have the same name in C files, sometimes such symbols get
> +included via header fil
>>> Konrad Rzeszutek Wilk 09/16/15 11:02 PM >>>
>+struct xsplice {
>+const char *name; /* A sensible name for the patch. Up to 40 characters.
>*/
Any reason not to make this a 40-character array right in the structure then?
It would seem to me the fewer relocation the better.
>+const
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 shapped by the input from:
12 matches
Mail list logo
