ple may get
confused when they see different fixes associated with the same CVE.
Thanks,
Jack
Jack Schwartz (1):
multiboot.c: Document as fixed against CVE-2018-7550
--
1.8.3.1
This empty commit documents multiboot.c as fixed against CVE-2018-7550.
The fix, dated Dec 21 2017, went in before the CVE was created, as:
2a8fcd119eb7 ("multiboot: bss_end_addr can be zero")
Fixes: CVE-2018-7550
Signed-off-by: Jack Schwartz
Reviewed-by: Mark Kanda
--
1.8.3.1
On 03/15/18 10:18, Kevin Wolf wrote:
Am 15.03.2018 um 17:55 hat Jack Schwartz geschrieben:
On 03/15/18 08:54, Kevin Wolf wrote:
Am 15.03.2018 um 06:19 hat Jack Schwartz geschrieben:
Hi Kevin.
My comments are inline...
On 2018-03-14 10:32, Kevin Wolf wrote:
The code path with a manually set
On 03/15/18 08:54, Kevin Wolf wrote:
Am 15.03.2018 um 06:19 hat Jack Schwartz geschrieben:
Hi Kevin.
My comments are inline...
On 2018-03-14 10:32, Kevin Wolf wrote:
The code path with a manually set mh_load_addr in the Multiboot header
checks that load_end_addr <= load_addr, but the p
s fine.
Modulo above comments:
Reviewed-by: Jack Schwartz
Thanks,
Jack
Signed-off-by: Kevin Wolf
---
hw/i386/multiboot.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
index b9064264d8..1e215bf8d3 100644
--- a/hw/i386/multiboot.c
++
Hi Kevin.
I see an issue with the commit message of patch 1; please see my reply
to that patch for details. I fully understand patches 1,2,3, patch 4
except for some of the Makefile black magic, and patch 5 looks
reasonable to me.
So, for patches 2,3,4,5:
Reviewed-by: Jack Schwartz
Hi Kevin and everyone.
On 2018-03-05 00:13, Kevin Wolf wrote:
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
Hi Prasad.
The Multiboot Spec will allow for a zero bss end address. (Please see
section 3.1.3 at https://www.gnu.org/software/grub/manual/multiboot/ .
) For a zero bss end address, this patch will not do the right thing.
I had proposed some patches to properly handle zero bss end address,
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
Hi Anatol and Kevin.
Kevin and Anatol, thanks for your replies.
A few comments inline close to the bottom...
On 2018-02-05 13:43, Anatol Pomozov wrote:
Hi
On Wed, Jan 31, 2018 at 1:12 AM, Kevin Wolf wrote:
Am 31.01.2018 um 00:15 hat Jack Schwartz geschrieben:
Hi Anatol and Kevin.
Even
Hi Anatol and Kevin.
Even though I am new to Qemu, I have a patch to deliver for multiboot.c
(as you know) and so I feel familiar enough to do a review of this
patch. One comment is probably more for maintainers.
Comments inline...
On 01/29/18 12:43, Anatol Pomozov wrote:
Using C structs
Hi Anatol.
I have one comment about sections.c headers (and didn't really look
further in that file), and start.S.
Comments inline...
On 01/29/18 12:43, Anatol Pomozov wrote:
Multiboot may load section headers and all sections (even those that are
not part of any segment) to target memory.
Hi Anatol, Daniel and Kevin.
On 01/19/18 10:36, Anatol Pomozov wrote:
Hello Jack
On Wed, Jan 17, 2018 at 12:06 PM, Jack Schwartz
wrote:
Hi Kevin and Anatol.
Kevin, thanks for your review.
More inline below...
On 01/15/18 07:54, Kevin Wolf wrote:
Am 21.12.2017 um 18:25 hat Jack Schwartz
Hi Kevin and Anatol.
Kevin, thanks for your review.
More inline below...
On 01/15/18 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
://patchwork.ozlabs.org/patch/852046/
4/4 multiboot: fprintf(stderr...) -> error_report()
http://patchwork.ozlabs.org/patch/852051/
Thanks,
Jack
On 12/21/17 09:25, Jack Schwartz wrote:
Properly account for the possibility of multiboot kernels with a zero
bss_end_addr. The Multib
Hi Kevin.
Thanks for your feedback.
Looks like my team's project plans have changed, and there is no need to
pursue this further. We can work with the existing reason string.
Thanks,
Jack
On 01/09/18 02:24, Kevin Wolf wrote:
Am 08.01.2018 um 20:57 hat Jack Sch
Hi Kevin.
On 2017-12-22 05:52, Kevin Wolf wrote:
Am 22.12.2017 um 01:11 hat Jack Schwartz geschrieben:
BLOCK_IO_ERROR events currently contain a "reason" string which is
strerror(errno) of the error. This enhancement provides those events with
the numeric errno value as well, s
BLOCK_IO_ERROR events currently contain a "reason" string which is
strerror(errno) of the error. This enhancement provides those events with
the numeric errno value as well, since it is easier to parse for error type
than a string.
Signed-off-by: Jack Schwartz
Reviewed-by: Konrad Rzes
s. That file's prior reference to
errno confirms that Windows will work with the code change.
- If there would be a Linux vs Windows difference in mapping of errno to
error string values, that difference would have been in place before my
changes.
Thanks,
Jack
Jack Schwartz (1):
block: Add numeric errno field to BLOCK_IO_ERROR events
block/block-backend.c | 2 +-
qapi/block-core.json | 12 ++--
2 files changed, 11 insertions(+), 3 deletions(-)
--
1.8.3.1
Change all fprintf(stderr...) calls in hw/i386/multiboot.c to call
error_report() instead, including the mb_debug macro. Remove the "\n"
from strings passed to all modified calls, since error_report() appends
one.
Signed-off-by: Jack Schwartz
Reviewed-by: Daniel Kiper
---
hw/i386/m
The multiboot spec (https://www.gnu.org/software/grub/manual/multiboot/),
section 3.1.3, allows for bss_end_addr to be zero.
A zero bss_end_addr signifies there is no .bss section.
Suggested-by: Daniel Kiper
Signed-off-by: Jack Schwartz
Reviewed-by: Daniel Kiper
---
hw/i386/multiboot.c | 18
repo for two months.
Thanks,
Jack
Jack Schwartz (4):
multiboot: bss_end_addr can be zero
multiboot: Remove unused variables from multiboot.c
multiboot: Use header names when displaying fields
multiboot: fprintf(stderr...) -> error_report()
h
Refer to field names when displaying fields in printf and debug statements.
Signed-off-by: Jack Schwartz
Reviewed-by: Daniel Kiper
---
hw/i386/multiboot.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
index
Remove unused variables: mh_mode_type, mh_width, mh_height, mh_depth
Signed-off-by: Jack Schwartz
Reviewed-by: Daniel Kiper
---
hw/i386/multiboot.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
index ff2733d..964feaf 100644
--- a/hw/i386
Hi Luiz, Markus and everyone.
I am working on a qemu enhancement to display io-status in each
query-block command, not just those for devices which have werror and/or
rerror set to stop on error.
I'd like to verify the reasons behind the query-block command not
reporting io-status if errors
25 matches
Mail list logo
