From simon at josefsson.org Sat Aug 11 23:39:49 2018 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 11 Aug 2018 23:39:49 +0200 Subject: Buying FST-01(G)? Message-ID: <874lg0shui.fsf@latte.josefsson.org> Hello, README says FST-01 (Flying Stone Tiny 01) is available for sale, and it is a kind of the best choice, hopefully. however I cannot find FST-01 on Seedstudio anymore. What happened? I can find FST-01 (or likely FST-01G?) through FSF: https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator however it isn't clear to me whether I can put Gnuk on it. What's the best recommended hardware to run Gnuk on? Any chance of getting any hardware RYF certified? :) Thanks, /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From gniibe at fsij.org Sun Aug 12 07:08:37 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sun, 12 Aug 2018 14:08:37 +0900 Subject: Buying FST-01(G)? In-Reply-To: <874lg0shui.fsf@latte.josefsson.org> References: <874lg0shui.fsf@latte.josefsson.org> Message-ID: <87a7ps9noq.fsf@fsij.org> Simon Josefsson wrote: > however I cannot find FST-01 on Seedstudio anymore. What happened? For FST-01 (2010 to 2015), Seeed had kindly offered me an option selling at their SeeedStudio.com. For not-selling-much product like FST-01 (10 to 20 per month), this option is not available now. After sold out of FST-01, I manufactured FST-01G (by Seeed Technology) last year. It is not available at SeeedStudio.com. And... > I can find FST-01 (or likely FST-01G?) through FSF: > > https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator > > however it isn't clear to me whether I can put Gnuk on it. Yes. It is FST-01G now. This is an only stable distribution channel. I personally bring FST-01G at FOSDEM or Debconf. With the product from FSF, you can flash Gnuk by youself. It has NeuG instead, now. It must be the best if it has Gnuk, but I wonder if it would cause export/import problem around crypto product. I was taught that newer ECC would be risky for China, for example. > What's the best recommended hardware to run Gnuk on? I believe FST-01G is the best, if you like current enclosure, or you can make your own enclosure. I value how it is reproducible by other party. I don't know other products, which BOM and test plan are available to public. This summer, I am trying new PCB with a bit smaller size, to match Chinese de-facto standard called "wristband USB" with GD32F103. > Any chance of getting any hardware RYF certified? :) In 2014, I asked FSF. I brought two FST-01 to John at Debconf14. At that time, such a device was not in the scope of RYF, I suppose. I felt that I only got some negative response (like manufacturing process required proprietary tool of ST-Link/V2), while that was actually relevant. FST-01G was manufactured using BeagleBone Green with my BBG-SWD. So, I think that it would be worth to ask again. Well, staff members at FSF have been changed, since then. -- From tomli at tomli.me Tue Aug 14 19:58:18 2018 From: tomli at tomli.me (tomli at tomli.me) Date: Wed, 15 Aug 2018 01:58:18 +0800 Subject: Correction about the Flash Zero-Wait on GD32F103 Message-ID: <20180814175818.GA865794@x220> Hello. In the email I sent in Feburary, https://lists.gnupg.org/pipermail/gnuk-users/2018-March/000021.html I described the operation of the flash memory of GD32F103 as, > In addition, the access time for data behind of first 32 KiB is slow, > one should put timing-crtitial data at the beginning of the flash chip. Now it turned out to be a complete mistake. I confused and mixed the datasheet of GD32F103, and GD32F130, whith is another series of low-cost microcontroller based on Cortex-M3. In fact, page 22 (physical page 46) of the GD32F1x0 datasheet reads, > Up to 64KB of on-chip flash memory for storing instruction/data > No waiting time within 32K bytes when CPU executes instruction > A long delay when fetch 32K ~ 64K bytes date from flash But page 44 of the GD32F10x datasheet reads, > Up to 3072KB of on-chip flash memory for instruction and data. > No waiting time within first 256K bytes when CPU executes instructions. > A long delay when CPU fetches the instructions out of the range. In conclusion, while the flash memory of GD32F130 only has zero-wait access within the 32 KiB range, the flash memory of GD32F103, the chip we are testing, should have complete zero-wait access within the range of 256 KiB, which essentially means the whole flash memory is zero-wait, since we are not using high-density models. Therefore, we should be able to use this chip without worrying about incompatibility, or timing attacks. Sorry for the previous misinformation. BTW, I have confirmed on my board that the updated Chopstx and Gnuk is indeed working correctly. Thanks for your hard-work. I guess it's the right time to upstream the OpenOCD patches for GD32 development. Happy Hacking, Tom Li Beijing GNU/Linux User Group -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: Digital signature URL: From mrtijn at riseup.net Wed Aug 15 16:49:57 2018 From: mrtijn at riseup.net (Martijn) Date: Wed, 15 Aug 2018 16:49:57 +0200 Subject: NeuG on the STlink v2? Message-ID: <20180815164957.561a5e43@Martijn-T480> Hello, I found this [0] blog post online describing the process to install Gnuk on the STlink v2, an in-circuit programmer/debugger for STM chips which also uses the STM32F103. Would it also be possible to compile and install NeuG in a similar fashion on an STlink v2? Thanks in advance. Kind regards, Martijn [0] https://blog.danman.eu/2-usb-crypto-token-for-use-with-gpg-and-ssh/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Thu Aug 16 02:44:00 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 16 Aug 2018 09:44:00 +0900 Subject: NeuG on the STlink v2? In-Reply-To: <20180815164957.561a5e43@Martijn-T480> References: <20180815164957.561a5e43@Martijn-T480> Message-ID: <87d0uj9m3z.fsf@iwagami.gniibe.org> Martijn wrote: > I found this [0] blog post online describing the process to install Gnuk on > the STlink v2, an in-circuit programmer/debugger for STM chips which also uses > the STM32F103. Would it also be possible to compile and install NeuG in a > similar fashion on an STlink v2? Yes. The hardware requirement of Gnuk and NeuG standalone device is same; MCU should be STM32F103 or GD32F103. It only uses ADC and USB. If it can run Gnuk, NeuG also can run. For your board, you need clock configuration (usually, 8MHz or 12MHz) and how to enable USB, and how to control LED. Well, there is one corner case. While STM32F103 has 64KiB flash ROM version, it actually has 128KiB, thus, you can install Gnuk on that. A version of GD32F103 seems to have only 64KiB, really. On this MCU, you can install NeuG (with no Fraucheky support), but you can't install Gnuk. Please note that there are multiple products for ST-Link/V2 clone. So, configuration may differ. -- From simon at josefsson.org Sun Aug 19 23:34:51 2018 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 19 Aug 2018 23:34:51 +0200 Subject: Buying FST-01(G)? In-Reply-To: <87a7ps9noq.fsf@fsij.org> References: <874lg0shui.fsf@latte.josefsson.org> <87a7ps9noq.fsf@fsij.org> Message-ID: <1534714491.20476.3.camel@josefsson.org> s?n 2018-08-12 klockan 14:08 +0900 skrev NIIBE Yutaka: > I can find FST-01 (or likely FST-01G?)??through FSF: > > Yes.??It is FST-01G now.??This is an only stable distribution > channel. > I personally bring FST-01G at FOSDEM or Debconf. > > With the product from FSF, you can flash Gnuk by youself. Thanks for confirming this! > Any chance of getting any hardware RYF certified? :) > > In 2014, I asked FSF.??I brought two FST-01 to John at Debconf14.??At > that time, such a device was not in the scope of RYF, I suppose.??I > felt > that I only got some negative response (like manufacturing process > required proprietary tool of ST-Link/V2), while that was actually > relevant. > > FST-01G was manufactured using BeagleBone Green with my BBG-SWD.??So, > I think that it would be worth to ask again.??Well, staff members at > FSF have been changed, since then. Do you think BBG would pass RYF? Otherwise I see little difference compared to ST-Link/V2. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From gniibe at fsij.org Mon Aug 20 05:00:31 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 20 Aug 2018 12:00:31 +0900 Subject: Buying FST-01(G)? In-Reply-To: <1534714491.20476.3.camel@josefsson.org> References: <874lg0shui.fsf@latte.josefsson.org> <87a7ps9noq.fsf@fsij.org> <1534714491.20476.3.camel@josefsson.org> Message-ID: <877eklivxs.fsf@iwagami.gniibe.org> Simon Josefsson wrote: > Do you think BBG would pass RYF? I don't know, but I think it's not that far, by looking https://www.fsf.org/resources/hw/single-board-computers BBG or PocketBeagle is a bit better than original BeagleBone Black, since it doesn't assume using video output. I think that we can use it with fully free software environment. For the hardware reproducibility with free software (with possible modification), it is a bit difficult (yet). We can find some resources here: http://wiki.seeedstudio.com/BeagleBone_Green/ While schematic and PCB design is available, the hardware design was done by OrCAD, which is proprietary software. > Otherwise I see little difference compared to ST-Link/V2. Firstly, there is one step techinical difference. Perhaps, it would be also relevant from the viewpoint of RYF. That is: We can control BBG-SWD on BBG better than ST-Link/V2. Our use of ST-Link/V2 is based on reverse engineering, so, while it works somehow, but it's far from perfect. If we focus on the firmware of JTAG/SWD device, comparison between DAPLink and the firmware of ST-Link/V2 is more relevant. (DAPLink is free software, which is supported by ARM.) Device with DAPLink is better than ST-Link/V2. If an engineer asks a device for his computer with Debian, I would suggest a device with DAPLink. Secondly, for me, BBG-SWD has practical technical benefit when I ask flashing at a factory. When their computer runs proprietary operating system, even if it's a device with DAPLink, I don't know how we can practically protect against possible mistake/attack, While I cannot ask use of free operating system on their computer, asking use of BBG is possible. I prepare microSD with Debian and BBG-SWD, and ask them to run a program to flash FST-01G with BBG. And... I did that and they did accept my test plan for FST-01G production. Still, BBG is connected to a computer with a proprietary operating system, that's true, but possible mistake/attack are limited. This point would be out of scope for RYF. This is an argument of how we can receive free software firmware reliably. More argument is possible for logistics. Besides, I was asked about how we can get anonymously. My answer was: Please join LibrePlanet, FOSDEM and/or Debconf, or you can ask PCBA and flashing by yourself. -- From gniibe at fsij.org Wed Aug 22 07:42:57 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 22 Aug 2018 14:42:57 +0900 Subject: Correction about the Flash Zero-Wait on GD32F103 In-Reply-To: <20180814175818.GA865794@x220> References: <20180814175818.GA865794@x220> Message-ID: <87d0ubklcu.fsf@iwagami.gniibe.org> tomli at tomli.me wrote: > Therefore, we should be able to use this chip without worrying > about incompatibility, or timing attacks. Thanks for your update. > BTW, I have confirmed on my board that the updated Chopstx and Gnuk > is indeed working correctly. Thanks for your hard-work. I guess it's > the right time to upstream the OpenOCD patches for GD32 development. Today, I released BBG-SWD version 0.04. For me, normal flash write with OpenOCD mostly works without specific change for GD32F103. My problem was that: When I tried to erase all flash by > flash erase_sector 0 0 127 It failed. When I did for pages by pages, I managed to erase all pages. In February, your change was, iiuc, timing change and 32-bit access change. I think that latter may not be needed. -- From tomli at tomli.me Thu Aug 23 04:57:48 2018 From: tomli at tomli.me (tomli at tomli.me) Date: Thu, 23 Aug 2018 10:57:48 +0800 Subject: How to Implement I2C on Chopstx? Message-ID: <20180823025748.GA536661@x220> Hi gniibe, Recently I've done a little bit of further research about using an additional ATECC508A crypto chip for improved security. Although there are some difficulties but I was able to hack a solution, now the results looks promising. I will publish the technical details after I finish my reseach. I was working on the software protocol part and all the development was done on GNU/Linux. Now, logically the next step would be working with the actual hardware. In order to control the chip, an I2C driver should be implemented in Chopstx. But I don't understand the design and architecture of Chopstx, nor have any experience about working on the "bare-metal" STM32 hardware without using a high-level HAL library like STM32Cube or libopencm3, I have lots of things to learn. From my understanding, the I2C subsystem on STM32F103 has three modes, polling, interrupt, and DMA. Since I2C communication is only needed just before the private keys are decrypted by DEK - at this point there is no other tasks to do - I think we don't need to use interrupt or DMA to implement non-blocking asynchronous I2C operation, we can block the whole firmware and perform I2C reads/writes by busy-waiting and polling until we finish the job. But I don't understand about how interrupts, threads, context-switching or USB communication is handled in Chopstix. Is it really okay to implement I2C in this way? Is it going to break other things in Chopstx? Do you have more suggestions and resources for the I2C implementation? Thanks, Tom Li Beijing GNU/Linux User Group -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: Digital signature URL: From gniibe at fsij.org Thu Aug 23 08:39:42 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 23 Aug 2018 15:39:42 +0900 Subject: How to Implement I2C on Chopstx? In-Reply-To: <20180823025748.GA536661@x220> References: <20180823025748.GA536661@x220> Message-ID: <87zhxdbn81.fsf@iwagami.gniibe.org> tomli at tomli.me wrote: > using a high-level HAL library > like STM32Cube or libopencm3, I have lots of things to learn. Well, you would need to unlearn things, perhaps. > I think > we don't need to use interrupt or DMA to implement non-blocking asynchronous > I2C operation, we can block the whole firmware and perform I2C reads/writes by > busy-waiting and polling until we finish the job. That sounds more difficult for me. Why not simply implement the driver by DMA with an interrupt notification for DMA finish? Do you intend to use it connecting your board through USB? If so, USB protocol requires the board should respond to host. I'd suggest to read chopstx/example-usb-serial and chopstx/contrib/usart-stm32f103.c, as well as the Chopstx Reference Manual. -- From tomli at tomli.me Thu Aug 23 19:27:48 2018 From: tomli at tomli.me (tomli at tomli.me) Date: Fri, 24 Aug 2018 01:27:48 +0800 Subject: How to Implement I2C on Chopstx? In-Reply-To: <87zhxdbn81.fsf@iwagami.gniibe.org> References: <20180823025748.GA536661@x220> <87zhxdbn81.fsf@iwagami.gniibe.org> Message-ID: <20180823172748.GA970695@x220> > > using a high-level HAL library > > like STM32Cube or libopencm3, I have lots of things to learn. > > Well, you would need to unlearn things, perhaps. Yes, that's right. It reminds me the experience of learning Dvorak keyboard layout during the first two months ;-) > > I think > > we don't need to use interrupt or DMA to implement non-blocking asynchronous > > I2C operation, we can block the whole firmware and perform I2C reads/writes by > > busy-waiting and polling until we finish the job. > > That sounds more difficult for me. Why not simply implement the > driver by DMA with an interrupt notification for DMA finish? > > Do you intend to use it connecting your board through USB? If so, USB > protocol requires the board should respond to host. I understand the idea now. Using DMA with an interrupt allows an "event-driven" way of development, which is easier to manage than busy-polling in a multithreaded environment. > I'd suggest to read chopstx/example-usb-serial and > chopstx/contrib/usart-stm32f103.c, as well as the Chopstx Reference > Manual. Thanks for your advice. I've looked through the USART code, and noticed all the reads/writes are threaded in a producer-consumer model with a ring buffer. Is it designed for full-deplex opeartion? In I2C, the protocol is half-deplex with predefined message format, so I think it's the whole driver can be implemented with a fixed-size buffer in a single thread. Is my understanding correct? Happy Hacking, Tom Li Beijing GNU/Linux User Group -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: Digital signature URL: From gniibe at fsij.org Fri Aug 24 09:53:23 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 24 Aug 2018 16:53:23 +0900 Subject: How to Implement I2C on Chopstx? In-Reply-To: <20180823172748.GA970695@x220> References: <20180823025748.GA536661@x220> <87zhxdbn81.fsf@iwagami.gniibe.org> <20180823172748.GA970695@x220> Message-ID: <87in40urnw.fsf@fsij.org> tomli at tomli.me wrote: > the whole driver can be implemented with a fixed-size buffer in > a single thread. Is my understanding correct? Right. My experience for I2C was more than ten years ago, though. -- From bertrand at jacquin.bzh Sun Aug 26 03:13:06 2018 From: bertrand at jacquin.bzh (Bertrand Jacquin) Date: Sun, 26 Aug 2018 02:13:06 +0100 Subject: Gnuk and max-cache-ttl Message-ID: <20180826011305.GB9207@lady-voodoo.scabb> Hi, I've noticed this issue since a long time but never reported it yet. I have the following configuration defined in ~/.gnupg/gpg-agent.conf to ensure the passphrase of my gnuk is not kept too long in gpg-agent memory: default-cache-ttl 600 default-cache-ttl-ssh 600 max-cache-ttl 600 max-cache-ttl-ssh 600 It seems that none of these parameters are properly respected, if I leave my computer alive for more than 4 hours, no passphrase is asked to me again when I use gpg-agent as a ssh-agent and connecting to a remote host using SSH. I am currently using gnupg 2.2.8. Note that this issue does not happen with software gnupg keys. Is this is a known issue ? Cheers -- Bertrand -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Digital signature URL: From bertrand at jacquin.bzh Sun Aug 26 03:08:48 2018 From: bertrand at jacquin.bzh (Bertrand Jacquin) Date: Sun, 26 Aug 2018 02:08:48 +0100 Subject: Gnuk with GCC >= 5 Message-ID: <20180826010848.GA9207@lady-voodoo.scabb> Hi, I recently made an update of my FST-01 to gnuk 1.2.10. The firmware was built using gcc 7.3.0 and firmware loaded using upgrade_by_passwd.py. After the update, the USB key was not recognized. dmesg did not showing the detection and the blue light did not blink as usual. Then I loaded the firmware using a STlinkv2 and the same problem appeared. After doing the same operation on a different host where the firmware was built using gcc 4.9.4, the USB key was detected normally as usual. Trying to understand the issue, I build the firmware with several version of gcc and noticed that firmware built using gcc 5.9.4 was fine when firmwares build with gcc 6.4.0 or 7.3.0 produced non functional firmwares. Then I noticed a commit in master to fix a compile warning wit gcc 7.3.0, applied it on top of gnuk 1.2.10 and ran the full iteration of tests as mentioned before and did not see a change, all firmwares build with gcc greater than 4.9.4 were not functional. Is this a known issue ? Cheers, Bertrand -- Bertrand -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Digital signature URL: From peter at digitalbrains.com Sun Aug 26 11:01:43 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 26 Aug 2018 11:01:43 +0200 Subject: Gnuk and max-cache-ttl In-Reply-To: <20180826011305.GB9207@lady-voodoo.scabb> References: <20180826011305.GB9207@lady-voodoo.scabb> Message-ID: <433b7ae6-ff3c-cf5a-d841-f989aa96f9c6@digitalbrains.com> On 26/08/18 03:13, Bertrand Jacquin wrote: > It seems that none of these parameters are properly respected Yes, it is a known shortcoming that these settings only work for on-disk keys in the agent, not smartcards. Smartcards will remain unlocked as long as they are powered currently, or until you do something like $ gpg-connect-agent "scd killscd" /bye ALthough the latter might actually still leave the smartcard unlocked but simply make GnuPG unaware of this fact :-). I'm not sure. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Mon Aug 27 03:30:46 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 27 Aug 2018 10:30:46 +0900 Subject: Gnuk with GCC >= 5 In-Reply-To: <20180826010848.GA9207@lady-voodoo.scabb> References: <20180826010848.GA9207@lady-voodoo.scabb> Message-ID: <87tvngwq7t.fsf@iwagami.gniibe.org> Bertrand Jacquin wrote: > After doing > the same operation on a different host where the firmware was built > using gcc 4.9.4, the USB key was detected normally as usual. [...] > I build the firmware with several version of gcc > and noticed that firmware built using gcc 5.9.4 was fine when firmwares > build with gcc 6.4.0 or 7.3.0 produced non functional firmwares. I think that I once (or twice) had encountered an issue in upgrading GNU Toolchain. What's your libc? Is Gnuk linked correct version? For me, when it's 6.3.1, I have following entries in gnuk/src/build/gnuk.map: ============================== /usr/lib/gcc/arm-none-eabi/6.3.1/thumb/v7-m/libgcc.a(_lshrdi3.o) build/sha512.o (__aeabi_llsr) /usr/lib/gcc/arm-none-eabi/6.3.1/thumb/v7-m/libgcc.a(_ashldi3.o) build/sha512.o (__aeabi_llsl) /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/thumb/v7-m/libc.a(lib_a-memcmp.o) build/openpgp.o (memcmp) /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/thumb/v7-m/libc.a(lib_a-memcpy.o) build/call-rsa.o (memcpy) /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/thumb/v7-m/libc.a(lib_a-memset.o) build/usb_ctrl.o (memset) /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/thumb/v7-m/libc.a(lib_a-strlen-stub.o) build/bignum.o (strlen) ============================== The important point is that we need to use V7-M/Thumb implementation of libc, while there are multiple implementations. If it's not thumb one, the first call memset will cause failure, IIRC. I needed to upgrade newlib together. It should be handled by the gcc-arm-none-eabi package with dependency. It seems that this problem has been fixed by gcc-arm-none-eabi version 15:7-2018-q2-3 recently. -- From bertrand at jacquin.bzh Mon Aug 27 03:51:39 2018 From: bertrand at jacquin.bzh (Bertrand Jacquin) Date: Mon, 27 Aug 2018 02:51:39 +0100 Subject: Gnuk with GCC >= 5 In-Reply-To: <87tvngwq7t.fsf@iwagami.gniibe.org> References: <20180826010848.GA9207@lady-voodoo.scabb> <87tvngwq7t.fsf@iwagami.gniibe.org> Message-ID: <20180827015139.GA10740@lady-voodoo.scabb> Hi, On Mon, Aug 27, 2018 at 10:30:46AM +0900, NIIBE Yutaka wrote: > Bertrand Jacquin wrote: > > After doing > > the same operation on a different host where the firmware was built > > using gcc 4.9.4, the USB key was detected normally as usual. > [...] > > I build the firmware with several version of gcc > > and noticed that firmware built using gcc 5.9.4 was fine when firmwares > > build with gcc 6.4.0 or 7.3.0 produced non functional firmwares. > > I think that I once (or twice) had encountered an issue in upgrading > GNU Toolchain. > > What's your libc? On the host I am using glibc 2.26, the target libc is newlib 2.2.0. Note that newlib remains the same when I am using gcc 4.9.4 or gcc 7.3.0 > Is Gnuk linked correct version? > > For me, when it's 6.3.1, I have following entries in > gnuk/src/build/gnuk.map: > > ============================== > /usr/lib/gcc/arm-none-eabi/6.3.1/thumb/v7-m/libgcc.a(_lshrdi3.o) > build/sha512.o (__aeabi_llsr) > /usr/lib/gcc/arm-none-eabi/6.3.1/thumb/v7-m/libgcc.a(_ashldi3.o) > build/sha512.o (__aeabi_llsl) > /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/thumb/v7-m/libc.a(lib_a-memcmp.o) > build/openpgp.o (memcmp) > /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/thumb/v7-m/libc.a(lib_a-memcpy.o) > build/call-rsa.o (memcpy) > /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/thumb/v7-m/libc.a(lib_a-memset.o) > build/usb_ctrl.o (memset) > /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/thumb/v7-m/libc.a(lib_a-strlen-stub.o) > build/bignum.o (strlen) > ============================== Mine looks like this: * gcc-4.9.4 /usr/lib/gcc/arm-none-eabi/4.9.4/thumb/libgcc.a(_lshrdi3.o) build/sha512.o (__aeabi_llsr) /usr/lib/gcc/arm-none-eabi/4.9.4/thumb/libgcc.a(_ashldi3.o) build/sha512.o (__aeabi_llsl) /usr/lib/gcc/arm-none-eabi/4.9.4/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-memcmp.o) build/openpgp.o (memcmp) /usr/lib/gcc/arm-none-eabi/4.9.4/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-memcpy.o) build/call-rsa.o (memcpy) /usr/lib/gcc/arm-none-eabi/4.9.4/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-memset.o) build/usb_ctrl.o (memset) /usr/lib/gcc/arm-none-eabi/4.9.4/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-strlen.o) build/bignum.o (strlen) * gcc-7.3.0 /usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-memcmp.o) build/openpgp.o (memcmp) /usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-memcpy.o) build/call-rsa.o (memcpy) /usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-memset.o) build/usb_ctrl.o (memset) /usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-strlen.o) build/bignum.o (strlen) build/chopstx.o: dynamic relocation against `chx_idle' in read-only section `.text.preempt' > The important point is that we need to use V7-M/Thumb implementation of > libc, while there are multiple implementations. If it's not thumb one, > the first call memset will cause failure, IIRC. > > I needed to upgrade newlib together. It should be handled by the > gcc-arm-none-eabi package with dependency. It seems that this problem > has been fixed by gcc-arm-none-eabi version 15:7-2018-q2-3 recently. I am not sure which version of the libc this corresponds to Cheers -- Bertrand -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Digital signature URL: From gniibe at fsij.org Mon Aug 27 08:51:32 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 27 Aug 2018 15:51:32 +0900 Subject: Gnuk with GCC >= 5 In-Reply-To: <20180827015139.GA10740@lady-voodoo.scabb> References: <20180826010848.GA9207@lady-voodoo.scabb> <87tvngwq7t.fsf@iwagami.gniibe.org> <20180827015139.GA10740@lady-voodoo.scabb> Message-ID: <871saks3nv.fsf@fsij.org> Hello, I wonder how you configure your gcc. Bertrand Jacquin wrote: > Note that newlib remains the same when I am using gcc 4.9.4 or gcc 7.3.0 I think that newlib for gcc 7 should be configured/compiled by gcc 7. > * gcc-7.3.0 [...] > build/chopstx.o: dynamic relocation against `chx_idle' in read-only section `.text.preempt' Strange. Dynamic relocation should never happen. > I am not sure which version of the libc this corresponds to My libc for arm-none-eabi is: Package: libnewlib-arm-none-eabi Version: 3.0.0.20180802-2 I think that the issue is not the souce version, but which gcc it is built. -- From bertrand at jacquin.bzh Mon Aug 27 23:21:22 2018 From: bertrand at jacquin.bzh (Bertrand Jacquin) Date: Mon, 27 Aug 2018 22:21:22 +0100 Subject: Gnuk with GCC >= 5 In-Reply-To: <871saks3nv.fsf@fsij.org> References: <20180826010848.GA9207@lady-voodoo.scabb> <87tvngwq7t.fsf@iwagami.gniibe.org> <20180827015139.GA10740@lady-voodoo.scabb> <871saks3nv.fsf@fsij.org> Message-ID: <20180827212122.GB19273@lady-voodoo.scabb> On Mon, Aug 27, 2018 at 03:51:32PM +0900, NIIBE Yutaka wrote: > Hello, > > I wonder how you configure your gcc. I let Gentoo do it for me :) Here is the configure statement: * strip-flags: CFLAGS: changed '-march=native -O2 -pipe -fomit-frame-pointer' to '-march=native -O2 -pipe' * strip-flags: CXXFLAGS: changed '-march=native -O2 -pipe -fomit-frame-pointer' to '-march=native -O2 -pipe' * CFLAGS="-O2 -pipe" * CXXFLAGS="-O2 -pipe" * LDFLAGS="-Wl,-O1 -Wl,--as-needed" * PREFIX: /usr * BINPATH: /usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/7.3.0 * LIBPATH: /usr/lib/gcc/arm-none-eabi/7.3.0 * DATAPATH: /usr/share/gcc-data/arm-none-eabi/7.3.0 * STDCXX_INCDIR: /usr/lib/gcc/arm-none-eabi/7.3.0/include/g++-v7 * Languages: c,jit * Configuring GCC with: * --host=x86_64-pc-linux-gnu * --target=arm-none-eabi * --build=x86_64-pc-linux-gnu * --prefix=/usr * --bindir=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/7.3.0 * --includedir=/usr/lib/gcc/arm-none-eabi/7.3.0/include * --datadir=/usr/share/gcc-data/arm-none-eabi/7.3.0 * --mandir=/usr/share/gcc-data/arm-none-eabi/7.3.0/man * --infodir=/usr/share/gcc-data/arm-none-eabi/7.3.0/info * --with-gxx-include-dir=/usr/lib/gcc/arm-none-eabi/7.3.0/include/g++-v7 * --with-python-dir=/share/gcc-data/arm-none-eabi/7.3.0/python * --enable-languages=c,jit * --enable-obsolete * --enable-secureplt * --disable-werror * --with-system-zlib * --enable-nls * --without-included-gettext * --enable-checking=release * --with-bugurl=https://bugs.gentoo.org/ * --with-pkgversion=Gentoo Hardened 7.3.0-r3 p1.4 * --enable-esp * --disable-libstdcxx-pch * --enable-host-shared * --enable-poison-system-directories * --disable-libstdcxx-time * --with-sysroot=/usr/arm-none-eabi * --disable-bootstrap * --with-newlib * --enable-multilib * --disable-altivec * --disable-fixed-point * --with-float=soft * --disable-libgomp * --disable-libmudflap * --disable-libssp * --disable-libcilkrts * --disable-libmpx * --enable-vtable-verify * --enable-libvtv * --disable-libquadmath * --enable-lto * --without-isl * --disable-libsanitizer * --enable-default-pie * --enable-default-ssp /var/tmp/portage/cross-arm-none-eabi/gcc-7.3.0-r3/work/gcc-7.3.0/configure --host=x86_64-pc-linux-gnu --target=arm-none-eabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/7.3.0 --includedir=/usr/lib/gcc/arm-none-eabi/7.3.0/include --datadir=/usr/share/gcc-data/arm-none-eabi/7.3.0 --mandir=/usr/share/gcc-data/arm-none-eabi/7.3.0/man --infodir=/usr/share/gcc-data/arm-none-eabi/7.3.0/info --with-gxx-include-dir=/usr/lib/gcc/arm-none-eabi/7.3.0/include/g++-v7 --with-python-dir=/share/gcc-data/arm-none-eabi/7.3.0/python --enable-languages=c,jit --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo Hardened 7.3.0-r3 p1.4 --enable-esp --disable-libstdcxx-pch --enable-host-shared --enable-poison-system-directories --disable-libstdcxx-time --with-sysroot=/usr/arm-none-eabi --disable-bootstrap --with-newlib --enable-multilib --disable-altivec --disable-fixed-point --with-float=soft --disable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --disable-libquadmath --enable-lto --without-isl --disable-libsanitizer --enable-default-pie --enable-default-ssp > Bertrand Jacquin wrote: > > Note that newlib remains the same when I am using gcc 4.9.4 or gcc 7.3.0 > > I think that newlib for gcc 7 should be configured/compiled by gcc 7. Yes, this was the case, everytime I rebuilt gcc, I also rebuild newlib. > > * gcc-7.3.0 > [...] > > build/chopstx.o: dynamic relocation against `chx_idle' in read-only section `.text.preempt' > > Strange. Dynamic relocation should never happen. > > > I am not sure which version of the libc this corresponds to > > My libc for arm-none-eabi is: > > Package: libnewlib-arm-none-eabi > Version: 3.0.0.20180802-2 > > I think that the issue is not the souce version, but which gcc it is built. newlib 3.0.0 is not available in gentoo yet unfortunately, even thought a request for an update was made in https://bugs.gentoo.org/656018 Cheers -- Bertrand -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Digital signature URL: From gniibe at fsij.org Tue Aug 28 03:04:03 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 28 Aug 2018 10:04:03 +0900 Subject: Gnuk with GCC >= 5 In-Reply-To: <20180827212122.GB19273@lady-voodoo.scabb> References: <20180826010848.GA9207@lady-voodoo.scabb> <87tvngwq7t.fsf@iwagami.gniibe.org> <20180827015139.GA10740@lady-voodoo.scabb> <871saks3nv.fsf@fsij.org> <20180827212122.GB19273@lady-voodoo.scabb> Message-ID: <87wosbfgjg.fsf@fsij.org> Hello, For my own environment, configure options for GCC build is: https://salsa.debian.org/debian/gcc-arm-none-eabi/blob/master/debian/rules#L33 I found a problem in your configuration of GCC. For the target arm-none-eabi, which Gnuk uses, it's free standing environment, where we have no system calls and no loarder (any kinds of, not only dynamic linker+loader, but also the initial static loader). So, some configure options are irrelevant. Bertrand Jacquin wrote: > I let Gentoo do it for me :) Here is the configure statement: [...] > * Configuring GCC with: > * --host=x86_64-pc-linux-gnu > * --target=arm-none-eabi > * --build=x86_64-pc-linux-gnu > * --prefix=/usr > * --bindir=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/7.3.0 > * --includedir=/usr/lib/gcc/arm-none-eabi/7.3.0/include > * --datadir=/usr/share/gcc-data/arm-none-eabi/7.3.0 > * --mandir=/usr/share/gcc-data/arm-none-eabi/7.3.0/man > * --infodir=/usr/share/gcc-data/arm-none-eabi/7.3.0/info > * --with-gxx-include-dir=/usr/lib/gcc/arm-none-eabi/7.3.0/include/g++-v7 > * --with-python-dir=/share/gcc-data/arm-none-eabi/7.3.0/python > * --enable-languages=c,jit > * --enable-obsolete No problem, so far. > * --enable-secureplt This is irrelevant for arm-none-eabi. It doesn't use PLT. Perhaps, specifying this option is OK, provided we don't use PLT. > * --disable-werror > * --with-system-zlib > * --enable-nls > * --without-included-gettext > * --enable-checking=release > * --with-bugurl=https://bugs.gentoo.org/ > * --with-pkgversion=Gentoo Hardened 7.3.0-r3 p1.4 Those are OK. > * --enable-esp > * --disable-libstdcxx-pch > * --enable-host-shared > * --enable-poison-system-directories I wonder if those makes sence (and how) for arm-none-eabi. > * --disable-libstdcxx-time > * --with-sysroot=/usr/arm-none-eabi > * --disable-bootstrap > * --with-newlib > * --enable-multilib > * --disable-altivec > * --disable-fixed-point > * --with-float=soft > * --disable-libgomp > * --disable-libmudflap > * --disable-libssp > * --disable-libcilkrts > * --disable-libmpx No problem. > * --enable-vtable-verify > * --enable-libvtv I think that it doesn't matter for Gnuk build. > * --disable-libquadmath > * --enable-lto > * --without-isl > * --disable-libsanitizer No problem. > * --enable-default-pie This is wrong. We don't have dynamic linker for arm-none-eabi. This might be the cause of your problem. At least, I'm sure that it will generate dynamic relocations. > * --enable-default-ssp How does it make sence for arm-none-eabi? I don't know. -- From bertrand at jacquin.bzh Tue Aug 28 22:55:30 2018 From: bertrand at jacquin.bzh (Bertrand Jacquin) Date: Tue, 28 Aug 2018 21:55:30 +0100 Subject: Gnuk with GCC >= 5 In-Reply-To: <87wosbfgjg.fsf@fsij.org> References: <20180826010848.GA9207@lady-voodoo.scabb> <87tvngwq7t.fsf@iwagami.gniibe.org> <20180827015139.GA10740@lady-voodoo.scabb> <871saks3nv.fsf@fsij.org> <20180827212122.GB19273@lady-voodoo.scabb> <87wosbfgjg.fsf@fsij.org> Message-ID: <20180828205530.GC11909@lady-voodoo.scabb> Hi, > > * --enable-default-pie > > This is wrong. We don't have dynamic linker for arm-none-eabi. This > might be the cause of your problem. At least, I'm sure that it will > generate dynamic relocations. Indeed, if I build gnuk with -fno-pie, then the map file is correct: /usr/lib/gcc/arm-none-eabi/7.3.0/thumb/libgcc.a(_lshrdi3.o) build/sha512.o (__aeabi_llsr) /usr/lib/gcc/arm-none-eabi/7.3.0/thumb/libgcc.a(_ashldi3.o) build/sha512.o (__aeabi_llsl) /usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-memcmp.o) build/openpgp.o (memcmp) /usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-memcpy.o) build/call-rsa.o (memcpy) /usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-memset.o) build/usb_ctrl.o (memset) /usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-strlen.o) build/bignum.o (strlen) Can you please consider applied the attached patch to chopstx? Cheers -- Bertrand -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Disable-PIE-by-default.patch Type: text/x-diff Size: 752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Digital signature URL: From gniibe at fsij.org Wed Aug 29 01:56:31 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 29 Aug 2018 08:56:31 +0900 Subject: Gnuk with GCC >= 5 In-Reply-To: <87wosbfgjg.fsf@fsij.org> References: <20180826010848.GA9207@lady-voodoo.scabb> <87tvngwq7t.fsf@iwagami.gniibe.org> <20180827015139.GA10740@lady-voodoo.scabb> <871saks3nv.fsf@fsij.org> <20180827212122.GB19273@lady-voodoo.scabb> <87wosbfgjg.fsf@fsij.org> Message-ID: <877ekagi4w.fsf@iwagami.gniibe.org> NIIBE Yutaka wrote: > So, some configure options are irrelevant. And I found another problem (not severe, though). >> * --enable-multilib It seems that it only enables libs for generic ARM and generic Thumb. I think that you need to specify multilib-list to fully support optimization for different sub architectures. In 7.x, it's: --with-multilib-list=rmprofile where "R M profile" stands for support of ARM-R and ARM-M. -- From gniibe at fsij.org Wed Aug 29 07:40:30 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 29 Aug 2018 14:40:30 +0900 Subject: Gnuk with GCC >= 5 In-Reply-To: <20180828205530.GC11909@lady-voodoo.scabb> References: <20180826010848.GA9207@lady-voodoo.scabb> <87tvngwq7t.fsf@iwagami.gniibe.org> <20180827015139.GA10740@lady-voodoo.scabb> <871saks3nv.fsf@fsij.org> <20180827212122.GB19273@lady-voodoo.scabb> <87wosbfgjg.fsf@fsij.org> <20180828205530.GC11909@lady-voodoo.scabb> Message-ID: <871sahhgs1.fsf@iwagami.gniibe.org> Bertrand Jacquin wrote: > If gcc is built using --enable-default-pie, generated binary will > contain dynamic relocations which is irrelevant for firmware build Sorry, I think that this is a problem of building arm-none-eabi-gcc, not a problem of Chopstx or Gnuk. I don't know any good reason for building GCC with --enable-default-pie for free standing target. GCC could even reject that option, imnsho. Chopstx is used by GNU/Linux emulation, which may use PIE correctly. -- From bertrand at jacquin.bzh Thu Aug 30 02:56:57 2018 From: bertrand at jacquin.bzh (Bertrand Jacquin) Date: Thu, 30 Aug 2018 01:56:57 +0100 Subject: Gnuk with GCC >= 5 In-Reply-To: <871sahhgs1.fsf@iwagami.gniibe.org> References: <20180826010848.GA9207@lady-voodoo.scabb> <87tvngwq7t.fsf@iwagami.gniibe.org> <20180827015139.GA10740@lady-voodoo.scabb> <871saks3nv.fsf@fsij.org> <20180827212122.GB19273@lady-voodoo.scabb> <87wosbfgjg.fsf@fsij.org> <20180828205530.GC11909@lady-voodoo.scabb> <871sahhgs1.fsf@iwagami.gniibe.org> Message-ID: <20180830005657.GB25700@lady-voodoo.scabb> On Wed, Aug 29, 2018 at 02:40:30PM +0900, NIIBE Yutaka wrote: > Bertrand Jacquin wrote: > > If gcc is built using --enable-default-pie, generated binary will > > contain dynamic relocations which is irrelevant for firmware build > > Sorry, I think that this is a problem of building arm-none-eabi-gcc, not > a problem of Chopstx or Gnuk. I don't know any good reason for building > GCC with --enable-default-pie for free standing target. GCC could even > reject that option, imnsho. > > Chopstx is used by GNU/Linux emulation, which may use PIE correctly. Would it make to enforce the use of no-pie if the target is not GNU/Linux emulation as it's done for other options in the configure file since all target but GNU/Linux are bare metal. This issue may affect other distributions or users building their own toolchain. When experienced, it really feels like the smartcard was bricked and since it's not a problem that easy to troubleshoot, it potentially lead to some extra complaints from gnuk users. -- Bertrand -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Digital signature URL: