From gniibe at fsij.org  Fri Feb  1 14:47:41 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 01 Feb 2019 22:47:41 +0900
Subject: FOSDEM and FST-01SZ
In-Reply-To: <20190131122325.zt53hpf72b6uldgo@earth.li>
References: <874l9pe0wi.fsf@c720> <20190131122325.zt53hpf72b6uldgo@earth.li>
Message-ID: <87zhrfy60y.fsf@c720>

Jonathan McDowell <noodles at earth.li> wrote:
> Very nice!

Glad to hear that. :-)

> Now my only wishlist item missing is a button to confirm signing.

Yes, I remember.

Since I put a hall effect sensor on FST-01SZ, you can use magnet
movement to acknowledge signing/decryption/authentication request from
host PC.  It is a feature added in OpenPGPcard specification, and
recent GnuPG 2.2 supports this, with pop-up window to notify a user,
if you use internal CCID driver.

I'm testing FST-01SZ prototype + magnet for five months.  My opinion is:
for me, enabling the interaction for singing/authentication makes sense
in some situations, but it is questionable for decryption, because my
practice is removing Gnuk Token when not needed, and I don't want to
move off my hands from keyboard to acknowledge decryption.

My decision is not a button but a hall effect sensor, because I have an
experience (with FS-BB48), having button on a surface of a board is not
good for electrical connection of USB.  And having capacitive touch
button on a edge is difficult for me.

I hope you can use a magnet for the interaction.

> Do you have any idea what pricing for the new device + case is likely
> to be?

At FOSDEM, from me, it is 30 Euro.  Please note that I only have 10
cases this time (I got them as sample), and there is no logo on that
(GnuPG, Gnuk, or whatever).  I bring plenty of FST-01SZ, it is 25 Euro.

I wish I will able to arrange the order of metal case, in order to ask
distribution of FST-01SZ + case from FSF (as same price setting as
FST-01 and FST-01G).  Now I'm not sure if I can put some logo (the
number matters!).  It may be with no logo.

Note that FST-01G is still available from FSF.  I only have a few of
them.
-- 


From tomli at tomli.me  Wed Feb  6 18:54:41 2019
From: tomli at tomli.me (Tom Li)
Date: Thu, 7 Feb 2019 01:54:41 +0800
Subject: Utilizing Memory Protection Unit on STM32?
Message-ID: <20190206175441.GA17636@localhost.localdomain>

Hello.

It's clear on the datasheet that the Cortex M3-series of microcontroller
cores have an optional Memory Protection Unit (MPU), which is provided
by both STM32 and GD32's chips. Having a memory protection mechanism
can help reducing the impact of an accidental buffer overflows in gnuk,
thus improving security.

I'm still new to the Cortex M3 architecture. My question is, how feasible
is it to introduce new code to utilize the memory protection unit? Can
we simply mark the stack of each chopstx process as non-executable? If
it's difficult, what is the main obstacle preventing it from being
used? It seems to me, that the memory region-based model may potentially
be somewhat inflexible to deal with.

Thanks! And congrat on the successful production of FST-01SZ, I wish you
are enjoying the FOSDEM conference of this year.

Tom Li
Beijing GNU/Linux User Group
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190207/25cf77d0/attachment.sig>

From peter at digitalbrains.com  Wed Feb  6 20:47:23 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 6 Feb 2019 20:47:23 +0100
Subject: Utilizing Memory Protection Unit on STM32?
In-Reply-To: <20190206175441.GA17636@localhost.localdomain>
References: <20190206175441.GA17636@localhost.localdomain>
Message-ID: <b08f0997-b51b-916b-0da8-8b01776bed85@digitalbrains.com>

On 06/02/2019 18:54, Tom Li via Gnuk-users wrote:
> It's clear on the datasheet that the Cortex M3-series of microcontroller
> cores have an optional Memory Protection Unit (MPU), which is provided
> by both STM32 and GD32's chips.

Are you sure? The Cortex-M3 Programming Manual (PM0056) says:

> Refer to the corresponding device datasheet to see if the MPU is
> present in the STM32 type you are using.

If we now compare the datasheet for the STM32F103CB, the medium-density
device used in the GnuK, to an XL-density device like the STM32F103RFT,
I notice that the former has the following subsections of section 2.3:

| 2.3 Overview
| 2.3.1 ARM ? Cortex ? -M3 core with embedded Flash and SRAM
| 2.3.2 Embedded Flash memory
| 2.3.3 CRC (cyclic redundancy check) calculation unit
| 2.3.4 Embedded SRAM
| [...]

Whereas the latter, the XL-density part has:

| 2.3 Overview
| 2.3.1 ARM? Cortex?-M3 core with embedded Flash and SRAM
| 2.3.2 Memory protection
| 2.3.3 Embedded Flash memory
| 2.3.4 CRC (cyclic redundancy check) calculation unit
| 2.3.5 Embedded SRAM
| [...]

I must say, they could have presented this information in a much easier
way, but I think you're mistaken that the 103CB has an MPU. It's too
bad.

I also looked at the datasheet for a high-density device (in between the
103CB and the 103RFT), but it seemed to be missing the MPU as well.

I didn't check the GD32 part, but it would be quite a hefty upgrade if
they chose to include the MPU silicon on their version of the 103CB!

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190206/ad8fbb70/attachment.sig>

From tomli at tomli.me  Wed Feb  6 21:31:18 2019
From: tomli at tomli.me (Tom Li)
Date: Thu, 7 Feb 2019 04:31:18 +0800
Subject: Utilizing Memory Protection Unit on STM32?
In-Reply-To: <b08f0997-b51b-916b-0da8-8b01776bed85@digitalbrains.com>
References: <20190206175441.GA17636@localhost.localdomain>
 <b08f0997-b51b-916b-0da8-8b01776bed85@digitalbrains.com>
Message-ID: <20190206203118.GC17636@localhost.localdomain>

On Wed, Feb 06, 2019 at 08:47:23PM +0100, Peter Lebbing wrote:
> On 06/02/2019 18:54, Tom Li via Gnuk-users wrote:
> > It's clear on the datasheet that the Cortex M3-series of microcontroller
> > cores have an optional Memory Protection Unit (MPU), which is provided
> > by both STM32 and GD32's chips.
> 
> Are you sure? The Cortex-M3 Programming Manual (PM0056) says:
> [...]
>
> I also looked at the datasheet for a high-density device (in between the
> 103CB and the 103RFT), but it seemed to be missing the MPU as well.
> 
> I didn't check the GD32 part, but it would be quite a hefty upgrade if
> they chose to include the MPU silicon on their version of the 103CB!
> 
> HTH,
> 
> Peter.

Oops, Nevermind. I'm wrong.

I've just reviewed the GD32F103 datasheet, it only does mention the Memory
Protection Unit, but it only says the MPU can be provided by Cortex-M3 core
without additional notes. So it's not in fact supported.

I was reviewing a bunch of different datasheets in a Sunday afternoon in
2018, including F and L series from different vendor. The bulletpoint of
the MPU in GD32 datasheet probably confused me and I mixed them up.

Tom Li
Beijing GNU/Linux User Group.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190207/b6860792/attachment.sig>

From peter at digitalbrains.com  Thu Feb  7 17:06:30 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 7 Feb 2019 17:06:30 +0100
Subject: Where to buy 128K st-links?
In-Reply-To: <20181223123415.aitpxwk4jkxejo4g@kartoffel.localdomain>
References: <20181223123415.aitpxwk4jkxejo4g@kartoffel.localdomain>
Message-ID: <5f6af451-929e-1a02-97be-d341d12e6e14@digitalbrains.com>

On 23/12/2018 13:34, Pablo Ovelleiro Corral wrote:
> Can anybody link me to a suppliers of those chips that delivers the
> 128K flash version? Has anybody build this and can share his
> experieces and where he got the device?

I was curious about chips other than the STM32F103CB capable of being
used as though they were, and these things are cheap. So I bought the
following three:

https://www.aliexpress.com/item/1Set-ST-LINK-Stlink-ST-Link-V2-Mini-STM8-STM32-Simulator-Download-Programmer-Programming-With-Cover/32869967486.html

https://www.aliexpress.com/item/ST-LINK-Stlink-ST-Link-V2-Mini-STM8-STM32-Simulator-Download-Programmer-Programming-with-Cover/32921831799.html

https://www.aliexpress.com/item/ST-Link-V2-new-stlink-mini-STM8STM32-STLINK-simulator-download-programming-With-Cover/32719963657.html

Now, I just /might/ have mixed them up upon reception, but I don't think
so. The first two have an STM32F103C8, which is officially the 64 KiB
version, but in all likelihood have 128 KiB.

The third one, the one from the WAVGAT Store, was more interesting. It
has a chip marked

| STM32
| GC102CB
| GH213 9U
| CHNO46

which you can see here:

http://digitalbrains.com/tmp/WAVGAT-ST-Link-v2-?C

I couldn't find what a GC102 is, does anybody know? Anyway, it reports
itself as a medium-density F10x does. I kinda forgot to save the log of
that OpenOCD session, but here is the output for a proper STM32F103CB:

| SWD IDCODE 0x1ba01477
| > flash probe 0
| device id = 0x20036410
| flash size = 128kbytes
| flash 'stm32f1x' found at 0x08000000

And I remember that this GC102CB reported the same numbers.

I checked the memory, and it has 128 KiB of flash and 20 KiB of RAM. I
used SWD to fill both memories with 32-bit words containing the word
address being programmed as the data, and I could read it back
succesfully. So the first word programmed to memory was 0x00000000, the
second word 0x00000001, etcetera. This should catch any address aliasing
occurring, and it worked fine. As soon as you tried to write beyond the
20 KiB RAM, OpenOCD would throw an error.

I flashed this thing with GnuK and am using it to see if there are any
(stability?) issues. It works, *but* I did notice that reGNUal failed!
So it is not 100% equal to an F103CB.

So if you order one of the others, you have a fair chance of receiving a
F103C8, which should be 128 KiB despite it not being marked as such. I
ordered another 5 from different suppliers to see what I'll get. I think
it's interesting to look at to what extent these chips that are marked
differently are usable, but I'm not giving it any priority at the
moment.

Does anybody know what the *bleep* an STM32GC102 is? What are
interesting registers to look at? I see the SWD IDCODE, the
DBGMCU_IDCODE register at 0xE0042000 (that's "device id" in the output
above) and the Flash size register at 0x1FFFF7E0, are there any more
interesting ones? I plan to compare a complete register space dump in
the future, but if it's too noisy I'll forego that avenue. I'm
currently using the device as a GnuK, so I can't do anything with it at
the moment.

This ST-Link V2 with the GC102 chip is running a normal GnuK fine, it's
config string is
Config: ST_DONGLE:dfu=no:debug=no:pinpad=no:certdo=yes:factory_reset=yes

I've seen people say they lowered the CPU clock frequency. I didn't
change a thing, so it's probably running at the normal 72 MHz, because I
think the USB will not work if the crystal doesn't match. So apparently
it matches.

This mail is signed with the device in question :-).

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190207/b155dcb3/attachment.sig>

From dmanriq at gmail.com  Fri Feb 22 16:15:54 2019
From: dmanriq at gmail.com (Daniel Manrique)
Date: Fri, 22 Feb 2019 10:15:54 -0500
Subject: Private data objects
Message-ID: <CAF680uegS=BXpJ3ATSWVbvig=7iEKECnQqPefpD_6rsW+JxHdQ@mail.gmail.com>

Hi,

I've been testing gnuk on a st-link stick for some weeks now. In general it
works pretty well. I'm very happy with it and very grateful for Niibe's
great work.

One thing that I've noted is that gnuk doesn't seem to implement the
private data objects (DO1-4) from the openpgp card specification. In my
case that's what currently prevents me to fully adopt gnuk instead of still
relying on a smartcard.

My question is: are there plans to implement the private data objects? how
difficult would be to do it?

Thank you very much for your help!

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190222/949a2859/attachment.html>