[Gnuk-users] [PATCH 0/7] Gnuk: add support for Cortex M4 MCU
NIIBE Yutaka
gniibe at fsij.org
Tue Oct 17 00:07:32 UTC 2017
Aurelien Jarno <aurelien at aurel32.net> wrote:
> I am fine with releasing my changes under GPLv3+, and I understand the
> agreement with USB-IF. Actually I fully understand it's not directly
> related to FSIJ and Gnuk, many hardware projects got the issue. Some
> projects had a more liberal usage of their VID than Gnuk (like giving
> or selling PID), and since then the USB-IF has been more strong to make
> sure everybody follows the agreement.
Thank you.
The condition of non-use of VID is _not_ by (the power of) copyright of
FSIJ. FSIJ asks non-use of their VID, because of the agreement. I
think that if it were based on copyright, it contradicts free software
license.
Yesterday, I was told about Openmoko Inc. [0]
[0] http://wiki.openmoko.org/wiki/USB_Product_IDs
IIUC, they can do that, because they no longer have plan to release
products any more. Such "tranfer" (from my viewpoint) could have risk
of ban from USB-IF. For assignee which distributes hardware products,
I think that it is not possible to do that.
Well, if someone will get PID from [0] and he will ask adding a line to
gnuk/GNUK_USB_DEVICE_ID, I won't have any reason to reject that.
>> Speaking about my own situation, once, I have said publicly that my code
>> should be 100% free software, always. (I didn't expect I encounter such
>> a tricky situation.) One of the reasons why I assign my work for Gnuk
>> to FSIJ is to keep sane myself. :-)
>
> From what I understand I don't have to assign my work for Gnuk to FSIJ,
> correct?
No, it's not the requirement for contributors, while I recommend
assignment to FSIJ. I don't explicitly advertise the non-requirement.
When asked, I answer.
That's because... if excessively conservertive for the interpretation of
the agreement between USB-IF, it would be possible to interpret:
accepting any patches means virtually "transfer"ring something.
> When looking at the whole picture, Gnuk is using a very small subset of
> PolarSSL.
Yes. AES and RSA. And RSA is heavily modified.
> It might make sense to submit the MULADDC part to mbedTLS, especially
> now that the upstream has changed. However it depends on the changes you
> have done to directly use the pointers in the asm code instead of
> copying them first into registers. I'll see if I can find some spare
> time to do that.
Let's see.
As I wrote in the previous mail, mbedTLS adopted RSA blinding (base and
exponent). I know that that's considered a best practice for RSA
implementation these days (against attacks), as we can see BSI (in
Germany) document.
Gnuk cares much on constant-time implementation of RSA, and not use
blinding. When I talked to the upstream of mbedTLS, they didn't have
much interest on constant-time implementation of RSA, it seemed.
If someone really wants to use Gnuk on GNU/Linux, we need to replace
current RSA implementation. Apparently, it's not safe against some sort
of side channel attacks on usual architecture.
Only for STM32F103, I do my best to be more constant-time ("more" means
it's not perfect).
That's the situation.
The work for merging from/to upstream will be welcome as long as Gnuk on
STM32F103 keep working great.
--
More information about the gnuk-users
mailing list