[RFC] tcg plugin: Additional plugin interface

[RFC] tcg plugin: Additional plugin interface

[Min-Yih Hsu]

[-- Attachment #1: Type: text/plain, Size: 620 bytes --]

Hi Alex and QEMU developers,

Recently I was working with the TCG plugin. I found that
`qemu_plugin_cb_flags` seems to reserve the functionality to read / write
CPU register state, I'm wondering if you can share some roadmap or thoughts
on this feature?

Personally I see reading the CPU register state as (kind of) low-hanging
fruit. The most straightforward way to implement it will be adding another
function that can be called by insn_exec callbacks to read (v)CPU register
values. What do you think about this?

Thank you
-Min
-- 
Min-Yih Hsu
Ph.D Student in ICS Department, University of California, Irvine (UCI).

[-- Attachment #2: Type: text/html, Size: 860 bytes --]

Re: [RFC] tcg plugin: Additional plugin interface

[Alex Bennée]

Min-Yih Hsu <minyihh@uci.edu> writes:

> Hi Alex and QEMU developers,
>
> Recently I was working with the TCG plugin. I found that `qemu_plugin_cb_flags` seems to reserve the functionality to
> read / write CPU register state, I'm wondering if you can share some
> roadmap or thoughts on this feature?

I think reading the CPU register state is certainly on the roadmap,
writing registers presents a more philosophical question of if it opens
the way to people attempting a GPL bypass via plugins. However reading
registers would certainly be a worthwhile addition to the API.

> Personally I see reading the CPU register state as (kind of) low-hanging fruit. The most straightforward way to implement
> it will be adding another function that can be called by insn_exec callbacks to read (v)CPU register values. What do you
> think about this?

It depends on your definition of low hanging fruit ;-)

Yes the implementation would be a simple helper which could be called
from a callback - I don't think we need to limit it to just insn_exec. I
think the challenge is proving a non-ugly API that works cleanly across
all the architectures. I'm not keen on exposing arbitrary gdb register
IDs to the plugins.

There has been some discussion previously on the list which is probably
worth reviewing:

  Date: Mon, 7 Dec 2020 16:03:24 -0500
  From: Aaron Lindsay <aaron@os.amperecomputing.com>
  Subject: Plugin Register Accesses
  Message-ID: <X86YnHhHMpQBr2/G@strawberry.localdomain>

But in short I think we need a new subsystem in QEMU where frontends can
register registers (sic) and then provide a common API for various
users. This common subsystem would then be the source of data for:

  - plugins
  - gdbstub
  - monitor (info registers)
  - -d LOG_CPU logging

If you are interested in tackling such a project I'm certainly happy to
provide pointers and review.

>
> Thank you
> -Min


-- 
Alex Bennée

Re: [RFC] tcg plugin: Additional plugin interface

[Min-Yih Hsu]

Hi Alex,

> On Apr 23, 2021, at 8:44 AM, Alex Bennée <alex.bennee@linaro.org> wrote:
> 
> 
> Min-Yih Hsu <minyihh@uci.edu> writes:
> 
>> Hi Alex and QEMU developers,
>> 
>> Recently I was working with the TCG plugin. I found that `qemu_plugin_cb_flags` seems to reserve the functionality to
>> read / write CPU register state, I'm wondering if you can share some
>> roadmap or thoughts on this feature?
> 
> I think reading the CPU register state is certainly on the roadmap,
> writing registers presents a more philosophical question of if it opens
> the way to people attempting a GPL bypass via plugins. However reading
> registers would certainly be a worthwhile addition to the API.

Interesting…I’ve never thought about this problem before.

> 
>> Personally I see reading the CPU register state as (kind of) low-hanging fruit. The most straightforward way to implement
>> it will be adding another function that can be called by insn_exec callbacks to read (v)CPU register values. What do you
>> think about this?
> 
> It depends on your definition of low hanging fruit ;-)
> 
> Yes the implementation would be a simple helper which could be called
> from a callback - I don't think we need to limit it to just insn_exec. I
> think the challenge is proving a non-ugly API that works cleanly across
> all the architectures. I'm not keen on exposing arbitrary gdb register
> IDs to the plugins.
> 
> There has been some discussion previously on the list which is probably
> worth reviewing:
> 
>  Date: Mon, 7 Dec 2020 16:03:24 -0500
>  From: Aaron Lindsay <aaron@os.amperecomputing.com>
>  Subject: Plugin Register Accesses
>  Message-ID: <X86YnHhHMpQBr2/G@strawberry.localdomain>
> 
> But in short I think we need a new subsystem in QEMU where frontends can
> register registers (sic) and then provide a common API for various
> users. This common subsystem would then be the source of data for:
> 
>  - plugins
>  - gdbstub
>  - monitor (info registers)
>  - -d LOG_CPU logging
> 
> If you are interested in tackling such a project I'm certainly happy to
> provide pointers and review.

Thank you! Yeah I’m definitely going to scratch a prototype for this register reading plugin interface. I’ll take a look at related email discussions.

Best,
-Min

> 
>> 
>> Thank you
>> -Min
> 
> 
> -- 
> Alex Bennée

Re: [RFC] tcg plugin: Additional plugin interface

[Alex Bennée]

Min-Yih Hsu <minyihh@uci.edu> writes:

> Hi Alex,
>
>> On Apr 23, 2021, at 8:44 AM, Alex Bennée <alex.bennee@linaro.org> wrote:
>> 
>> 
>> Min-Yih Hsu <minyihh@uci.edu> writes:
>> 
>>> Hi Alex and QEMU developers,
>>> 
>>> Recently I was working with the TCG plugin. I found that `qemu_plugin_cb_flags` seems to reserve the functionality to
>>> read / write CPU register state, I'm wondering if you can share some
>>> roadmap or thoughts on this feature?
>> 
>> I think reading the CPU register state is certainly on the roadmap,
>> writing registers presents a more philosophical question of if it opens
>> the way to people attempting a GPL bypass via plugins. However reading
>> registers would certainly be a worthwhile addition to the API.
>
> Interesting…I’ve never thought about this problem before.
>
>> 
>>> Personally I see reading the CPU register state as (kind of) low-hanging fruit. The most straightforward way to implement
>>> it will be adding another function that can be called by insn_exec callbacks to read (v)CPU register values. What do you
>>> think about this?
>> 
>> It depends on your definition of low hanging fruit ;-)
>> 
>> Yes the implementation would be a simple helper which could be called
>> from a callback - I don't think we need to limit it to just insn_exec. I
>> think the challenge is proving a non-ugly API that works cleanly across
>> all the architectures. I'm not keen on exposing arbitrary gdb register
>> IDs to the plugins.
>> 
>> There has been some discussion previously on the list which is probably
>> worth reviewing:
>> 
>>  Date: Mon, 7 Dec 2020 16:03:24 -0500
>>  From: Aaron Lindsay <aaron@os.amperecomputing.com>
>>  Subject: Plugin Register Accesses
>>  Message-ID: <X86YnHhHMpQBr2/G@strawberry.localdomain>
>> 
>> But in short I think we need a new subsystem in QEMU where frontends can
>> register registers (sic) and then provide a common API for various
>> users. This common subsystem would then be the source of data for:
>> 
>>  - plugins
>>  - gdbstub
>>  - monitor (info registers)
>>  - -d LOG_CPU logging
>> 
>> If you are interested in tackling such a project I'm certainly happy to
>> provide pointers and review.
>
> Thank you! Yeah I’m definitely going to scratch a prototype for this
> register reading plugin interface. I’ll take a look at related email
> discussions.

Awesome - please CC me on any patches you come up with (as well as
qemu-devel of course ;-).

>
> Best,
> -Min
>
>> 
>>> 
>>> Thank you
>>> -Min
>> 
>> 
>> -- 
>> Alex Bennée


-- 
Alex Bennée

Re: [RFC] tcg plugin: Additional plugin interface

[Aaron Lindsay]

On Apr 26 18:42, Alex Bennée wrote:
> 
> Min-Yih Hsu <minyihh@uci.edu> writes:
> 
> > Hi Alex,
> >
> >> On Apr 23, 2021, at 8:44 AM, Alex Bennée <alex.bennee@linaro.org> wrote:
> >> 
> >> 
> >> Min-Yih Hsu <minyihh@uci.edu> writes:
> >> 
> >>> Hi Alex and QEMU developers,
> >>> 
> >>> Recently I was working with the TCG plugin. I found that `qemu_plugin_cb_flags` seems to reserve the functionality to
> >>> read / write CPU register state, I'm wondering if you can share some
> >>> roadmap or thoughts on this feature?
> >> 
> >> I think reading the CPU register state is certainly on the roadmap,
> >> writing registers presents a more philosophical question of if it opens
> >> the way to people attempting a GPL bypass via plugins. However reading
> >> registers would certainly be a worthwhile addition to the API.
> >
> > Interesting…I’ve never thought about this problem before.
> >
> >> 
> >>> Personally I see reading the CPU register state as (kind of) low-hanging fruit. The most straightforward way to implement
> >>> it will be adding another function that can be called by insn_exec callbacks to read (v)CPU register values. What do you
> >>> think about this?
> >> 
> >> It depends on your definition of low hanging fruit ;-)
> >> 
> >> Yes the implementation would be a simple helper which could be called
> >> from a callback - I don't think we need to limit it to just insn_exec. I
> >> think the challenge is proving a non-ugly API that works cleanly across
> >> all the architectures. I'm not keen on exposing arbitrary gdb register
> >> IDs to the plugins.
> >> 
> >> There has been some discussion previously on the list which is probably
> >> worth reviewing:
> >> 
> >>  Date: Mon, 7 Dec 2020 16:03:24 -0500
> >>  From: Aaron Lindsay <aaron@os.amperecomputing.com>
> >>  Subject: Plugin Register Accesses
> >>  Message-ID: <X86YnHhHMpQBr2/G@strawberry.localdomain>
> >> 
> >> But in short I think we need a new subsystem in QEMU where frontends can
> >> register registers (sic) and then provide a common API for various
> >> users. This common subsystem would then be the source of data for:
> >> 
> >>  - plugins
> >>  - gdbstub
> >>  - monitor (info registers)
> >>  - -d LOG_CPU logging
> >> 
> >> If you are interested in tackling such a project I'm certainly happy to
> >> provide pointers and review.
> >
> > Thank you! Yeah I’m definitely going to scratch a prototype for this
> > register reading plugin interface. I’ll take a look at related email
> > discussions.
> 
> Awesome - please CC me on any patches you come up with (as well as
> qemu-devel of course ;-).

I would love to be copied on any patches as well. I've wanted to look
into doing this properly for some time now, but have not made time.

-Aaron