Hi,
On 03/04/2019 08:59, Jan Beulich wrote:
On 02.04.19 at 19:49, <andrew.coop...@citrix.com> wrote:
On 02/04/2019 17:42, Julien Grall wrote:
diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
index 97466a12b1..35a47c7229 100644
--- a/xen/arch/arm/early_printk.c
+++ b/xen/arch/arm/early_printk.c
@@ -17,9 +17,10 @@
void early_putch(char c);
void early_flush(void);
-void early_puts(const char *s)
+void early_puts(const char *s, unsigned int nr)
size_t here and elsewhere please, because...
@@ -666,16 +664,16 @@ static bool_t console_locks_busted;
static void __putstr(const char *str)
{
+ size_t len = strlen(str);
+
ASSERT(spin_is_locked(&console_lock));
- sercon_puts(str);
- video_puts(str);
+ sercon_puts(str, len);
+ video_puts(str, len);
... this introduces a truncation bug for 64bit builds.
I don't expect a 4G buffer to be passed, but it is not worth introducing
the possibility for such a subtle bug in the first place.
I don't entirely object to what you say, but I also don't think
running into a truncation situation here would be an actual
problem: Consider how long it would take to get out such a
giant string, not to speak of it going to wrap our internal ring
buffers many times. Looking at it from that angle, truncation
may actually beneficial here;
Truncation could be done explicitly in *_puts functions if necessary. So I will
switch to size_t as suggested by Andrew.
"len" may want to be unsigned int
as well then. do_console_io()'s "count" is "int" as well (should
really be "unsigned int" imo, just like "cmd").
I will look at writing a patch to switch do_console_io() to unsigned int.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
