OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] [RFC PATCH v3 3/4] virtio-rtc: Add alarm feature


On 25.12.23 05:18, Jason Wang wrote:
> On Sat, Dec 23, 2023 at 2:57âAM Cornelia Huck <cohuck@redhat.com> wrote:
>>
>> On Mon, Dec 18 2023, Peter Hilber <peter.hilber@opensynergy.com> wrote:
>>
>>> Add the VIRTIO_RTC_F_ALARM feature (without normative statements).
>>>
>>> The intended use case is: A driver needs to react when an alarm time has
>>> been reached, but the driver may be in a sleep state or powered off at
>>> alarm time. The alarm feature can resume and notify the driver in this
>>> case. Alarms may be retained across device resets (including reset on
>>> boot).
>>
>> Does the driver have some kind of control or information about whether
>> alarms are retained? I.e. to start with a clean slate, if wanted.
> 
> It might be otherwise we may have security implications?
> 
> Userspace driver set the alarm, and the device was shifted to kernel
> driver which may get this alarm accidentally?

As per my answer to Cornelia's comment, a driver could avoid getting such
an alarm (at least after tightening the spec a bit).

I can also add a requirement that the driver should, on an alarm
notification, read the virtio-rtc clock, to avoid misinterpretation (also
due to race conditions such as when setting a new alarm time while the old
is about to expire).

Thanks for the comment,

Peter


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]