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.
>> Finally, what about (if such configured) output from a Xenstore
>> domain? That's kind of importantish as well, I'd say.
>
> I would be less inclined to do so. Xenstore domains can use a regular
> PV console, which shouldn't be affected by the rate limiting applied to
> the serial.
Fair point.
> 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.
Jan
