[PATCH v2 4/4] Exclude TPM ioctls definitions for the GNU/Hurd

[PATCH v2 4/4] Exclude TPM ioctls definitions for the GNU/Hurd

[Manolo de Medici]

The Hurd currently doesn't have any TPM driver, compilation fails
for missing symbols unless these are left undefined.

Signed-off-by: Manolo de Medici <manolo.demedici@gmail.com>
---
 backends/tpm/tpm_ioctl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/backends/tpm/tpm_ioctl.h b/backends/tpm/tpm_ioctl.h
index 1933ab6855..c721bf8847 100644
--- a/backends/tpm/tpm_ioctl.h
+++ b/backends/tpm/tpm_ioctl.h
@@ -274,7 +274,7 @@ typedef struct ptm_lockstorage ptm_lockstorage;
 #define PTM_CAP_SEND_COMMAND_HEADER (1 << 15)
 #define PTM_CAP_LOCK_STORAGE       (1 << 16)

-#ifndef _WIN32
+#if !defined(_WIN32) && !defined(__GNU__)
 enum {
     PTM_GET_CAPABILITY     = _IOR('P', 0, ptm_cap),
     PTM_INIT               = _IOWR('P', 1, ptm_init),
--
2.43.0

Re: [PATCH v2 4/4] Exclude TPM ioctls definitions for the GNU/Hurd

[Peter Maydell]

On Thu, 18 Jan 2024 at 16:04, Manolo de Medici <manolodemedici@gmail.com> wrote:
>
> The Hurd currently doesn't have any TPM driver, compilation fails
> for missing symbols unless these are left undefined.
>
> Signed-off-by: Manolo de Medici <manolo.demedici@gmail.com>
> ---
>  backends/tpm/tpm_ioctl.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/backends/tpm/tpm_ioctl.h b/backends/tpm/tpm_ioctl.h
> index 1933ab6855..c721bf8847 100644
> --- a/backends/tpm/tpm_ioctl.h
> +++ b/backends/tpm/tpm_ioctl.h
> @@ -274,7 +274,7 @@ typedef struct ptm_lockstorage ptm_lockstorage;
>  #define PTM_CAP_SEND_COMMAND_HEADER (1 << 15)
>  #define PTM_CAP_LOCK_STORAGE       (1 << 16)
>
> -#ifndef _WIN32
> +#if !defined(_WIN32) && !defined(__GNU__)
>  enum {
>      PTM_GET_CAPABILITY     = _IOR('P', 0, ptm_cap),
>      PTM_INIT               = _IOWR('P', 1, ptm_init),
> --
> 2.43.0

This looks plausible as a change, but looking at the history
of the file in git it seems like this is a file we import
from a third-party swtpm project.

Stefan: should we get this change made in the swtpm project
too? Or have we diverged from that copy of the header?
If the latter, then the simple thing would be to delete
this enum entirely, because as far as I can see we don't
use any of the values in QEMU, so we can avoid the
portability problem that way.

thanks
-- PMM

Re: [PATCH v2 4/4] Exclude TPM ioctls definitions for the GNU/Hurd

[Stefan Berger]

On 1/22/24 12:16, Peter Maydell wrote:
> On Thu, 18 Jan 2024 at 16:04, Manolo de Medici <manolodemedici@gmail.com> wrote:
>>
>> The Hurd currently doesn't have any TPM driver, compilation fails
>> for missing symbols unless these are left undefined.
>>
>> Signed-off-by: Manolo de Medici <manolo.demedici@gmail.com>
>> ---
>>   backends/tpm/tpm_ioctl.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/backends/tpm/tpm_ioctl.h b/backends/tpm/tpm_ioctl.h
>> index 1933ab6855..c721bf8847 100644
>> --- a/backends/tpm/tpm_ioctl.h
>> +++ b/backends/tpm/tpm_ioctl.h
>> @@ -274,7 +274,7 @@ typedef struct ptm_lockstorage ptm_lockstorage;
>>   #define PTM_CAP_SEND_COMMAND_HEADER (1 << 15)
>>   #define PTM_CAP_LOCK_STORAGE       (1 << 16)
>>
>> -#ifndef _WIN32
>> +#if !defined(_WIN32) && !defined(__GNU__)
>>   enum {
>>       PTM_GET_CAPABILITY     = _IOR('P', 0, ptm_cap),
>>       PTM_INIT               = _IOWR('P', 1, ptm_init),
>> --
>> 2.43.0
> 
> This looks plausible as a change, but looking at the history
> of the file in git it seems like this is a file we import
> from a third-party swtpm project.
> 
> Stefan: should we get this change made in the swtpm project
> too? Or have we diverged from that copy of the header?

The diffs are minimal at the moment:
$ diff swtpm/include/swtpm/tpm_ioctl.h qemu/backends/tpm/tpm_ioctl.h
15,16d14
< #include <stdint.h>
< #include <sys/types.h>

Since we already handle _WIN32 we can just take this case for __GNU__.

   Stefan

> If the latter, then the simple thing woud be to delete
> this enum entirely, because as far as I can see we don't
> use any of the values in QEMU, so we can avoid the
> portability problem that way.
> 
> thanks
> -- PMM
> 

Re: [PATCH v2 4/4] Exclude TPM ioctls definitions for the GNU/Hurd

[Peter Maydell]

On Mon, 22 Jan 2024 at 19:30, Stefan Berger <stefanb@linux.ibm.com> wrote:
>
>
>
> On 1/22/24 12:16, Peter Maydell wrote:
> > On Thu, 18 Jan 2024 at 16:04, Manolo de Medici <manolodemedici@gmail.com> wrote:
> >>
> >> The Hurd currently doesn't have any TPM driver, compilation fails
> >> for missing symbols unless these are left undefined.
> >>
> >> Signed-off-by: Manolo de Medici <manolo.demedici@gmail.com>
> >> ---
> >>   backends/tpm/tpm_ioctl.h | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/backends/tpm/tpm_ioctl.h b/backends/tpm/tpm_ioctl.h
> >> index 1933ab6855..c721bf8847 100644
> >> --- a/backends/tpm/tpm_ioctl.h
> >> +++ b/backends/tpm/tpm_ioctl.h
> >> @@ -274,7 +274,7 @@ typedef struct ptm_lockstorage ptm_lockstorage;
> >>   #define PTM_CAP_SEND_COMMAND_HEADER (1 << 15)
> >>   #define PTM_CAP_LOCK_STORAGE       (1 << 16)
> >>
> >> -#ifndef _WIN32
> >> +#if !defined(_WIN32) && !defined(__GNU__)
> >>   enum {
> >>       PTM_GET_CAPABILITY     = _IOR('P', 0, ptm_cap),
> >>       PTM_INIT               = _IOWR('P', 1, ptm_init),
> >> --
> >> 2.43.0
> >
> > This looks plausible as a change, but looking at the history
> > of the file in git it seems like this is a file we import
> > from a third-party swtpm project.
> >
> > Stefan: should we get this change made in the swtpm project
> > too? Or have we diverged from that copy of the header?
>
> The diffs are minimal at the moment:
> $ diff swtpm/include/swtpm/tpm_ioctl.h qemu/backends/tpm/tpm_ioctl.h
> 15,16d14
> < #include <stdint.h>
> < #include <sys/types.h>
>
> Since we already handle _WIN32 we can just take this case for __GNU__.

OK, so how should we handle the mechanics of it -- just take
this commit in QEMU and then you'll sort it out in swtpm?
Or do we need to change swtpm first and then sync?

thanks
-- PMM

Re: [PATCH v2 4/4] Exclude TPM ioctls definitions for the GNU/Hurd

[Stefan Berger]

On 1/22/24 15:46, Peter Maydell wrote:
> On Mon, 22 Jan 2024 at 19:30, Stefan Berger <stefanb@linux.ibm.com> wrote:
>>
>>
>>
>> On 1/22/24 12:16, Peter Maydell wrote:
>>> On Thu, 18 Jan 2024 at 16:04, Manolo de Medici <manolodemedici@gmail.com> wrote:
>>>>
>>>> The Hurd currently doesn't have any TPM driver, compilation fails
>>>> for missing symbols unless these are left undefined.
>>>>
>>>> Signed-off-by: Manolo de Medici <manolo.demedici@gmail.com>
>>>> ---
>>>>    backends/tpm/tpm_ioctl.h | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/backends/tpm/tpm_ioctl.h b/backends/tpm/tpm_ioctl.h
>>>> index 1933ab6855..c721bf8847 100644
>>>> --- a/backends/tpm/tpm_ioctl.h
>>>> +++ b/backends/tpm/tpm_ioctl.h
>>>> @@ -274,7 +274,7 @@ typedef struct ptm_lockstorage ptm_lockstorage;
>>>>    #define PTM_CAP_SEND_COMMAND_HEADER (1 << 15)
>>>>    #define PTM_CAP_LOCK_STORAGE       (1 << 16)
>>>>
>>>> -#ifndef _WIN32
>>>> +#if !defined(_WIN32) && !defined(__GNU__)
>>>>    enum {
>>>>        PTM_GET_CAPABILITY     = _IOR('P', 0, ptm_cap),
>>>>        PTM_INIT               = _IOWR('P', 1, ptm_init),
>>>> --
>>>> 2.43.0
>>>
>>> This looks plausible as a change, but looking at the history
>>> of the file in git it seems like this is a file we import
>>> from a third-party swtpm project.
>>>
>>> Stefan: should we get this change made in the swtpm project
>>> too? Or have we diverged from that copy of the header?
>>
>> The diffs are minimal at the moment:
>> $ diff swtpm/include/swtpm/tpm_ioctl.h qemu/backends/tpm/tpm_ioctl.h
>> 15,16d14
>> < #include <stdint.h>
>> < #include <sys/types.h>
>>
>> Since we already handle _WIN32 we can just take this case for __GNU__.
> 
> OK, so how should we handle the mechanics of it -- just take
> this commit in QEMU and then you'll sort it out in swtpm?

Yes.

> Or do we need to change swtpm first and then sync?

No.

Regarding the patch:

Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>

> 
> thanks
> -- PMM