All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Jack Schwartz <jack.schwartz@oracle.com>
Cc: ehabkost@redhat.com, Anatol Pomozov <anatol.pomozov@gmail.com>,
	konrad.wilk@oracle.com, daniel.kiper@oracle.com, mst@redhat.com,
	qemu-devel@nongnu.org, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH QEMU v1 0/4] multiboot: bss_end_addr can be zero / cleanup
Date: Mon, 5 Mar 2018 09:13:02 +0100	[thread overview]
Message-ID: <20180305081302.GA4789@localhost.localdomain> (raw)
In-Reply-To: <45620ce8-23c6-3ad5-2393-a5f48c2a9f58@oracle.com>

Am 02.03.2018 um 20:32 hat Jack Schwartz geschrieben:
> Hi Kevin.
> 
> On 2018-01-15 07:54, Kevin Wolf wrote:
> > Am 21.12.2017 um 18:25 hat Jack Schwartz geschrieben:
> > > Properly account for the possibility of multiboot kernels with a zero
> > > bss_end_addr.  The Multiboot Specification, section 3.1.3 allows for
> > > kernels without a bss section, by allowing a zeroed bss_end_addr multiboot
> > > header field.
> > > 
> > > Do some cleanup to multiboot.c as well:
> > > - Remove some unused variables.
> > > - Use more intuitive header names when displaying fields in messages.
> > > - Change fprintf(stderr...) to error_report
> > There are some conflicts with Anatol's (CCed) multiboot series:
> > https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg03003.html
> > 
> > None if these should be hard to resolve, but it would be good if you
> > could agree with each other whose patch series should come first, and
> > then the other one should be rebased on top of that.
> > 
> > > Testing:
> > >    1) Ran the "make check" test suite.
> > >    2) Booted multiboot kernel with bss_end_addr=0.  (I rolled my own
> > >       grub multiboot.elf test "kernel" by modifying source.)  Verified
> > >       with gdb that new code that reads addresses/offsets from multiboot
> > >       header was accessed.
> > >    3) Booted multiboot kernel with non-zero bss_end_addr.
> > >    4) Uncommented DEBUG_MULTIBOOT in multiboot.c and verified messages worked.
> > >    5) Code has soaked in an internal repo for two months.
> > Can you integrate your test kernel from 2) in tests/multiboot/ so we can
> > keep this as a regression test?
> If need be, would you be willing to accept updated versions of these patches
> (with another review, of course) without the test file?  I will deliver the
> test file later once I get company approvals.  I don't want the test file to
> continue holding everything up in the meantime.

Sure, let's move forward with what we have now. Please keep me CCed when
you send a new version and I'll give it a review and hopeuflly get it
merged.

Kevin

  reply	other threads:[~2018-03-05  8:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-21 17:25 [Qemu-devel] [PATCH QEMU v1 0/4] multiboot: bss_end_addr can be zero / cleanup Jack Schwartz
2017-12-21 17:25 ` [Qemu-devel] [PATCH QEMU v1 1/4] multiboot: bss_end_addr can be zero Jack Schwartz
2018-03-07  7:18   ` P J P
2017-12-21 17:25 ` [Qemu-devel] [PATCH QEMU v1 2/4] multiboot: Remove unused variables from multiboot.c Jack Schwartz
2018-03-07  7:20   ` P J P
2017-12-21 17:25 ` [Qemu-devel] [PATCH QEMU v1 3/4] multiboot: Use header names when displaying fields Jack Schwartz
2018-03-07  7:25   ` P J P
2017-12-21 17:25 ` [Qemu-devel] [PATCH QEMU v1 4/4] multiboot: fprintf(stderr...) -> error_report() Jack Schwartz
2018-03-07  7:40   ` P J P
2018-01-12 18:28 ` [Qemu-devel] ping: Re: [PATCH QEMU v1 0/4] multiboot: bss_end_addr can be zero / cleanup Jack Schwartz
2018-01-15 15:54 ` [Qemu-devel] " Kevin Wolf
2018-01-17 20:06   ` Jack Schwartz
2018-01-18 11:35     ` Kevin Wolf
2018-01-18 13:03       ` Daniel P. Berrange
2018-01-19 18:36     ` Anatol Pomozov
2018-01-20  0:18       ` Jack Schwartz
2018-01-22  9:57         ` Daniel P. Berrange
2018-03-02 19:32   ` Jack Schwartz
2018-03-05  8:13     ` Kevin Wolf [this message]
2018-03-07  1:52       ` Jack Schwartz
2018-03-07 11:14 ` Kevin Wolf
2018-03-14 17:23 ` [Qemu-devel] CVE-2018-7550 (was: multiboot: bss_end_addr can be zero / cleanup) Kevin Wolf
2018-03-14 17:35   ` Konrad Rzeszutek Wilk
2018-03-14 18:01     ` Kevin Wolf
2018-03-15  6:13       ` P J P

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180305081302.GA4789@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=anatol.pomozov@gmail.com \
    --cc=daniel.kiper@oracle.com \
    --cc=ehabkost@redhat.com \
    --cc=jack.schwartz@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.