Tegra board allocation for Security Team (ARM Fuzzing)

RESOLVED FIXED

Status

Infrastructure & Operations
Buildduty
RESOLVED FIXED
6 years ago
18 days ago

People

(Reporter: decoder, Assigned: bear)

Tracking

({sec-want})

Details

(Whiteboard: [sg:want])

(Reporter)

Description

6 years ago
As previously discussed with ctalbert, part of our Q2 goals in security is to deploy an automated fuzzing framework to test Fennec on Android. For this purpose, we will ultimately want to use our own pool of panda boards. However, since these boards won't be ready until Q3, we decided that a smaller set of Tegra boards should be used as a temporary drop-in so we can start testing and iron out further bugs in our automation and deployment.

As discussed on IRC with jmaher and bear, 5 tegra boards should be allocated for this purpose such that we can access them from a server where we can run the framework to interact with the boards. Jmaher mentioned that the boards would be accessible from the tegravm server (10.250.7.80), where I do have an account already, so this wouldn't require any changes on that side.

Let me know if there's anything else required and thanks in advance for helping with setting this up :)
(Assignee)

Updated

6 years ago
Component: Release Engineering → Release Engineering: Machine Management
QA Contact: release → armenzg
Whiteboard: [sg:want] → [sg:want][buildduty]
(Assignee)

Updated

6 years ago
Assignee: nobody → bear
(Assignee)

Comment 1

6 years ago
I'm working thru inventory now to identify the boards.
(Assignee)

Comment 2

6 years ago
I have identified the following tegras:

tegra-202
tegra-203
tegra-204
tegra-205
tegra-275

they are now out of releng circulation and ready for your use
(Assignee)

Comment 3

6 years ago
info delivered along with notes on how to reboot and manage tegras

enjoy your fuzzing ;)
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Also as an FYI --

"How to remote reformat the sdcard"

* Make sure nothing else is actively using tegra at the time
* Connect to tegra via command port (20701)
* execute: |exec mount| (skim/take note of output, this is just a sanity check)
* execute: |exec newfs_msdos -F 32 /dev/block/vold/179:9| (this does the actual clearing)
* execute: |rebt| (this should seem to "hang" at prompt for quite a while)
* -- To dive out of the hung telnet prompt use the escape char (ctrl+]) then enter, then type |quit| and enter to return to your normal prompt.

This method of formatting is *not* a secure format.
(Reporter)

Comment 5

6 years ago
Reopening per our discussion on IRC. I've been monitoring the Tegras for two days now and it seems that tegra-202 and tegra-205 keep rebooting themselves shortly after testing has started. The rest seems to run more reliably.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 6

6 years ago
k, let's see how these two perform:

tegra-198
tegra-287
This doesn't seem buildduty related, removing the whiteboard tag.
Whiteboard: [sg:want][buildduty] → [sg:want]

Updated

6 years ago
Blocks: 755739
(In reply to Mike Taylor [:bear] from comment #6)
> k, let's see how these two perform:

No complaints on these, so..

enjoy your fuzzing ;)
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
(Reporter)

Updated

6 years ago
Blocks: 804306
(Reporter)

Updated

6 years ago
Blocks: 804308

Updated

6 years ago
Depends on: 807784

Updated

6 years ago
No longer blocks: 804306
Depends on: 804306

Updated

6 years ago
No longer blocks: 804308

Updated

6 years ago
No longer blocks: 755739
Depends on: 755739
(Reporter)

Comment 9

5 years ago
These boards can be returned now, we are no longer using them for fuzzing. Thanks a lot :)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Thanks decoder.
We will be using dep bugs to track returning each one of them.

12:20 decoder: Callek: armenzg_brb: I thought the tegras were already given back
12:20 decoder: if not, you can take them back now
12:20 Callek: decoder: ooo, heh not afaik
12:20 Callek: decoder: note that "Mozilla" will be supporting tegras until at least Q4 2014
12:21 Callek: decoder: since thats the only platform we have that supports Android 2.x atm (2.2 on tegras)
12:21 decoder: yea, they havent been very reliable during fuzzing, i dont think it makes much sense to keep them right now
12:21 decoder: (for us)
12:21 Callek: decoder: can you enumerate that explicitly in, lets go for, Bug 749637, then, just so we have a record we can point to
12:22 decoder: Callek: shall I reopen that bug and state that they can be taken back?
12:22 Callek: that works for me!
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago5 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering

Updated

5 years ago
Blocks: 755739, 804306, 807784
No longer depends on: 755739, 804306, 807784

Updated

5 years ago
Blocks: 928122
coop: should tegra bugs that are still blocked here be blocked on bug 928122 instead?
Flags: needinfo?(coop)
(In reply to John Hopkins (:jhopkins) from comment #11)
> coop: should tegra bugs that are still blocked here be blocked on bug 928122
> instead?

Yes.
Flags: needinfo?(coop)

Updated

18 days ago
Product: Release Engineering → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.