2018-03-07 16:10+0100, Paolo Bonzini:
> On 07/03/2018 15:56, Radim Krčmář wrote:
> > The MSR_F10H_DECFG default is questionable -- MSR_F10H_DECFG is an
> > architectural MSR, so we'd be changing the guest under the sight of
> > existing userspaces.
> > A potential security risk if they migrate the
2018-03-07 16:10+0100, Paolo Bonzini:
> On 07/03/2018 15:56, Radim Krčmář wrote:
> > The MSR_F10H_DECFG default is questionable -- MSR_F10H_DECFG is an
> > architectural MSR, so we'd be changing the guest under the sight of
> > existing userspaces.
> > A potential security risk if they migrate the
On 07/03/2018 15:56, Radim Krčmář wrote:
> The MSR_F10H_DECFG default is questionable -- MSR_F10H_DECFG is an
> architectural MSR, so we'd be changing the guest under the sight of
> existing userspaces.
> A potential security risk if they migrate the guest to a CPU that
> doesn't serialize LFENCE.
On 07/03/2018 15:56, Radim Krčmář wrote:
> The MSR_F10H_DECFG default is questionable -- MSR_F10H_DECFG is an
> architectural MSR, so we'd be changing the guest under the sight of
> existing userspaces.
> A potential security risk if they migrate the guest to a CPU that
> doesn't serialize LFENCE.
2018-03-07 12:53+0100, Paolo Bonzini:
> On 02/03/2018 22:42, Radim Krčmář wrote:
> > Ok, sounds good. I've deferred it to rc5 as I think we'll want to use
> > this to replace the auto setting: I would not bet that it is going to
> > be safe to expose future bits, so having the userspace always
2018-03-07 12:53+0100, Paolo Bonzini:
> On 02/03/2018 22:42, Radim Krčmář wrote:
> > Ok, sounds good. I've deferred it to rc5 as I think we'll want to use
> > this to replace the auto setting: I would not bet that it is going to
> > be safe to expose future bits, so having the userspace always
On 02/03/2018 22:42, Radim Krčmář wrote:
> Ok, sounds good. I've deferred it to rc5 as I think we'll want to use
> this to replace the auto setting: I would not bet that it is going to
> be safe to expose future bits, so having the userspace always sanitize
> the capabilities would be safer (and
On 02/03/2018 22:42, Radim Krčmář wrote:
> Ok, sounds good. I've deferred it to rc5 as I think we'll want to use
> this to replace the auto setting: I would not bet that it is going to
> be safe to expose future bits, so having the userspace always sanitize
> the capabilities would be safer (and
2018-03-02 10:36+0100, Paolo Bonzini:
> On 01/03/2018 22:39, Radim Krčmář wrote:
> > [Resent after removing g...@char.us.oracle.com.]
> >
> > 2018-02-26 17:13-0500, Konrad Rzeszutek Wilk:
> >> On Sat, Feb 24, 2018 at 01:52:26AM +0100, Paolo Bonzini wrote:
> >>> Use the new MSR feature framework
2018-03-02 10:36+0100, Paolo Bonzini:
> On 01/03/2018 22:39, Radim Krčmář wrote:
> > [Resent after removing g...@char.us.oracle.com.]
> >
> > 2018-02-26 17:13-0500, Konrad Rzeszutek Wilk:
> >> On Sat, Feb 24, 2018 at 01:52:26AM +0100, Paolo Bonzini wrote:
> >>> Use the new MSR feature framework
On 01/03/2018 22:39, Radim Krčmář wrote:
> [Resent after removing g...@char.us.oracle.com.]
>
> 2018-02-26 17:13-0500, Konrad Rzeszutek Wilk:
>> On Sat, Feb 24, 2018 at 01:52:26AM +0100, Paolo Bonzini wrote:
>>> Use the new MSR feature framework to expose the ARCH_CAPABILITIES MSR to
>>>
On 01/03/2018 22:39, Radim Krčmář wrote:
> [Resent after removing g...@char.us.oracle.com.]
>
> 2018-02-26 17:13-0500, Konrad Rzeszutek Wilk:
>> On Sat, Feb 24, 2018 at 01:52:26AM +0100, Paolo Bonzini wrote:
>>> Use the new MSR feature framework to expose the ARCH_CAPABILITIES MSR to
>>>
[Resent after removing g...@char.us.oracle.com.]
2018-02-26 17:13-0500, Konrad Rzeszutek Wilk:
> On Sat, Feb 24, 2018 at 01:52:26AM +0100, Paolo Bonzini wrote:
> > Use the new MSR feature framework to expose the ARCH_CAPABILITIES MSR to
> > userspace. This way, userspace can access the
[Resent after removing g...@char.us.oracle.com.]
2018-02-26 17:13-0500, Konrad Rzeszutek Wilk:
> On Sat, Feb 24, 2018 at 01:52:26AM +0100, Paolo Bonzini wrote:
> > Use the new MSR feature framework to expose the ARCH_CAPABILITIES MSR to
> > userspace. This way, userspace can access the
On Mon, Feb 26, 2018 at 05:13:00PM -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Feb 24, 2018 at 01:52:26AM +0100, Paolo Bonzini wrote:
> > Use the new MSR feature framework to expose the ARCH_CAPABILITIES MSR to
> > userspace. This way, userspace can access the capabilities even if it
> > does
On Mon, Feb 26, 2018 at 05:13:00PM -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Feb 24, 2018 at 01:52:26AM +0100, Paolo Bonzini wrote:
> > Use the new MSR feature framework to expose the ARCH_CAPABILITIES MSR to
> > userspace. This way, userspace can access the capabilities even if it
> > does
On Sat, Feb 24, 2018 at 01:52:26AM +0100, Paolo Bonzini wrote:
> Use the new MSR feature framework to expose the ARCH_CAPABILITIES MSR to
> userspace. This way, userspace can access the capabilities even if it
> does not have the permissions to read MSRs.
... That is good but could you expand a
On Sat, Feb 24, 2018 at 01:52:26AM +0100, Paolo Bonzini wrote:
> Use the new MSR feature framework to expose the ARCH_CAPABILITIES MSR to
> userspace. This way, userspace can access the capabilities even if it
> does not have the permissions to read MSRs.
... That is good but could you expand a
18 matches
Mail list logo
