linux-kernel - Re: [PATCH v2 04/13] KVM: x86: API changes for SMM support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150528134821.GA6974@potion.brq.redhat.com>
Date:	Thu, 28 May 2015 15:48:24 +0200
From:	Radim Krčmář <rkrcmar@...hat.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	guangrong.xiao@...ux.intel.com, bdas@...hat.com
Subject: Re: [PATCH v2 04/13] KVM: x86: API changes for SMM support

2015-05-28 11:00+0200, Paolo Bonzini:
> On 27/05/2015 19:05, Paolo Bonzini wrote:
> > This patch includes changes to the external API for SMM support.
> > All the changes are predicated by the availability of a new
> > capability, KVM_CAP_X86_SMM, which is added at the end of the
> > patch series.
> > 
> > Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
> 
> Radim, I forgot to change flags to u8 in this patch.  However, I am
> thinking that it's just as good to leave it as u16.  The reason is that
> the other two fields in this 32-bit word were just 1-bit flags that were
> expanded to 8 bits for no particular reasons.

(Yeah, it's sad that we have wasted all those bits.)

> If we make it now
> 
> 		u8 flags;
> 		u8 padding2;
> 
> chances are that in due time it will become simply
> 
> 		u8 flags;
> 		u8 flags2;

True, I forgot that big endian exists, so we can't just say u16 later.
(u8 avoids endianess problems of C bit-fields, but I wouldn't have
 brought it up when u8 isn't strictly better ...)

> and then it's nicer to just have an u16.  On the other hand, your
> argument that KVM_RUN has very little free space is also a good one.

Thinking more about it ... we don't forbid multi-bit flags, so u16 can
be used fairly the same way.  (u16 would be a bit worse for an 8 bit
vector, but nicer for >8 bit vector.)

> What do you think?  I have already done the change in my local repo, but
> I can change it back too.

I'd be glad if we were more bit-field friendly, but whatever is the
least work for you is the best :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/