[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen/kexec: Clear unused registers before jumping into an image



>>> On 18.11.13 at 12:08, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote:
> On Mon, Nov 18, 2013 at 09:29:41AM +0000, Jan Beulich wrote:
>> >>> On 15.11.13 at 21:07, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
>> > On 15/11/13 15:56, Daniel Kiper wrote:
>> >> Clear unused registers before jumping into an image. This way
>> >> loaded image could not assume that any register has an specific
>> >> info about earlier running Xen hypervisor. However, it also
>> >> does not mean that the image may expect that a given register
>> >> is zeroed. The image MUST assume that every register has a random
>> >> value or in other words it is uninitialized or has undefined state.
>> >
>> > I think this, where the specification (registers undefined) differs from
>> > the implementation (registers zeroed), is the worst option.
>> >
>> > I also think it is more likely for an image to inadvertently rely on a
>> > zero value that whatever junk Xen has left behind.
>>
>> Preventing users to rely on anything would likely make it
>> desirable to put some random value into all unused registers.
> 
> Right, but on the other hand this way we lose completely chance
> to differentiate between old and new implementation of kexec
> if we would like to do that in the future (yes, this is small
> chance but it still exists). Additionally, I think it could be
> quite difficult because at this stage there is no simple reliable
> RNGs. Although there are some CPUs with RNGs but they are not
> very common right now. However, I will do not object if we find
> another simple RNG.

We surely wouldn't need a good quality random number here -
the TSC would very likely already be more random than anything
we need.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.