On Mon, Jun 13, 2022 at 10:29:43AM +0200, Jan Beulich wrote:
> On 13.06.2022 10:21, Roger Pau Monné wrote:
> > On Mon, Jun 13, 2022 at 09:30:06AM +0200, Jan Beulich wrote:
> >> On 10.06.2022 17:06, Roger Pau Monne wrote:
> >>> Prevent dropping console output from the hardware domain, since it's
> >>> likely important to have all the output if the boot fails without
> >>> having to resort to sync_console (which also affects the output from
> >>> other guests).
> >>>
> >>> Do so by pairing the console_serial_puts() with
> >>> serial_{start,end}_log_everything(), so that no output is dropped.
> >>
> >> While I can see the goal, why would Dom0 output be (effectively) more
> >> important than Xen's own one (which isn't "forced")? And with this
> >> aiming at boot output only, wouldn't you want to stop the overriding
> >> once boot has completed (of which, if I'm not mistaken, we don't
> >> really have any signal coming from Dom0)? And even during boot I'm
> >> not convinced we'd want to let through everything, but perhaps just
> >> Dom0's kernel messages?
> >
> > I normally use sync_console on all the boxes I'm doing dev work, so
> > this request is something that come up internally.
> >
> > Didn't realize Xen output wasn't forced, since we already have rate
> > limiting based on log levels I was assuming that non-ratelimited
> > messages wouldn't be dropped. But yes, I agree that Xen (non-guest
> > triggered) output shouldn't be rate limited either.
>
> Which would raise the question of why we have log levels for non-guest
> messages.
Hm, maybe I'm confused, but I don't see a direct relation between log
levels and rate limiting. If I set log level to WARNING I would
expect to not loose _any_ non-guest log messages with level WARNING or
above. It's still useful to have log levels for non-guest messages,
since user might want to filter out DEBUG non-guest messages for
example.
> > Also that would give the xenstore domain a way to trigger
> > DoS attacks.
>
> I guess a Xenstore domain can do so anyway, by simply refusing to
> fulfill its job.
Right, but that's IMO a DoS strictly related to the purpose of the
domain.
Thanks, Roger.
