-1

If I stop getty for the following vt I can achieve what I want, but only until reboot

systemctl stop serial-getty@ttymxc1

1) How do I make it permanent?
"disable" does not help.
2) How do I make it irreversible?
If user takes sdcard out of device and fiddles with insides, he still shall not be able to restore access.

P.S. If it's possible I don't want to touch uboot.
EDIT
A few more useful points from discussion in comments:
Breaking pins is not something I may decide, this is a mass production hardware and handling is done by hardware team. I'm sure this stuff is already long before decided, schematics won't be changed in a last minute if it's not something terrible.
In 2) I asked for solution to be irreversible. The reason is that, customer wants no access to console possible, even if soldering is performed. Technically, solution like systemctl stop serial-getty@ttymxc1 is easily reversible, so I'm interested in if there is any other more bulletproof possible ways.

  • Is this a real serial console? If so, the easiest irreversible solution would be to break off the Rx and Tx pins, but I have a feeling you don't want to go that far – Fox Sep 12 '17 at 11:06
  • 1
    Yep, real one. Not at workplace atm, but wording in documentation was like "user should not be able to get access to console even by means of soldering". I managed to kill serial pins output in uboot, but device should be able to have usable serial console at factory testing step, and after testing ends simple reboot occurs and device looses serial console functionality completely. That is, do this somehow from userspace, uboot won't do – metamorphling Sep 12 '17 at 12:35
  • "even by means of soldering" effectively gives the user the ability to replace the entire device, so some means of physical securement seems necessary – Fox Sep 12 '17 at 17:15
  • There is a lot of stuff in question comments and answer comments here that should be in the question right from the start. – JdeBP Sep 12 '17 at 19:08
  • @JdeBP what exactly should have been in question that was not clean from the start? Bloated questions are not easy to read, I summed up problem into minimal explanation. All necessary conditions were in question from the start and, for example, present answer does not satisfy the second one. Anyway, edited to add info from discussions. – metamorphling Sep 13 '17 at 0:43
1

Mask the service.

systemctl mask serial-getty@ttymxc1

This will create a symlink from the service to /dev/null and at restart it will not be used.

Unmask to enable again.

systemctl unmask serial-getty@ttymxc1
  • Well, I don't want it be enabled again. Ever. End user shall not be able to get access to console, with this method access can be restored by adding unmask to any runscript on sdcard. – metamorphling Sep 12 '17 at 9:36
  • 2
    That is if the user has root access.. How is the user going to get root access? – Hunter.S.Thompson Sep 12 '17 at 9:39
  • Technical documentation requirements, nothing personal. But I will try to propose a CR, thanks – metamorphling Sep 12 '17 at 10:31
  • 1
    If the user has physical access to the device, including the ability to swap the SD card it boots from, you may want to look for similar requirements in your documentation that don't make much sense. If the user has physical access, (s)he can do anything with the device, unless it has some kind of tamper proof firmware with the ability to check the signature of the SD card contents. – Johan Myréen Sep 12 '17 at 10:54
  • Well, if I comment out rx tx pins output in bootloader, that makes it impossible to get access. Looking for solution that can not be reversed by just tampering with scripts on SD card. – metamorphling Sep 12 '17 at 12:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.